Because of the orchestrator’s comprehensive reach in the container runtime environment, Kubernetes security is a critical aspect of the security posture of the container infrastructure. In this first part of our new blog series, which is part of our upcoming ebook release on Kubernetes deployment and security patterns , we will talk about threat models for a Kubernetes deployment.
Dr. Chenxi Wang
Dr. Chenxi Wang is the founder of the Jane Bond Project, a cybersecurity strategy consulting firm. A well-known strategist, speaker, and writer in the cybersecurity industry. Dr. Wang also serves as Vice Chair on the Board of Directors for the OWASP foundation, investment advisor to ClearSky security and 630 Cyber, as well as strategy advisor to various security startups and IT Security Planet. Previously, Chenxi was Chief Strategy Officer at Twistlock, responsible for building Twistlock’s brand and business from zero to the leader in the segment. Chenxi was named by SC Magazine as a 2016 Women of Influence, and she served as the program chair (Security & Privacy) for the 2017 Grace Hopper Conference. Chenxi built an illustrious career in the cybersecurity industry, including several executive positions at Forrester Research, Intel Security, and CipherCloud. At Forrester, Chenxi covered mobile, cloud, and enterprise security, and wrote many hard-hitting research papers. At Intel Security, she led the ubiquity strategy that spans both hardware and software platforms. Chenxi started her career as a faculty member of Computer Engineering at Carnegie Mellon University. Chenxi is a sought after public speaker and has been featured by top media outlets and events worldwide. Chenxi holds a Ph.D. in Computer Science from University of Virginia.
In theKubernetes environment, there are generally four types of threats that apply regardless of the deployment model (with some edge case exceptions):
These different threats may result in a multitude of compromises and undesirable scenarios, including elevation of privileges, exfiltration of sensitive data, compromise of operations or breach of compliance policies.
KubeCon + CloudNativeCon conferences gather adopters and technologists to further the education and advancement of cloud native computing. The vendor-neutral events feature domain experts and key maintainers behind popular projects like Kubernetes, Prometheus, gRPC, Envoy, OpenTracing and more.
Alcide delivers a network security platform designed for any combination of container, VM and bare metal data centers operated by multiple orchestration systems. Alcide empowers DevOps, Security and Engineering teams with simplified and autonomous control to manage and secure the evolving data center and hybrid cloud, at any scale.
Twistlock protects today’s applications from tomorrow’s threats with advanced intelligence, machine learning capabilities, and automated policy creation and enforcement. As the first end-to-end container security solution, Twistlock is purpose-built to deliver modern security.
One of the attack scenarios that has garnered a fair amount of attention is the concern of “blast radius” — how much damage can a compromised container do to other containers on the same node, or how much damage can a compromised node do to the rest of the cluster? All security considerations for a Kubernetes deployment are motivated by these threat models as well as the need to minimize “blast radius.”
In a Kubernetes environment, the components that are accessible externally will be exposed to external attacks. Those components can include the application programming interface (API) server, kubelet and etcd . (See The New Stack’s ebook, “ The State of the Kubernetes Ecosystem ,” to review the components in a Kubernetes node.)
To alleviate the threat of external attacks, ensure that only the necessary Kubernetes services are exposed and no more. Always enforce authentication and configure the right network security policies for any exposed services.
Ultimately, Kubernetes manages workloads running in containers. If a container is compromised, the concern is whether the container can escalate privileges to take control of other containers or the cluster.
Kubernetes’ isolation mechanisms, such as namespaces or network segmentation, as well as some of the built-in, OS-level controls regulating what the container can access, can help limit the impact of compromised containers. One other control users should pay attention to is the ability to limit the number of containers that can run in a privileged mode — if a privileged container is compromised, it will be able to do much more harm than a normal container.
When legitimate user credentials have been compromised, you may have a malicious user in the system. It is critical, therefore, to properly regulate and limit a user’s access to cluster resources and to closely monitor user actions.
To reduce the impact of malicious users, you need to enforce least-privilege access, role-based access control or other fine-grained access controls.
If the system is not configured correctly, it could lead to misuse of user privileges. For instance, if network policies do not restrict access between pods or namespaces, a user might be able to read traffic for other namespaces that he or she should not have access to in the first place.
A major defense against misuse of privileges is proper hardening. Ensure that all the system components, such as containers, pods, namespaces and kubelets, are hardened to significantly reduce the possibility of privilege misuse.
Another important defense is authorization control. Kubernetes supports a plugin architecture, which allows sophisticated authorization logic to be included. Design and implement authorization correctly; it’s one of the most effective weapons against privilege misuses.
With the threat model in mind, next time we will explore Kubernetes security along four major tenets: authentication and authorization; resource isolation; hardening and network security; and logging and auditing.