If you’re looking to take your Kubernetes security to the next level, you’ll want to start working with pod security policies. Here’s a quick introduction to this feature.
Kubernetes is an incredibly powerful container management tool. If you’ve worked with containers long enough, you know that security has to take a central role in the deployment of your apps and services. Without locking down those containers, havoc could be wreaked on your network.
You certainly don’t want that.
So, what can you do? With Kubernetes you should consider establishing pod security policies.
SEE: 10 things companies are keeping in their own data centers (TechRepublic download)
What is a pod?
If you’re new to Kubernetes, you might not know what a pod is. Simply stated, a Kubernetes pod is a collection of processes that make up a container, such as:
In other words, a pod is a unit of deployment–either a single container or a number of containers working together.
Now that you understand what a pod is, let’s see what we can do about crafting a security policy.
What is a pod security policy?
The Kubernetes pod security policy is a resource that controls the security of a pod specification. Using the PodSecurityPolicy object definition, you can control things like:
The ability to run privileged containers
Access to volume types
Access to host file systems
Usage of host networking
But how to define the policy? As with almost everything in Kubernetes, this is defined within a YAML file.
How to create a Kubernetes pod security policy
Let’s create a Kubernetes pod security policy that prevents the creation of privileged pods and controls access to volumes. First, we must create the YAML file. From a terminal window, issue the command:
In that file, paste the following:
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: psp spec: privileged: false seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny volumes: - '*'
In that file, we prevent privileged pods from being created with the line:
We also allow the following (via the RunAsAny rule):
SeLinux – allows any user to control SELinux within pods
Linux groups – supplemental Groups
runAsUser – allows users to run container entry points with a different username
fsGroup – volumes which support ownership management
Save and close the file.
Now we have to apply the policy. This is done with the command:
kubectl apply -f psp.yaml
The command will report back:
At any time, you can modify the policy YAML file and run the same command to re-configure the policy.
Check to make sure your policy is available by issuing the command:
kubectl get psp
The output will list the details for the policy (Figure A).
How to assign a Kubernetes pod security policy
Now that you’ve created your policy, how do you assign it? This is done using Role Based Access Control (RBAC). Create an RBAC configuration for the policy with the command:
In that file, paste the following:
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: psp:psp rules: - apiGroups: - extensions resources: - podsecuritypolicies resourceNames: - psp verbs: - use --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: psp:psp subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: psp:psp apiGroup: rbac.authorization.k8s.io
The above file will create a cluster-wide role named psp that can use our new policy we named psp. This will also create a cluster-wide role binding which gives access to the psp:psp role to every authenticated user.
Save and close the file. Create this policy with the command:
kubectl apply -f rbac-psp.yaml
We’ve now created a policy and an RBAC control. Let’s find out if we’re now able to use this new policy. Issue the command:
kubectl auth can-i use psp/psp
The output should say “yes.”
Of course, it should say “yes,” as I am an admin user. But what if we test it with any user? Do that with the command:
kubectl auth can-i use psp/psp --as-group=system:authenticated --as=any-user
You should now see “no” in the response.
You’ve just created a Kubernetes pod security policy, assigned it with RBAC, and tested it to make sure the policy actually works. You’re one step closer to gaining more security with your Kubernetes container deployments.