- User and Group Settings
- Capabilities Settings
- fsGroup Settings
- readOnlyRootFilesystem Flag
- AllowPrivilegeEscalation Flag
- No Windows Support
- Limited to Pod/Container-Level Security
- Inefficient Tooling
Kubernetes Internal vs. External Security Contexts
In Kubernetes, there are two types of Security Contexts: internal and external.
- Internal Security Contexts are those that are defined within the pod or container itself. They are specified in the pod’s YAML configuration file, and can include settings for running the pod or container as a non-root user, limiting the system calls the pod or container can make, and so on.
- External Security Contexts are defined outside of the pod or container. They are defined and enforced by security software on the Linux host (the Kubernetes node), which might be SELinux or AppArmor.
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.
Kubernetes Security Context vs. RBAC vs. Pod Security Policies: What Is the Difference?
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.
Kubernetes Security Context Options
Here are a few of the security options and configurations provided by the Security Context mechanism.
User and Group Settings
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 Settings
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.
fsGroup Settings
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.
readOnlyRootFilesystem Flag
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.
AllowPrivilegeEscalation Flag
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
Tutorial: How to Set an Internal Security Context For a Pod
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.
Limitations of Kubernetes Security Contexts
Here are a few important limitations you should be aware of when using Kubernetes Security Contexts:
No Windows Support
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.
Limited to Pod/Container-Level Security
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.
Inefficient Tooling
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
Kubernetes Security and Observability with Calico
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 policy preview, staging, and recommendation – Easily make self-service security policy changes to a cluster without the risk of overriding an existing policy. Calico can auto-generate a recommended policy based on ingress and egress traffic between existing services, and can deploy your policies in a “staged” mode before the policy rule is enforced.
- Namespace Isolation – By default, any workload can communicate with any other workload within a cluster. With Calico’s policy recommendation, you can do namespace isolation out of the box with a single click.
- Compliance reporting and alerts – Continuously monitor and enforce compliance controls, easily create custom reports for audit.
- Microsegmentation across Host/VMs/Containers – Deploy a scalable, unified microsegmentation model for hosts, VMs, containers, pods, and services that works across all your environments.
- Data-in-transit encryption – Protect sensitive data and meet compliance requirements with high-performance encryption for data-in-transit.
- Dynamic Service Graph – Get a detailed runtime visualization of your Kubernetes environment to easily understand microservice behavior and interaction.
- Application Layer Observability – Gain visibility into service-to-service communication within your Kubernetes environment, without the operational complexity and performance overhead of service mesh.
- Dynamic Packet Capture – Generate pcap files on nodes associated with pods targeted for packet capture, to debug microservices and application interaction.
- DNS Dashboard – Quickly confirm or eliminate DNS as the root cause for microservice and application connectivity issues in Kubernetes.
- Flow visualizer – Get a 360-degree view of a namespace or workload, including analytics around how security policies are being evaluated in real time and a volumetric representation of flows.
Next steps:
- Read our guide: What is network policy?
- Read our guide: Kubernetes observability
- Read our O’Reilly book: Kubernetes Security and Observability (free download)
