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

Kubernetes 1.7

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:

Kubernetes 1.7

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

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.

Final take

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.

← Back to All Posts Next Post →