Strengthen Your Kubernetes Security with SecurityContext Settings

In Kubernetes, a pod is the smallest deployable unit that can be created and managed. Pods are generally designed to run a single container, but can also run multiple containers if needed. Running a pod without defining a security context can pose a security risk in a Kubernetes cluster. When a pod is created without a security context, it inherits the security context of its parent namespace, which may not provide adequate security measures. Without these measures, the pod can potentially gain access to the host system’s resources and perform malicious activities, such as modifying or deleting sensitive files, accessing other pods and even taking over the entire cluster. In addition, if the pod runs as the root user and has unrestricted access to the host filesystem, it can easily compromise the security of the entire cluster. SecurityContext settings can be used to enhance the security of pods in a Kubernetes cluster. SecurityContext is a field in the pod specification that allows you to specify security-related settings for the pod and its containers. It defines privilege and access control settings for a pod or container. You can use SecurityContexts to define how individual pods and containers will interact with the host machine.

SecurityContext Options

The securityContext field allows you to set various security-related options for the containers within a pod. Some of the options that can be set include:

• runAsUser: Sets the user ID (UID) that the container should run as. This can help to prevent privilege escalation attacks.
• runAsGroup: Sets the group ID (GID) that the container should run as.
• capabilities: Specifies the Linux capabilities that the container should have.
• privileged: Indicates whether the container should be run in privileged mode or not.
• seLinuxOptions: Specifies the SELinux context that the container should run with.
• fsGroup: Sets the GID that the container’s filesystem should be owned by.

To gain a deeper understanding of how the securityContext options behave in different situations, refer to the official Kubernetes documentation. It outlines the intended behavior of each option, taking into consideration various factors such as the underlying operating system and container runtime being used, as well as the configuration of the Kubernetes cluster itself. By studying the documentation, you can gain insights into how these options can provide additional security controls for containers running within a Kubernetes pod. However, misconfiguring these options can lead to unintended consequences, such as preventing a container from running correctly or opening up security vulnerabilities, so read carefully and follow best practices when setting up these security controls.

Why Setting Security Contexts Matters

Specifying a security context for a pod or container is important because it allows you to set various security-related settings such as runAsUser, runAsGroup, fsGroup, and others. These settings help to ensure that containers run in a secure environment with minimal privileges, reducing the risk of unauthorized access or malicious activity. The runAsUser field specifies the user ID under which the container’s process should run. This helps to prevent the container from running as the root user, which would give it unrestricted access to the host system. If left unspecified, the container will run as the default user specified in the image metadata, which could potentially be a privileged user. Similarly, the runAsGroup field specifies the group ID under which the container’s process should run. If left unspecified, the GID will default to 0, which is the root ID, meaning that the container will have permission to read files owned by the root user. By specifying a non-root group ID, the container’s access to sensitive files can be further restricted. The fsGroup field specifies the group ID that should own the volumes mounted by the container. This ensures that the container can access only the files that it needs to, and not all files on the host system. If the runAsGroup field is not specified and the container runs as the default user ID, there is still a security vulnerability within the configuration. This is because the container could potentially access files owned by the root user, which could lead to sensitive information being compromised or the container being able to perform unauthorized actions on the host system. To avoid these scenarios, always specify the appropriate values for runAsUser, runAsGroup, and fsGroup in order to maintain the security of the container and the host system.

How to Define a SecurityContext

To use SecurityContext settings, you need to specify them in the pod specification. For example, to specify a non-root user to run the container as, you can use the following YAML snippet, which  includes runAsUser, runAsGroup, and fsGroup as part of a security context: This YAML code defines a Kubernetes pod with one container named `my-container`. The securityContext field is defined at the pod level and specifies that the container should be run with a non-root user ID of 1000, a group ID of 2000, and a file system group of 3000. The volumes field defines a volume named `my-volume`, which is an empty directory. Under the containers field, the my-container container is defined with an image `my-image`. It also specifies that the my-volume volume should be mounted at `/data` within the container. The securityContext field is also defined at the container level and specifies that allowPrivilegeEscalation is `false`. This means that the container process will not be able to gain additional privileges beyond what was specified in the securityContext field at the pod level. This field sets the security context for the specific container within the pod and this will overwrite the security context for the pod if they conflict. For example, we could define that the pod operates under a GroupID of `3000` while the container within the pod operates under the GroupID of `4000`. Here we are setting the allowPrivilegeEscalation field to `false`, so the container is prevented from gaining privileges higher than the pod it’s running in.

Conclusion

By default, when you don’t set security contexts for your pods, they run as root, which is what you don’t want. If the microservice is exploited and the attacker gains control of the container, they can now get into the host system as root and start reading whatever they want. Make sure you include runAsUser, runAsGroup and fsGroup in every security context, to ensure that the principle of least privilege is followed throughout all layers of the infrastructure, to prevent sneaky vulnerabilities. Don’t leave anything to chance — and don’t let any root users run your containers.