Pod security policies in IBM Cloud Kubernetes Service
5 min read
Pod security policies in IBM Cloud Kubernetes Service
You can now use Kubernetes pod security policies in your IBM Cloud Kubernetes Service clusters. These policies enable the cluster administrator to configure who is authorized to create and update pods. For many cluster administrators, this is an important security feature to leverage.
What are pod security policies?
Pod security policies are cluster-level resources that control security sensitive aspects of the pod specification. Running a privileged container is one example. By combining these policies with Kubernetes RBAC, a cluster administrator can control who is authorized to create and update pods that use security sensitive pod specifications.
How do I enable them?
IBM Cloud Kubernetes Service enables pod security policies for you. This is done by enabling the PodSecurityPolicy admission controller and configuring default policies. The default policy configuration is required because without it, pod creation would fail. And since the cluster administrator knows best as to who should be authorized to what, IBM Cloud Kubernetes Service allows access to a privileged policy for those authorized to create pods. Therefore, locking down your cluster’s policies is left as an exercise for the cluster administrator.
How do I configure them?
First of all, read configuring pod security policies before changing the default configuration provided by IBM Cloud Kubernetes Service. Pod security policy support is not available for all releases. Also, certain configurations must be left as-is in order to properly manage your cluster. But for the configurations that you can customize, let’s explore what you could do.
Example
For this example, let’s prevent everyone except the cluster administrator from creating a privileged container in the default
namespace.
Setup
-
Start by downloading and using the Kubernetes configuration for your cluster:
$(bx cs cluster-config <cluster name or ID> | grep export)
-
Save a backup to restore later:
kubectl get clusterrolebinding privileged-psp-user -o yaml > privileged-psp-user.yaml
-
Run
kubectl edit clusterrolebinding privileged-psp-user
and remove allsubjects
entries except for thesystem:masters
entry. The will prevent everyone from creating privileged containers except cluster administrators.
Successful pod creation
Create a privileged container via a Pod
. This should succeed.
Now run kubectl get pods
. You will see the privileged container running.
Failed pod creation
First run kubectl delete pod privileged
to delete the pod. Then create a privileged container via a Deployment
. This should succeed.
Run kubectl get pods
. You will see the privileged container running…nothing. So what happened? Kubernetes used the default
service account credentials in the default
namespace when creating the pod, not your credentials. Run kubectl get events | grep FailedCreate
. You will see that pod creation was forbidden
because the service account was not authorized to any pod security policies allowing creation of a privileged container.
Fix pod creation
Run kubectl edit clusterrolebinding privileged-psp-user
and add a subjects
entry for system:serviceaccounts
. This will authorize all service accounts in all namespace to create a privileged container. Now run kubectl get pods
again, and after a minute or two, you will see the privileged container running. When you create a pod by using a resource controller such as a deployment, Kubernetes validates the pod’s service account credentials against the pod security policies that the service account is authorized to use.
Cleanup
-
Run
kubectl delete deployment privileged
to delete the deployment. -
Restore your backup:
kubectl apply --force=true -f privileged-psp-user.yaml
Next steps
Equipped with the basic knowledge of Kubernetes pod security policies and their configuration in your cluster, it’s time to start applying the policies that meet your requirements. If you have questions or concerns, engage our team in Slack. You can register here and join the discussion in the #kubernetes or #questions channels on https://ibm-container-service.slack.com/.