Setting a New Standard for Kubernetes Deployments

The Center for Internet Security (CIS) has recently released a new benchmark standard for Kubernetes deployments, providing a vendor-neutral benchmark to help companies assess against good security practices.

Kubernetes is a key player in the containerisation technology market, seeking to help developers and IT staff effectively manage large fleets of containers. Like many products in this space, Kubernetes is still in rapid development and security functionality is continuously being incorporated into the system.

As a result, and following the release of Kubernetes 1.6 in March 2017, the CIS decided that a benchmark should be created for the system. NCC Group has been helping with this new standard, which is now available on the CIS website.

One of the challenges we faced in building this standard is that it can be difficult to define a Kubernetes target installation. The reason being, there are a large number of different Kubernetes ‘distributions’ – over 60 at the time of writing – which have differing installation mechanisms and make distinct choices with regards to how key components are configured and deployed.

Like any standard, it’s important that organisations using it understand their underlying security goals and make appropriate decisions about which options are important to them. This is particularly important with the standard in question, as users will need to tailor it to the style of Kubernetes deployment they have chosen.

Key security areas

The standard focuses on a number of key settings that can be used to harden a Kubernetes deployment. There are over 100 recommendations in the standard at the moment, but here are some of the key things to look out for:

• API Server Authentication: The Kubernetes API server is the interface to the cluster for most external users and, as such, securing access to it is key to the overall security of the system. Authentication choices vary from using clear text static credentials and HTTP Basic authentication (which we wouldn’t recommend) to the more commonly recommended choice of SSL/TLS client certificates.
• API Server Authorisation: Role Based Access Control (RBAC) is a relatively new addition to Kubernetes, but making appropriate use of this can help significantly in restricting what various clients can do when connected to the API server. Older versions of Kubernetes only offered an ‘all or nothing’ option, which could lead to nasty security surprises. Deploying RBAC is therefore definitely recommended.
• Kubelet Authentication: The Kubelet process is a key component which runs on Kubernetes worker nodes and manages the Docker service (which is used to create pods of containers). Securing access to the Kubelet service is therefore a key step in defending against unauthorised container creation, especially considering that older versions of Kubernetes tended to allow unauthenticated access.
• etcd security: etcd is used as the store for Kubernetes state information, so you should be sure to control access to it and make sure that only authorised processes and users can read that information. This is also one of the areas where the appropriate controls from the CIS standard will change depending on which Kubernetes distribution you are using. Some will have etcd only listen on the local interface of the master node – which is a fairly effective restriction on access – whereas others will listen on port 2379/TCP on all interfaces across several nodes, at which point it becomes vital that you ensure effective authentication controls within etcd.
• The use of privileged containers: With full access to the underlying Kubernetes node, privileged containers are in a good position to compromise the cluster’s security if misused. However, many Kubernetes distributions make use of these in areas such as Cluster Network Interface configuration, so care has to be taken before making a decision to disable this facility at a cluster level. This is another good example of an issue where users of the standard should take time to understand what works for their specific installation before making changes to the configuration of their clusters.

These are just some of the areas where the CIS standard should be able to help Kubernetes users understand the security controls available to them and allow them to start applying these across their clusters. This standard is sure to develop as Kubernetes adds more security options, so interested parties should contact the CIS if they’d like to contribute to later versions.

In the future, we are hoping to look at benchmarking popular Kubernetes distributions against the standard to help users make a decision about which option suits their needs the best from a security perspective.

To access the CIS benchmark standard for Kubernetes, click here: https://learn.cisecurity.org/benchmarks

Written by Rory McCune
First published on 16/05/17