Use the unprivileged policy¶
To switch users from the privileged policy to the unprivileged
policy, a cluster admin must remove the ClusterRoleBinding that links all
users and service accounts to the privileged policy and then create a
RoleBinding to link users to the alternate policy. A ClusterRole is
already defined but must be assigned to the required users or teams. The
procedures in this section apply both to using the unprivileged as well as any
custom policy.
Note
When the ClusterRoleBinding is removed, cluster admins can still
deploy Pods, and these Pods are deployed with the privileged policy.
However, users or service accounts will be unable to deploy pods until the
RoleBinding is created, because Kubernetes cannot determine which pod
security policy to apply.
To apply the unprivileged policy:
The following steps must be performed by a cluster admin.
Remove the
ClusterRoleBinding:kubectl delete clusterrolebindings ucp:all:privileged-psp-role
List the existing
ClusterRoles:kubectl get clusterrole | grep psp
Expected output:
privileged-psp-role 3h47m unprivileged-psp-role 3h47m
Define the user or team to whom you want to apply the
ClusterRole:USER=<user-name>
Create a
RoleBindingthat links theClusterRoleto the user or team:cat <<EOF | kubectl create -f - kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: unprivileged-psp-role:$USER namespace: default roleRef: kind: ClusterRole name: unprivileged-psp-role apiGroup: rbac.authorization.k8s.io subjects: - kind: User name: $USER namespace: default EOF
To verify the application of the unprivileged policy:
The following example must be performed by a regular user who is assigned to the unprivileged policy.
Deploy a basic
nginxPod:cat <<EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: demopod spec: containers: - name: demopod image: nginx EOF
Review the status of the Pod:
kubectl get pods
Example output:
NAME READY STATUS RESTARTS AGE demopod 1/1 Running 0 10m
Review which policy is applied to the Pod using the
-o yamlor-o jsonsyntax withkubectland parse the JSON output with jq:kubectl get pods demopod -o json | jq -r '.metadata.annotations."kubernetes.io/psp"'
Expected output:
unprivileged
Use the unprivileged policy in a Deployment¶
If you have disabled the privileged policy and created a
RoleBinding to map a user to a new PSP, Kubernetes objects
like Deployments and DaemonSets will not be able to deploy Pods. This is
because Kubernetes objects use a ServiceAccount to schedule Pods, instead
of the user that created the Deployment.
For this Deployment to be able to schedule Pods, the service account defined within the Deployment specification needs to be associated with a policy.
To review the status of the NGINX Deployment created in the previous section:
List your Deployments:
kubectl get deployments
Example output:
NAME READY UP-TO-DATE AVAILABLE AGE nginx 0/1 0 0 88s
List your ReplicaSets:
kubectl get replicasets
Example output:
NAME DESIRED CURRENT READY AGE nginx-cdcdd9f5c 1 0 0 92s
Describe your ReplicaSets:
kubectl describe replicasets nginx-cdcdd9f5c
Example output:
Warning FailedCreate 48s (x15 over 2m10s) \ replicaset-controller Error creating: \ pods "nginx-cdcdd9f5c-" is forbidden: \ unable to validate against any pod security policy: []
If a service account is not defined within a Deployment specification, the
default service account in a namespace is used. This is the case in the
Deployment output above. Because there is no service account defined, a
Rolebinding is needed to grant the default service account in the default
namespace to use the PSP.
To associate the unprivileged policy with the default service account:
The following must be performed by a cluster admin.
Create a RoleBinding to associate the unprivileged policy with the
default service account:
cat <<EOF | kubectl create -f -
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: unprivileged-psp-role:defaultsa
namespace: default
roleRef:
kind: ClusterRole
name: unprivileged-psp-role
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: default
namespace: default
EOF
To verify the application of the unprivileged policy to the default service account:
List your Deployments:
kubectl get deployments
Example output:
NAME READY UP-TO-DATE AVAILABLE AGE nginx 1/1 1 1 6m11s
List your ReplicaSets:
kubectl get replicasets
Example output:
NAME DESIRED CURRENT READY AGE nginx-cdcdd9f5c 1 1 1 6m16s
List your Pods:
kubectl get pods
Example output:
NAME READY STATUS RESTARTS AGE nginx-cdcdd9f5c-9kknc 1/1 Running 0 6m17s
Review which policy is applied to the default service account. For example:
kubectl get pod nginx-cdcdd9f5c-9kknc -o json | jq -r '.metadata.annotations."kubernetes.io/psp"'
Expected output:
unprivileged
Apply the unprivileged PSP to a namespace¶
A common PSP use case is to apply a particular policy to particular
namespace(s). For example, an admin might want to use
the privileged policy for all of the infrastructure namespaces and use the
unprivileged policy for the end user namespaces.
In the following example, infrastructure workloads are deployed in
the kube-system and monitoring namespaces, while end user workloads are
deployed in the default namespace.
To apply the privileged and unprivileged PSPs to different namespaces:
The following steps must be performed by a cluster admin.
Delete the
ClusterRoleBindingthat is applied by default in MKE:kubectl delete clusterrolebindings ucp:all:privileged-psp-role
Create a new
ClusterRoleBindingthat will enforce theprivilegedPSP for all users and service accounts in thekube-systemandmonitoringnamespaces:cat <<EOF | kubectl create -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: ucp:infrastructure:privileged-psp-role roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: privileged-psp-role subjects: - kind: Group name: system:authenticated:kube-system apiGroup: rbac.authorization.k8s.io - kind: Group name: system:authenticated:monitoring apiGroup: rbac.authorization.k8s.io - kind: Group name: system:serviceaccounts:kube-system apiGroup: rbac.authorization.k8s.io - kind: Group name: system:serviceaccounts:monitoring apiGroup: rbac.authorization.k8s.io EOF
Create a
ClusterRoleBindingto allow all users who deploy Pods and Deployments in thedefaultnamespace to use theunprivilegedpolicy.cat <<EOF | kubectl create -f - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: ucp:default:unprivileged-psp-role roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: unprivileged-psp-role subjects: - kind: Group name: system:authenticated:default apiGroup: rbac.authorization.k8s.io - kind: Group name: system:serviceaccounts:default apiGroup: rbac.authorization.k8s.io EOF
To verify the application of the privileged and unprivileged policies:
Create two Deployments, one in the monitoring namespace and the other in the default namespace:
cat <<EOF | kubectl create -f - apiVersion: v1 kind: Pod metadata: name: demopod namespace: monitoring spec: containers: - name: demopod image: nginx --- apiVersion: v1 kind: Pod metadata: name: demopod namespace: default spec: containers: - name: demopod image: nginx EOF
Review which policy is applied to the monitoring namespace:
kubectl get pods demopod -n monitoring -o json | jq -r '.metadata.annotations."kubernetes.io/psp"'
Expected output:
privileged
Review which policy is applied to the default namespace:
kubectl get pods demopod -n default -o json | jq -r '.metadata.annotations."kubernetes.io/psp"'
Expected output:
unprivileged