Kubernetes 1.7 has been released with focus on extensibility and security hardening. In this post I’ll review the new security features and their importance.
The Network Policy API
The Network Policy API was promoted to stable. A network policy is a specification of rules that controls how groups of pods can communicate with each other. Network policies are implemented by the network plugin, so you must be using a supported networking solution like Weave or Calico.
Let’s take a look at Kubernetes guestbook example:
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/examples/guestbook/all-in-one/guestbook-all-in-one.yaml
The network architecture of the guestbook is pretty straightforward:
Redis-slave receives connections on port 6379 from the frontend service and redis-master receives connections from frontend and from redis-slave on port 6379.
We define a set of two rules which describe the set of allowed connections:
Network policies support only ingress rules – rules on incoming connections to the pod. For every rule we define a target pod (using label matching) and a set of pods that are allowed to communicate with the target pod and a list of allowed ports.
Let’s try to access the redis-master Service from a pod without the correct labels.
First we will create a listening service inside redis-master:
$ kubectl get pods -o=wide | grep master redis-master-106238132-rj758 1/1 Running 0 2h 10.244.1.7 kubernetes-minion-group-96d7
$ kubectl exec -ti redis-master-106238132-rj758 sh
# nc -klvp 9090
Now we run a new pod that will attempt to connect to the redis-master:
$ kubectl run busybox --rm -ti --image=busybox /bin/sh # wget wget --spider --timeout=1 10.244.1.7:9090 wget: download timed out
The attempt was blocked and the request received time out.
Kubernetes network policies provide a clean and app-centric way to define network firewall rules. Notice that there are no IP addresses in the rules since pods IPs can change. At Twistlock we embraced network policies from it’s beta stage. We allow users to automatically export policies from the model you see in Runtime Radar so you don’t have manually configure and update them.
Encryption for Secrets
This feature allows sensitive data such as passwords, API keys, or other resources stored in the etcd key-value store to be encrypted. By providing a simple encryption config the user can choose the encryption algorithm (AES-CBC, AES-GCM, XSalsa20) and the secrets he would like to encrypt, i.e:
kind: EncryptionConfig apiVersion: v1 resources: - resources: - secrets providers: - aescbc: keys: - name: key1 secret:[BASE 64 ENCODED SECRET]
Node authorizer and admission control plugin provides a control of what resources a node can access. In previous versions of Kubernetes nodes had access to global resources while controlling only small portion of resources on the cluster. In Kubernetes 1.7 nodes are limited to access resources for pods that are scheduled to run on them.
Kubelet TLS bootstrapping
This feature defines a standardized way for dynamic registration of nodes. When kublet starts running it asks the Kubernetes master for client certificate that will identify it. This request goes through an approval control process which can be automatic or manual where administrator can add custom verification using scripts and api. This feature gives the administrator control over which nodes should join the cluster and what checks and verifications are needed in order to join while keeping the process of joining automated and autonomous.
Kubernetes 1.7 introduces some interesting and important security enhancement which will improve resources isolation and protection. Most of the features are in their alpha stage and it will be exciting to see their adoption and improvement in upcoming releases.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.