As an orchestration platform, Kubernetes impacts many runtime security functions. These include authentication, authorization, logging and resource isolation, as well as more advanced implications such as workload placement and network segmentation.

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.

Kubernetes Threat Models

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 the Kubernetes environment, there are generally four types of threats that apply regardless of the deployment model (with some edge case exceptions):

  1. External attacks aiming to compromise Kubernetes controls: This threat exists for all connected systems. In the context of a Kubernetes cluster, this represents attackers gaining access to the system or compromising certain controls that will impact the security of the system.
  2. Compromised containers or nodes: If there are malicious containers within the Kubernetes-controlled environment, or malicious nodes within a cluster, what is the impact to the rest of the nodes or the cluster? Can you effectively contain the “blast radius” both on the node and within a cluster?
  3. Compromised credentials: What happens when a Kubernetes administrator’s credential is compromised? How much does that affect the cluster?
  4. Misuse of legitimate privileges: This could happen when systems are misconfigured, controls are lacking or operations are not closely monitored.
Read More:   Update MongoDB Grabs WiredTiger and its Talent, Including Sleepycat Software’s Co-Founder and Lead Architect

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.

[cycloneslider id=”kubernetes-series-book-2-sponsors”]

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.”

External Attacks

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 InApps Technology’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.

Compromised Containers

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.

Compromised Credentials

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.

Read More:   Update It’s Mesos’ SMACK Stack versus Kubernetes’ Smart Clusters for Hosting Spark

To reduce the impact of malicious users, you need to enforce least-privilege access, role-based access control or other fine-grained access controls.

Misuse of Privileges

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.

Feature image by Yannick Pulver on Unsplash.