Enforce the baseline Pod Security Standard on a namespace (CKS)

In this lesson of the CKS series, you will learn how to enforce the baseline Pod Security Standard on a namespace. One pod in the namespace can access the logs of every other pod on its node, including those of the control plane. To address this security concern, you will label the namespace, preview the impact, and save the event explaining why the pod cannot be recreated.

Pod Security Admission is built into every Kubernetes cluster and can be configured with namespace labels. There are three standards: Privileged allows anything, Baseline blocks known escapes like hostPath volumes, host networking, and privileged containers, and Restricted demands running as non-root. The label pod-security.kubernetes.io/enforce determines what gets rejected. There are also audit and warn modes that only report violations.

In the scenario, you have a Deployment called node-inspector that mounts the node's /var/log/pods folder through a hostPath volume. You will enforce the baseline Pod Security Standard on the namespace, delete the running node-inspector pod, and save the event explaining why it cannot be recreated to pss-denial.log.

Pod Security Admission runs when a pod is created, and already running pods are left alone. The task instructs you to delete the node-inspector pod yourself because Kubernetes won't kill a running workload due to a label change. After applying the baseline enforcement, you will see that node-inspector is still running because enforcement happens at admission, not when a label changes.

To preview the impact, you can use a dry run command with --dry-run=server, which warns about violating the new PodSecurity enforce level and lists the violated pod. Once you're satisfied with the preview, you can enforce the baseline by applying the label to the namespace. The node-inspector pod will still be running because enforcement occurs at admission time.

To delete the node-inspector pod, you can use the kubectl delete command. After deletion, you can verify that the pod has been removed using the kubectl get pods command. Finally, you can save the reason for the pod's failure using the kubectl describe command on the ReplicaSet and save the event with reason FailedCreate to a file named pss-denial.log.