Configuring pod security policies

Why do I set pod security policies?

As a cluster admin, you want to control what happens in your cluster, especially actions that affect the cluster's security or readiness. Pod security policies can help you control usage of privileged containers, root privileges, host networking and ports, volume types, host file systems, Linux capabilities, and more.

With the PodSecurityPolicy admission controller, pod creation is controlled by pod security policies and related role-based access control (RBAC). By default, IBM Cloud Kubernetes Service clusters don't restrict pod creation for any authenticated users or service accounts. To secure your cluster, customize the pod security policies. This customization can have unintended side-effects, so make sure to thoroughly test your customizations. To deploy apps, the user and service accounts must all be authorized by the pod security policies that are required to deploy pods.

Trying to control which users have access to the IBM Cloud Kubernetes Service? See Assigning cluster access to set IBM Cloud IAM and infrastructure permissions.

Are any policies set by default? What can I add?

By default, IBM Cloud Kubernetes Service configures the PodSecurityPolicy admission controller with resources for IBM cluster management that you can't delete or modify. You also can't disable the admission controller.

Pod actions are not locked down by default. Instead, two role-based access control (RBAC) resources in the cluster authorize all administrators, users, services, and nodes to create privileged and unprivileged pods. Additional RBAC resources are included for portability with IBM Cloud Private packages that are used for hybrid deployments.

If you want to prevent certain users from creating or updating pods, you can modify these RBAC resources or create your own.

How does policy authorization work?

When you as a user create a pod directly and not by using a controller such as a deployment, your credentials are validated against the pod security policies that you are authorized to use. If no policy supports the pod security requirements, the pod is not created.

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. If no policy supports the pod security requirements, the controller succeeds, but the pod is not created.

For common error messages, see Pods fail to deploy because of a pod security policy.

Why can I still create privileged pods when I am not part of the privileged-psp-user cluster role binding?

Other cluster role bindings or namespace-scoped role bindings might give you other pod security policies that authorize you to create privileged pods. Additionally by default, cluster administrators have access to all resources, including pod security policies, and so can add themselves to PSPs or create privileged resources.

Modifying the RBAC resources

1. Get the name of the RBAC cluster role binding. The following steps use the privileged-psp-user RBAC as an example, but you can take similar steps for the restricted-psp-user RBAC or custom pod security policies.

   kubectl get clusterrolebinding
   

2. Download the cluster role binding as a .yaml file that you can edit locally.

   kubectl get clusterrolebinding privileged-psp-user -o yaml > privileged-psp-user.yaml
   

   You might want to save a copy of the existing policy so that you can revert to it if the modified policy yields unexpected results.

   Example cluster role binding file

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     creationTimestamp: 2018-06-20T21:19:50Z
     name: privileged-psp-user
     resourceVersion: "1234567"
     selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/privileged-psp-user
     uid: aa1a1111-11aa-11a1-aaaa-1a1111aa11a1
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ibm-privileged-psp-user
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:nodes
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

3. Edit the cluster role binding .yaml file. To understand what you can edit, review the Kubernetes documentation. Example actions:

   • Service accounts: You might want to authorize service accounts so that deployments can occur only in specific namespaces. For example, if you scope the policy to allow actions within the default namespace, the service account can deploy privileged pods in that namespace. However, actions in other namespaces are no longer authorized because you changed the scope from service accounts generally to service accounts specifically in the default namespace.

     Do not scope the policy to namespaces that run system components, such as the kube-system, ibm-system, or ibm-operators namespaces. These namespaces already have their own policies. Changing the system component policies might cause unexpected results, such as all service accounts in all namespaces being able to deploy privileged pods.

     To scope the policy to allow actions in a specific namespace, change the system:serviceaccounts to system:serviceaccount:<namespace>.

     - apiGroup: rbac.authorization.k8s.io
       kind: Group
       name: system:serviceaccounts:default
     

     To scope the policy to multiple namespaces, copy the subject group and update the namespace.

     - apiGroup: rbac.authorization.k8s.io
       kind: Group
       name: system:serviceaccounts:default
     - apiGroup: rbac.authorization.k8s.io
       kind: Group
       name: system:serviceaccounts:test
     

   • Users: You might want to remove authorization for all authenticated users to deploy pods with privileged access. Remove the following system:authenticated entry.

     - apiGroup: rbac.authorization.k8s.io
       kind: Group
       name: system:authenticated
     

4. Create the modified cluster role binding resource in your cluster. Now, any users and service accounts that are not explicitly authorized to the privileged pod security policy can create pods only by using the restricted pod security policy.

   kubectl apply -f privileged-psp-user.yaml
   

5. Verify that the resource was modified.

   kubectl get clusterrolebinding privileged-psp-user -o yaml
   

Deleting RBAC resources

To delete the RBAC resources,

1. Get the name of the RBAC cluster role binding. The following steps use the privileged-psp-user RBAC as an example, but you can take similar steps for the restricted-psp-user RBAC or custom pod security policies.

   kubectl get clusterrolebinding
   

2. Delete the RBAC role that you want to remove. Now, any users and service accounts can create pods only by using the restricted pod security policy.

   kubectl delete clusterrolebinding privileged-psp-user
   

3. Verify that the RBAC cluster role binding is no longer in your cluster.

   kubectl get clusterrolebinding
   

Creating your own pod security policy

To create your own pod security policy resource and authorize users with RBAC, review the Kubernetes documentation.

Make sure that you modified the existing policies so that the new policy that you create does not conflict with the existing policy. For example, the existing policy permits users to create and update privileged pods. If you create a policy that does not permit users to create or update privileged pods, the conflict between the existing and the new policy might cause unexpected results.