Kubernetes Security
Kubernetes 1.4 Enhances Security with TLS Bootstrap
The open-source 1.4 release, which debuted Sept. 26, provides users with a host of enhanced Kubernetes security capabilities for container deployment and orchestration.
Kubernetes originated at Google and is now part of the Cloud Native Computing Foundation, benefiting from the contributions of multiple vendors. Among the new features in Kubernetes 1.4 is TLS bootstrap, which is designed to improve the use of encryption for data in motion across a cluster. TLS (Transport Layer Security) is widely used on the internet today for encryption.
“The TLS bootstrapping work done in Kubernetes 1.4 is a step toward automating the addition of new hosts to the Kubernetes cluster,” Clayton Coleman, Red Hat’s lead architect for OpenShift, explained to SCS.
OpenShift is Red Hat’s platform as a service (PaaS) and is based on Docker containers and Kubernetes. Coleman noted that Kubernetes 1.4 is already available in the OpenShift Origin upstream project. Later this quarter, Red Hat’s commercially supported OpenShift Container Platform 3.4 will be updated with Kubernetes 1.4. OpenShift Container Platform 3.3, based on Kubernetes 1.3, was released on Sept. 22.
CoreOS is also a leading contributor to Kubernetes security and builds a commercially supported distribution of Kubernetes called Tectonic. Prior to Kubernetes 1.4, the communication channel between the kubelet (a core building block of Kubernetes and the primary node agent that runs on each node) and the API server was only secured in one direction without manual configuration.
This change [TLS bootstrap] allows kubelets to request cryptographic assets [certificates] that identify them as approved members of the cluster when talking to the API server. This sets the stage for a variety of security features based on strong kubelet identity.
Going forward, CoreOS hopes to expand the TLS bootstrap feature to allow other components of Kubernetes to request certificates.
Container Security Enhancements
Another new capability in Kubernetes security 1.4 is the image policy webhook that can help make sure malicious container images don’t run on a cluster.
An Admission Controller is configured with an Image Policy webhook that will contact a back-end service for verifying images. The back-end service needs to only understand how to respond to a request from an admission controller, which allows for a variety of possible back-end services.
One example could be a service collocated with CoreOS’ Quay container image repository, which approves or rejects scheduling requests for containers based on the results of a Quay Security Scanner analysis. He added that today that system can notify users of potential issues via email, Slack or webhook but with this addition to Kubernetes a user will, in the future, be able to block known vulnerable images from ever running.
Pod Security Policy
Work is also ongoing in Kubernetes with a Pod Security Policy, which is the upstream Kubernetes equivalent of the Security Context Constraints that originally shipped with OpenShift v3.0 in June 2015.
aPod Security Policy (and Security Context Constraints) provides a set of rules that match a user or group to allow security options on the pods they create—to limit users from running pods/containers that may not be secure,” Coleman said.
Pod Security Policy is currently off by default in Kubernetes, he said. The current plan from Red Hat is to move the security policies that OpenShift provides out of the box, which range from restrictive to fully permissive, into Kubernetes in either the 1.5 or 1.6 releases.
Looking forward for Philips, one of the major efforts for CoreOS is helping to make rkt a first-class container runtime for Kubernetes. Rkt is a container runtime effort led by CoreOS that got started in December 2014.
“Our goal as community stewards for Kubernetes is to allow broad participation in the project while ensuring a healthy technical foundation for innovation,” Philips said.
The top areas of improvement for the Kubernetes 1.5 release, according to Coleman, will include maturing the storage capabilities in Kubernetes with dynamic volume provisioning across a wide range of cloud providers and storage systems. In addition, there is a focus on continuing to make performance and scale improvements to enable larger clusters.
