From 2f34e4314d01e649a6f8c8ada97eef036207689f Mon Sep 17 00:00:00 2001 From: ollypom Date: Sat, 22 Jun 2019 12:14:59 +0000 Subject: [PATCH 1/2] Added more examples to the Pod Security Policy Doc I have added more examples to the pod security policy document including: - how to use PSPs as part of a deployment - how to apply a PSP namespace wide Signed-off-by: Olly Pomeroy --- ee/ucp/kubernetes/pod-security-policies.md | 234 +++++++++++++++++++-- 1 file changed, 215 insertions(+), 19 deletions(-) diff --git a/ee/ucp/kubernetes/pod-security-policies.md b/ee/ucp/kubernetes/pod-security-policies.md index 887bf424a4..5e87e3e423 100644 --- a/ee/ucp/kubernetes/pod-security-policies.md +++ b/ee/ucp/kubernetes/pod-security-policies.md @@ -2,10 +2,12 @@ title: Use Pod Security Policies in UCP description: Learn how to use Pod Security Policies to lock down Kubernetes as part of Universal Control Plane. keywords: UCP, Kubernetes, psps, pod security policies -redirect_from: --- -Pod Security Policies (PSPs) are cluster-level resources which are enabled by default in Docker Universal Control Plane (UCP) 3.2. See [Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for an explanation of this Kubernetes concept. +Pod Security Policies (PSPs) are cluster-level resources which are enabled by +default in Docker Universal Control Plane (UCP) 3.2. See [Pod Security +Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for an +explanation of this Kubernetes concept. There are two default PSPs in UCP: a `privileged` policy and an `unprivileged` policy. Administrators of the cluster can enforce additional @@ -15,12 +17,11 @@ provides two example use cases for custom policies. ## Kubernetes Role Based Access Control (RBAC) -To interact with PSPs, a user will need to be granted access to -the `PodSecurityPolicy` object in Kubernetes RBAC. If the user is a `UCP Admin`, -or has been granted the `ClusterRole`: `cluster-admin` for all namespaces, then -the user can already manipulate PSPs. Additionally, a normal -user can interact with policies if a UCP admin creates the following -`ClusterRole` and `ClusterRoleBinding`: +To interact with PSPs, a user will need to be granted access to the +`PodSecurityPolicy` object in Kubernetes RBAC. If the user is a `UCP Admin`, +then the user can already manipulate PSPs. A normal user can interact with +policies if a UCP admin creates the following `ClusterRole` and +`ClusterRoleBinding`: ``` $ cat < Note: In a most use cases a Pod is not actually scheduled by a user. When +> creating Kubernetes objects such as Deployments or Daemonsets the pods are +> being scheduled by a service account or a controller. + +If you have disabled the `privileged` PSP policy, and created a `RoleBinding` +to map a user to a new PSP policy, Kubernetes objects like Deployments and +Daemonsets will not be able to deploy pods. This is because Kubernetes objects, +like Deployments, use a `Service Account` to schedule pods, instead of the user +that created the Deployment. + +```bash +user $ kubectl get deployments +NAME READY UP-TO-DATE AVAILABLE AGE +nginx 0/1 0 0 88s + +user $ kubectl get replicasets +NAME DESIRED CURRENT READY AGE +nginx-cdcdd9f5c 1 0 0 92s + +user $ kubectl describe replicasets nginx-cdcdd9f5c +... + Warning FailedCreate 48s (x15 over 2m10s) replicaset-controller Error creating: pods "nginx-cdcdd9f5c-" is forbidden: unable to validate against any pod security policy: [] +``` + +For this deployment to be able to schedule pods, the service account defined +wthin the deployment specification needs to be associated with a PSP policy. +If a service account is not defined within a deployment spec, the default +service account in a namespace is used. + +This is the case in the deployment output above, there is no service account +defined, therefore a `Rolebinding` to grant the default service account in the +default namespace to use PSP policy is needed. + +An example `RoleBinding` to associate the `unprivileged` PSP policy in UCP with +the defaut service account in the default namespace is: + +```bash +admin $ cat < Date: Wed, 26 Jun 2019 17:28:09 +0000 Subject: [PATCH 2/2] formatting --- ee/ucp/kubernetes/pod-security-policies.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ee/ucp/kubernetes/pod-security-policies.md b/ee/ucp/kubernetes/pod-security-policies.md index 5e87e3e423..af23fd0829 100644 --- a/ee/ucp/kubernetes/pod-security-policies.md +++ b/ee/ucp/kubernetes/pod-security-policies.md @@ -9,11 +9,11 @@ default in Docker Universal Control Plane (UCP) 3.2. See [Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for an explanation of this Kubernetes concept. -There are two default PSPs in UCP: a `privileged` policy -and an `unprivileged` policy. Administrators of the cluster can enforce additional -policies and apply them to users and teams for further control of what runs in the -Kubernetes cluster. This guide describes the two default policies, and -provides two example use cases for custom policies. +There are two default PSPs in UCP: a `privileged` policy and an `unprivileged` +policy. Administrators of the cluster can enforce additional policies and apply +them to users and teams for further control of what runs in the Kubernetes +cluster. This guide describes the two default policies, and provides two +example use cases for custom policies. ## Kubernetes Role Based Access Control (RBAC)