Apart from safeguarding network policy, it is also important to secure a cluster at the container level, which means the user is not allowed to use privileged containers unless explicitly authorized to do so.

Users prove their identity to Kubernetes with client certificates or – less recommended – passwords. External services can also be connected. Kubernetes automatically creates client certificates as secrets when creating service accounts. Related concepts will be delivered during the alpha to beta stage of production, although it works quite well already.

Privileged containers are the new root privileges. They are very powerful and dangerous if misused. To build Docker images, you would, for example, embed the Docker socket of the surrounding host in these containers. However, in the worst case, the surrounding node can be hijacked.

The path to a secure system is not easy and can only be outlined here. First, kube-admin creates service accounts, then generates roles via role-based access control (RBAC) [20], and binds them to users or groups. The right to administer a security policy, for example, must be severely restricted.

Roles give rights to resources in the form of verbs. For concepts with pods, verbs are actions: REST API calls here. Put simply, they give rights to perform read (get and list) or write (create or update) operations on pods, services, ingresses, or secrets. Doing so often goes deep into resources and can, for example, prevent users from creating pods without a security context – or with the wrong one.

If you withdraw the right to run root processes in containers with spec.securityContext.runAsNonRoot:true, most of the examples from the Internet will no longer launch. You should definitely switch on the feature in secure environments (Listing 9). It is well implemented with different degrees of success in the various implementations of Kubernetes; you are on the safe side with OpenShift and the Kubernetes distribution by Red Hat.