Pod security policies and context

One of the latest additions to the Kubernetes' security arsenal is that of pod security policies and contexts. These allow users to control users and groups for container processes and attached volumes, limit the use of host networks or namespaces, and even set the root filesystem to read-only. Additionally, we can limit the capabilities available and also set SELinux options for the labels that are applied to the containers in each pod. 

In addition to SELinux, Kubernetes also added beta support for using AppArmor with your pods by using annotations. For more information, refer to the following documentation page: https://kubernetes.io/docs/admin/apparmor/.

PodSecurityPolicies are enforced using the admission controller we spoke of earlier in this book. By default, Kubernetes doesn't enable PodSecurityPolicy, so if you have a GKE cluster running, you can try the following:

$ kubectl get psp

You should see 'No resources found.', assuming you haven't enabled them. 

Let's try an example by using the Docker image from our previous chapters. If we use the following run command on a cluster with no PodSecurityPolicy applied, it will happily run:

$ kubectl run myroottest --image=jonbaier/node-express-info:latest

Follow this with kubectl get pods and in a minute or so we should see a pod starting with myroottest in the listings. 

Go ahead and clean this up with the following code before proceeding:

$ kubectl delete deployment myroottest
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.59.173.103