Skip to main content
In this article, we address common questions about managing security contexts for pods and containers in Kubernetes. Learn how to verify which user is executing a process, modify pod configurations to run under a specific user ID, and adjust container capabilities. These step-by-step examples are designed to help you secure your containerized applications effectively.

​
1. Checking the User Running the Sleep Process in the Ubuntu Sleeper Pod

To verify which user is running the sleep process in your Ubuntu sleeper pod, follow these steps:
  1. List the running pods to identify the pod name.
  2. Execute the command inside the pod using the whoami command to check the current user.
Execute the following commands:
The output confirms that the sleep process is running as the root user:
If you see root as the output, it indicates that no user override has been set, and the container is running with root privileges.

​
2. Updating the Ubuntu Sleeper Pod to Run with User ID 1010

To update the pod so that the sleep process is executed as user ID 1010, proceed as follows:
  1. Retrieve the current pod configuration and write it to a file:
  2. Open the ubuntu-sleeper.yaml file in your preferred text editor.
  3. Locate the securityContext section and add or update the runAsUser field to 1010.
  4. Save your changes.
  5. Delete the existing pod. Using the --force flag can expedite deletion:
  6. Reapply the modified configuration file:
After reapplying, validate that the pod now runs with user ID 1010.

​
3. Analyzing a Multi-Container Pod Definition

Consider a pod definition file named multi-pod.yaml that includes multiple containers with different security contexts set at the pod and container levels. Below is the configuration snippet:

​
Q1: With which user does the web container run?

  • The pod-level context sets runAsUser: 1001, but the web container’s own security context overrides this with runAsUser: 1002.
  • Answer: The web container runs as user 1002.

​
Q2: With which user does the sidecar container run?

  • The sidecar container does not have a specified security context. It inherits the pod-level setting.
  • Answer: The sidecar container runs as user 1001.
For more details on Kubernetes security contexts, check out the Kubernetes Documentation.

​
4. Configuring the Ubuntu Sleeper Pod to Run as Root with SYS_TIME Capability

To update the Ubuntu sleeper pod so that it runs as root with the additional SYS_TIME capability, follow these instructions:
  1. Open the existing configuration file (ubuntu-sleeper.yaml).
  2. Remove any lines in the security context that force the pod to run as a non-root user.
  3. Add a container-level security context that specifies the SYS_TIME capability. Your updated configuration should resemble the following:
  1. Save the changes.
  2. Delete the existing pod using:
  3. Reapply the updated configuration:
Ensure the pod is running with the SYS_TIME capability as expected.

​
5. Adding the NET_ADMIN Capability to the Ubuntu Sleeper Pod

To enhance the Ubuntu sleeper pod so that it includes both the SYS_TIME and NET_ADMIN capabilities, update the configuration file as follows:
  1. Open the ubuntu-sleeper.yaml file.
  2. Locate the container’s securityContext section that defines the capabilities.
  3. Modify the capabilities to include both SYS_TIME and NET_ADMIN:
  1. Save the file.
  2. Delete the current pod:
  3. Apply the new configuration:
After these steps, verify that the pod runs with both the SYS_TIME and NET_ADMIN capabilities enabled.
You have now successfully adjusted the security contexts for your Ubuntu sleeper pod. This guide covered verifying container users, configuring pods to run with specific user IDs, and modifying container capabilities to enhance security.
For further reading on Kubernetes security best practices, visit the Kubernetes Security Documentation.

Watch Video