Now, let's try this with a cluster that can utilize PodSecurityPolicies. If you are using GKE, it is quite easy to create a cluster with PodSecurityPolicy enabled. Note you will need the Beta APIs enabled for this:
$ gcloud beta container clusters create [Cluster Name] --enable-pod-security-policy --zone=[Zone To Deply Cluster]
For clusters created with kube-up, like we saw in Chapter 1, Introduction to Kubernetes, you'll need to enable the admission controller on the API server. Take a look here for more information: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#enabling-pod-security-policies.
Once you have PodSecurityPolicy enabled, you can see the applied policies by using the following code:
$ kubectl get psp
You'll notice a few predefined policies that GKE has already defined. You can explore the details and the YAML used to create these policies with the following code:
$ kubectl get psp/[PSP Name] -o yaml
It's important to note that PodSecurityPolicies work with the RBAC features of Kubernetes. There are a few default roles, role bindings, and namespaces that are defined by GKE. As such, we will see different behaviors based on how we interact with Kubernetes. For example, by using kubectl in a GCloud Shell, you may be sending commands as a cluster admin and therefore have access to all policies, including gce.privileged. However, using the kubectl run command, as we did previously, will invoke the pods through the kube-controller-manager, which will be restricted to the policies bound to its role. Thus, if you simply create a pod with kubectl, it will create it without an issue, but by using the run command, we will be restricted.
Sticking to our previous method of using kubectl run, let's try the same deployment as the preceding one:
$ kubectl run myroottest --image=jonbaier/node-express-info:latest
Now, if we follow this with kubectl get pods, we won't see any pods prefaced with myroottest. We can dig a bit deeper by describing our deployment:
$ kubectl describe deployment myroottest
By using the name of the replica set listed in the output from the preceding command, we can then get the details on the failure. Run the following command:
$ kubectl describe rs [ReplicaSet name from deployment describe]
Under the events at the bottom, you will see the following pod security policy validation error:
Again, because the run command uses the controller manager and that role has no bindings that allow the use of the existing PodSecurityPolicies, we are unable to run any pods.
Understanding that running containers securely is not merely the task of administrators adding constraints is important. The work must be done in collaboration with developers, who will properly create the images.
You can find all of the possible parameters for PodSecurityPolicies in the source code, but I've created the following table for convenience. You can find more handy lookups like this on my new site, http://www.kubesheets.com:
|
Parameter |
Type |
Description |
Required |
|
Privileged |
bool |
Allows or disallows running a pod as privileged. |
No |
|
DefaultAddCapabilities |
[]v1.Capaility |
This defines a default set of capabilities that are added to the container. If the pod specifies a capability drop that will override, then add it here. Values are strings of POSIX capabilities minus the leading CAP_. For example, CAP_SETUID would be SETUID (http://man7.org/linux/man-pages/man7/capabilities.7.html). |
No |
|
RequiredDropCapabilities |
[]v1.Capaility |
This defines a set of capabilities that must be dropped from a container. The pod cannot specify any of these capabilities. Values are strings of POSIX capabilities minus the leading CAP_. For example, CAP_SETUID would be SETUID (http://man7.org/linux/man-pages/man7/capabilities.7.html). |
No |
|
AllowedCapabilities |
[]v1.Capaility |
This defines a set of capabilities that are allowed and can be added to a container. The pod can specify any of these capabilities. Values are strings of POSIX capabilities minus the leading CAP_. For example, CAP_SETUID would be SETUID (http://man7.org/linux/man-pages/man7/capabilities.7.html). |
No |
|
Volumes |
[]string |
This list defines which volumes can be used. Leave this empty for all types (https://github.com/kubernetes/kubernetes/blob/release-1.5/pkg/apis/extensions/v1beta1/types.go#L1127). |
No |
|
HostNetwork |
bool |
This allows or disallows the pod to use the host network. |
No |
|
HostPorts |
[]HostPortRange |
This lets us restrict allowable host ports that can be exposed. |
No |
|
HostPID |
bool |
This allows or disallows the pod to use the host PID. |
No |
|
HostIPC |
bool |
This allows or disallows the pod to use the host IPC. |
No |
|
SELinux |
SELinuxStrategyOptions |
Set it to one of the strategy options, as defined here: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#selinux. |
Yes |
|
RunAsUser |
RunAsUserStrategyOptions |
Set it to one of the strategy options, as defined here: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups. |
Yes |
|
SupplementalGroups |
SupplementalGroupsStrategyOptions |
Set it to one of the strategy options, as defined here: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#users-and-groups |
Yes |
|
FSGroup |
FSGroupStrategyOptions |
Set it to one of the strategy options, as defined here: https://kubernetes.io/docs/user-guide/pod-security-policy/#strategies |
Yes |
|
ReadOnlyRootFilesystem |
bool |
Setting this to true will either deny the pod or force it to run with a read-only root filesystem. |
No |
|
allowedHostPaths
|
[]AllowedHostPath |
This provides a whitelist of host paths that can be used at volumes. |
No |
|
allowedFlexVolumes |
[]AllowedFlexVolume |
This provides a whitelist of flex volumes that can be mounted. |
No |
|
allowPrivilegeEscalation |
bool |
This governs where setuid can be used to change the user a process is running under. Its default is true. |
No |
|
defaultAllowPrivilegeEscalation |
bool |
Sets the default for allowPrivilegeEscalation. |
No |