« Previous 1 2 3 4
Secure access to Kubernetes
Avoiding Pitfalls
Access Control
The last aspect is to control the content of a query. Kubernetes provides a long list of admission controllers that monitor and control very different things. Without changing the configuration, the controllers listed in the "Admission Controller" box are enabled.
Admission Controllers
NamespaceLifecycle
LimitRanger
ServiceAccount
TaintNodesByCondition
Priority
DefaultTolerationSeconds
DefaultStorageClass
StorageObjectInUseProtection
PersistentVolumeClaimResize
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
RuntimeClass
ResourceQuota
The Kubernetes documentation contains a description stating which controller implements which logic and what the configuration looks like [4]. Some of the plugins require their own configuration files or a YAML block in the cluster configuration.
One interesting example is LimitRanger
, which limits resources (e.g., CPU, memory usage) for a namespace. This plugin modifies running requests with default values. This happens, for example, if a pod definition does not specify how much CPU or memory it can request. In this way, the cluster admin can manage the extent to which resources are used by a customer or a namespace.
Optionally, an admission controller named PodSecurityPolicy
can be added [5] that increases security by insisting that pods generated by the system by replica sets and deployments comply with certain security policies. Among other things, it can restrict Linux capabilities, define SE Linux contexts and AppArmor profiles for containers, or regulate the handling of privileges (Figure 4).
Conclusions
Because Kubernetes makes all operations available through an API, it offers admins maximum flexibility. This pattern also continues in the security infrastructure. Rolling out even more complex environments with dedicated security configurations is a simple and unambiguous process controlled by YAML files, which, however, does not release the developer from having to think about how to use these possibilities sensibly. On the upside, it opens up an opportunity to set effective standards in a centralized location.
The access controls shown in the article only illustrate the first step toward establishing security. Cluster admins also need to pay attention to the integrity and security of the images used. Images can contain security holes and are a potential gateway for rootkits. Also, the possibilities for container users to escalate their privileges are a permanent security issue.
What happens in practice if the deployment of a rolled out project fails because of security settings? This situation is not much different from what has happened with other IT security components (e.g., firewalls) in the last 20 years. IT security managers must therefore familiarize themselves with what can be the complex security contexts of Kubernetes systems. The design allows for secure operations but does not relieve admins from the burden of thinking.
Infos
- Access control in Kubernetes: https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
- Kubernetes documentation: https://kubernetes.io/docs/
- OAuth 2.0: https://oauth.net/2/
- Admission controllers: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
- PodSecurityPolicy: https://kubernetes.io/docs/concepts/policy/pod-security-policy/
« Previous 1 2 3 4
Buy this article as PDF
(incl. VAT)