Kubernetes security is supported by some built-in core features, but it must be complemented to fill in gaps that can emerge from a variety of risks.
As organizations make greater use of containers, they must consider Kubernetes security. How secure is Kubernetes? That’s a simple question with no simple answer.
In some respects, Kubernetes is very secure. It offers a variety of built-in security tools, and it integrates easily with third-party security platforms.
Yet on its own, Kubernetes suffers from some significant security risks. There are major gaps within the native security functionality that Kubernetes provides out of the box.
Securing Kubernetes, then, requires understanding which types of security features Kubernetes provides natively and which functionality you need to build in yourself.
See also: Modern Applications Must Consider Container Security Risks
Kubernetes security features
Kubernetes provides four main types of security tooling as part of the core platform:
- Pod security policies: Kubernetes provides a framework for defining so-called pod security policies. These policies can enforce rules such as preventing containers from running in privileged mode or which resources they can access.
- Role-based access control: Kubernetes’s RBAC framework lets admins configure which actions may be performed by resources running in Kubernetes, based on the role of the resources. Resources could be human users, or they could be applications or services.
- Network policies: Like pod security policies, network policies can define certain restrictions about which activities are allowed on the network. They are useful for isolating containers and hardening internal network communications within a Kubernetes cluster.
- Secrets management: Kubernetes provides a built-in key-value store, etcd, for storing “secrets,” such as passwords and SSH keys, that your applications may need to operate. These secrets can be encrypted.
Together, these tools provide a basic foundation for managing security in Kubernetes and preventing certain types of breaches.
Kubernetes security gaps
You can and should use pod security policies, RBAC policies, network policies, and etcd to help secure Kubernetes clusters.
On their own, however, these tools are hardly sufficient for protection against all types of risks. They do little or nothing to mitigate the following types of threats:
- Breaches on Kubernetes nodes: An attack against the operating system on a node within a Kubernetes cluster could lead to unauthorized access to the cluster or certain resources in it.
- Data encryption: Kubernetes doesn’t automatically encrypt any data that your applications generate or store. It can encrypt secrets, as noted above, that are different from application data, which is where sensitive user information may live.
- Containers: Kubernetes will happily run whichever containers you tell it to run. It won’t scan container images for potential vulnerabilities or detect malicious activity by a container.
Plugging the security gaps
Securing Kubernetes, then, requires admins to take extra steps to address the security gaps described above. There are two main ways to go about that.
The first is to define and enforce best practices in the way you manage clusters and workflows. Practices such as storing secrets data inside a container image or trusting applications to encrypt sensitive data on their own, should be avoided, for example. Requiring kernel-hardening frameworks on Kubernetes nodes and locking down access to nodes at the operating-system level should be embraced.
The second is to leverage external tools that help plug Kubernetes security gaps. Container images scanners will check containers for malware, and they can be integrated into your CI/CD pipeline so that containers are scanned automatically as part of the deployment process. Anomaly detection tools can monitor a Kubernetes cluster for patterns that may indicate a breach or attempted breach.
Such Kubernetes security add-ons are already widely available. They are also increasingly being integrated into larger platforms by large tech vendors that are buying Kubernetes security startups.
In this respect, at least, Kubernetes security is likely to become easier to address over time. But no number of integrations will totally plug all of the gaps. As a Kubernetes admin, it’s your job to be aware of the security vulnerabilities that your software stack isn’t addressing and take steps to make sure you mitigate them.
