The Center for Internet Security (CIS) published a new banchmark last week for Kubernetes 1.6. As the adoption of container technologies grows rapidly, orchestrators have become a key enabler, since large-scale deployments can’t be managed efficiently by humans.
While securing a single-node deployment is extremely important, securing the cluster largely depends on the security of the orchestrator configuration as a whole.
Standardization of security requirements is very important, as we explained in our blog about the Docker CIS benchmark, so it’s only logical that CIS would publish a standard for orchestrators. Kubernetes is one of the leading orchestrators and endorsed by the CNCF. Although it’s still rapidly changing and has many security features planned on its roadmap (which I wrote about on the K8S blog a while back), the CIS decided that the 1.6 release is mature enough to create a standard benchmark document, to help organizations in the adoption of Kubernetes in production.
CIS Benchmark: What You Should Know
As with the Docker CIS benchmark when it came out, one thing that strikes me is the length of the new benchmark (more than 220 pages), and bear in mind this is just the first version! Orchestrators in general, and Kubernetes in particular, are complex, multi-component systems. Securing such systems is not a simple task, and the document’s scope it a testament to that.
In an attempt to help you separate the wheat from the chaff, following are what I consider the most significant recommendations in this document from a security perspective, grouped by categories of security measures:
Setup Authentication and Authorization
- Requests must be authorized and ‘admitted’, do not allow unauthorized/unauthenticated access of any kind.
- Provide separate identities (service account) to cluster components wherever relevant. This allows providing only minimal required privileges to those components.
- Configure authorization to be as granular as is practical, putting special attention to granting admin roles only to where required.
- Certificates and keys should be rotated. Configure your cluster to enable such procedures.
Secure Data In Transit
- All communications to/from a cluster and between inner components must be encrypted and authenticated, always verifying the component’s certificate.
- Each of the cluster components must be configured accordingly.
Secure Data at Rest
- Sensitive data must not be accessible to anyone or anything that are not authorized. Set ACLs and ownership accordingly.
- Avoid using Kubernetes secrets due to risks imposed by current implementation.
- Keep data of different sensitivity levels separate (e.g. Logs and secrets). That allows to set safeguards suitable to the level of sensitivity.
- All files holding critical configuration must be writable only by cluster administrators. File ACLs and ownership must be set accordingly.
Employ Least Privileges
The ‘least privilege’ principle must be a guiding light to ensure security of your cluster. By following it you will minimize the attack surface:
- Minimize the scope of user permissions by creating administrative boundaries using namespaces.
- Minimize the scope of container’s ‘network’ permissions by segmenting your network using network policies.
- No privileged containers should be able to run by default, and user access to the ones that are running in privileged mode should not be allowed.
Additional Runtime Controls
Consider the following:
- Provide identity to pods, i.e., use separate service accounts instead of just falling back to ‘default’. This allows for better control and monitoring of your runtime.
- Configure a pod security policy and then only allow running pods that conform to the policy.
- Configure security controls provided by underlying platforms (seccomp, SELinux, etc.) and by Kubernetes (Security Context).
- Enable and properly configure event logging. This is important for compliance audits, and for forensics in case of a security event.
In Summary
All of the above may sound obvious to some, but configuring complex software such as Kubernetes correctly is very challenging. The CIS benchmark is an impressive reference that takes advantage of the current Kubernetes release capabilities, but following 106 different items may be difficult to prioritize – I hope that readers can use my highlights as a ‘best practices’ approach to following the CIS benchmark.
Having emerging standards for securing orchestrators is evidence that security is being taken seriously and that the market is maturing. We at Aqua will continue to push the envelope, making such standards easier to implement and going beyond them to provide security worthy of critical applications in production.
