Kubernetes Security Context is a feature that enables the configuration of permission and security settings for pods and containers within a Kubernetes cluster. These settings allow cluster administrators to control security-sensitive aspects of the container runtime environment. This is particularly crucial in a multi-tenant cluster environment, where isolation between different users’ workloads is essential.
Security Contexts are defined in the pod manifest (YAML configuration file) and can include various options like setting the User and Group ID for processes inside the containers, defining privilege and access control settings, and configuring capabilities and security policies. These settings ensure that pods and containers operate under specific security constraints, reducing the risk of security breaches and maintaining the principle of least privilege.
In this article:
In Kubernetes, there are two types of Security Contexts: internal and external.
Essentially, an internal Security Context is a way to define certain permissions for pods and containers, while an external Security Context lets you integrate Kubernetes with security tools deployed on your Kubernetes nodes.
RBAC is a method of regulating access to computer or network resources based on the roles of individual users within an organization. Kubernetes has built-in RBAC functionality, allowing you to control who can access the Kubernetes API and what permissions they have.
Pod Security Policies are a cluster-level resource that controls the security-sensitive aspects of the pod specification. They enforce certain security practices across your entire cluster, such as preventing pods from running as root or restricting the types of volumes that pods can use. As of Kubernetes 1.21, Pod Security Policies are considered deprecated (although they can still be used).
While RBAC and Pod Security Policies focus on access control and enforcing security practices at the cluster level, Kubernetes Security Context is more granular. It allows you to specify security settings at the pod or container level, such as the user and group IDs that the container should run as, the capabilities that the container can have, and more.
Here are a few of the security options and configurations provided by the Security Context mechanism.
User and group settings dictate the user and group IDs that the container should run as. By default, containers run as the root user, which has full administrative privileges. This can be a security risk, as any process that can exploit the container can potentially gain root access to the host system.
By using the user and group settings in a Kubernetes Security Context, you can specify a non-root user and group for your containers to run as. This reduces the potential damage that an exploited container can do.
Capabilities are a set of privileges that can be granted to a process in a Linux system. In Kubernetes, you can use the capabilities settings in a Security Context to add or remove specific capabilities for a container.
For example, you can give a container the CAP_NET_RAW capability to allow it to use raw sockets, or you can remove the CAP_CHOWN capability to prevent it from changing the owner of files.
The fsGroup setting in a Kubernetes Security Context specifies a group ID that should be associated with any volumes that the container mounts. This allows the group to read and write to the volume, even if the volume’s filesystem does not natively support POSIX ownership or permissions.
The readOnlyRootFilesystem flag in a Kubernetes Security Context dictates whether the container’s root filesystem should be read-only. If this flag is set to true, the container will not be able to write to its root filesystem. This can be useful for containers that do not need to write data to their root filesystems and can help prevent malicious processes from modifying the filesystem.
The AllowPrivilegeEscalation flag in a Kubernetes Security Context controls whether a process can gain more privileges than its parent process. If this flag is set to false, a process within the container cannot gain additional privileges, effectively preventing privilege escalation attacks.
Related content: Read our guide to Kubernetes security checklist
The first step is to define the Security Context in your Pod’s specification. You can do this by adding the securityContext field in your Pod’s specification.
Here is a simple example:
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
runAsUser: 1000
runAsGroup: 3000
fsGroup: 2000
volumes:
- name: sec-ctx-vol
emptyDir: {}
containers:
- name: sec-ctx-demo
image: gcr.io/google-samples/node-hello:1.0
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false
In this example, the Pod runs as user 1000, group 3000, and with an fsGroup of 2000. Additionally, the allowPrivilegeEscalation field in the container’s Security Context is set to false, preventing the processes from gaining more privileges than their parent process.
After you’ve defined the Security Context, you can apply it using the kubectl apply command:
kubectl apply -f pod-security-context.yaml
This command creates the Pod with the Security Context you’ve specified.
Here are a few important limitations you should be aware of when using Kubernetes Security Contexts:
In Kubernetes, the Security Context settings are based on Linux capabilities and do not translate directly to Windows. This means that if you are running Windows containers, you cannot use many of the features provided by Kubernetes Security Contexts.
However, there are alternatives. For example, you can use Windows-specific security features such as the Run as User feature to control the user identity used to run the container. Also, Kubernetes has been making efforts to provide better support for Windows containers, and there should be improvements in the future.
Another limitation of Kubernetes Security Contexts is that they are limited to Pod and container-level security. This means that they cannot be used to enforce security policies at a higher level, such as the cluster level.
To mitigate this limitation, you can use Kubernetes Network Policies to enforce network-level security policies. Additionally, you can use other Kubernetes security features such as Role-Based Access Control (RBAC). Another option is Pod Security Policies, which also operate at the cluster level, but are deprecated and currently not recommended for use.
In many cases, it can be inefficient to manage Security Contexts at scale. This is especially true if you have a large number of pods or containers.
To overcome this limitation, you can use automation tools such as Helm or Kubernetes Operators. These tools allow you to manage your Kubernetes resources more efficiently, including Security Contexts.
Related content: Read our guide to Kubernetes security policy
Tigera’s commercial solutions provide Kubernetes security and observability for multi-cluster, multi-cloud, and hybrid-cloud deployments. Both Calico Enterprise and Calico Cloud provide the following features for security and observability:
Security
Observability
Next steps:
Get updates on blog posts, workshops, certification programs, new releases, and more!
