Securing Kubernetes with Security Contexts

Introduction
A security context allows you to set access control for pods, as well as containers
and volumes in pods, when applicable. Examples of access controls that can be set
with security contexts include:
• The user ID and group IDs of the first process running in a container
• The group ID of volumes
• If a container's root file system is read-only
• Security Enhanced Linux (SELinux) options
• The privileged status of containers, which allows the container to do almost
everything root can do on the host, if enabled
• Whether or not privilege escalation, where child processes can have more
privileges than their parent, is allowed
When a security context field is configured for a pod and one of the pod's
containers, the container's setting takes precedence. Configuring the security
context of pods and containers can greatly reduce the security risk posed by using
third-party images.
In this lab step, you will review the available options for configuring security
contexts. You will then create multiple pods with differing security contexts
to observer the effects of each.
Copy code
watch kubectl get nodes

Instructions
1. Explain the available pod-level security context fields:
Copy code
kubectl explain pod.spec.securityContext
© Kranthi putti
linkedin.com/in/kranthi-putti
Briefly read through each of the fields to get an understanding of what each can be
used for.
2. Explain the available container-level security context fields:
Copy code
kubectl explain pod.spec.containers.securityContext

Briefly read through each of the fields to get an understanding of what each can be
used for.
3. Create the following pod resource YAML file:
Copy code
cat > pod.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
name: security-context-test-1
namespace: test
spec:
containers:
- image: busybox
name: busybox
args:
- sleep
- "3600"
EOF
kubectl run busybox --image=busybox
The pod simply runs a container that sleeps.
4. Create the pod and use exec to list the available devices in the container:
Copy code
kubectl create namespace test
kubectl create -f pod.yaml
kubectl exec -n test security-context-test-1 -it -- ls /dev

There are only a minimal number of devices available in the container and none
that can do any harm. For the sake of what you will do next, notice there are no
block devices. In particular, there is no /nvme0n1p1 device that is the host's file
system disk.
If you get an error running the exec command, wait until the container starts to
try again
5. Create a similar pod that has a privileged container:
Copy code
kubectl delete -f pod.yaml
cat > pod.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
name: security-context-test-2
namespace: test
spec:
containers:
- image: busybox
name: busybox
args:
- sleep
- "3600"
securityContext:
privileged: true
EOF
kubectl create -f pod.yaml

Note the securityContext field included in the spec.

All of the host devices are available including the host file system
disk /nvme0n1p1.
8. Mount the host's file system and read a file from it:
Copy code
mkdir /hd
mount /dev/nvme0n1p1 /hd
cat /hd/etc/kubernetes/kubelet.conf
exit

In this example, the output file is a kubeconfig file that is created during cluster
initialization. With the kubeconfig file and the certificate and key files that it
references with the client-certificate and client-key fields (you also have access
to those files), you can connect to the Kubernetes cluster and perform
arbitrary operations. Using privileged containers introduces several other security
vulnerabilities, and is equivalent to granting root access to the host.
To avoid the potential downfalls of privileged containers, there are several best
practices including:
• Avoid using privileged containers, and ensure any third-party Kuberentes
templates you use do not stealthily grant privileged access
• Use RBAC to prevent users and service accounts from using exec or attach
(the relevant RBAC resources are pod/exec and pod/attach)
• Use a trusted image registry
• Enable PodSecurityPolicies, opens in a new tab to enforce all containers
running in unprivileged mode
• Do not run containers as the root user (the following instructions illustrate
this)
9. Create another pod that includes a pod security context as well as a container
security context:
Copy code
kubectl delete -f pod.yaml
cat > pod.yaml <<EOF
apiVersion: v1
kind: Pod
metadata:
name: security-context-test-3
namespace: test
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000
containers:
- image: busybox
name: busybox
args:
- sleep
- "3600"
securityContext:
runAsUser: 2000
readOnlyRootFilesystem: true
EOF
kubectl create -f pod.yaml
The pod security context enforces that container processes do not run as root
(runAsNonRoot) and sets the user ID of the container process to 1000. The
container securityContext sets the container process' user ID to 2000 and sets the
root file system to read-only.
10. Open a shell in the container:
Copy code
kubectl exec -n test security-context-test-3 -it -- /bin/sh

Notice that the shell prompt is $ and not # indicating that you are not the root
user.
11. List the running processes in the container:
Copy code
ps
The USER ID is 2000 illustrating that it is not root and that the container security
context overrides the setting in the pod security context when both security
contexts include the same field. Whenever possible you should not run as root.
12. Attempt to create a file in the /tmp directory:
Copy code
touch /tmp/test-file
exit

The attempt fails due to the Read-only file system. When possible, it is best to
use read-only root file systems to harden your container environments. A best
practice is to use volumes to mount any files that require modification, allowing
the root file system to be read-only.
Summary
In this lab step, you understood the use and capabilities of pod and container
security contexts. You also learned about potential risks and how to protect your
cluster from them.
© Kranthi putti
linkedin.com/in/kranthi-putti