docs/doc/source/security/kubernetes/assign-pod-security-policies.rst
Keane Lim 3c5fa979a4 Security guide update
Re-organized topic hierarchy

Tiny edit to restart review workflow.

Squashed with Resolved index.rst conflict commit

Change-Id: I13472792cb19d1e9975ac76c6954d38054d606c5
Signed-off-by: Keane Lim <keane.lim@windriver.com>
Signed-off-by: MCamp859 <maryx.camp@intel.com>
2021-03-12 15:10:40 -05:00

4.2 KiB

Assign Pod Security Policies

This section describes Pod security policies for cluster-admin users, and non-cluster-admin users.

cluster-admin users

After enabling checking, all users with cluster-admin roles can directly create pods as they have access to the privileged . However, when creating pods through deployments/ReplicaSets/etc., the pods are validated against the policies of the corresponding controller serviceAccount in kube-system namespace.

Therefore, for any user (including cluster-admin) to create deployment/ReplicaSet/etc. in a particular namespace:

  • the user must have permissions to create the deployment/ReplicaSet/etc. in this namespace, and
  • the system:serviceaccounts:kube-system must be bound to a role with access to (for example, one of the system created privileged-psp-user or restricted-psp-user roles) in this namespace

cluster-admin users have permissions for everything. So it is only the role binding of a role to system:serviceaccounts:kube-system for the target namespace, that is needed to create a deployment in a particular namespace. The following example describes the required RoleBinding for a cluster-admin user to create a deployment (with restricted capabilities) in the 'default' namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: kube-system-restricted-psp-users
  namespace: default
roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: restricted-psp-user
subjects:
- kind: Group
  name: system:serviceaccounts:kube-system
  apiGroup: rbac.authorization.k8s.io

non-cluster-admin users

They have restricted capabilities, and may not have access to policies. They require a new RoleBinding to either the privileged-psp-user role, or the restricted-psp-user role to create pods directly. For creating pods through deployments/ReplicaSets/etc., the target namespace being used will also require a RoleBinding for the corresponding controller serviceAccounts in kube-system (or generally system:serviceaccounts:kube-system).

  1. Define the required RoleBinding for the user in the target namespace.

    For example, the following RoleBinding assigns the 'restricted' role to dave-user in the billing-dept-ns namespace, from the examples in Enable Pod Security Policy Checking <enable-pod-security-policy-checking>.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: dave-restricted-psp-users
      namespace: billing-dept-ns
    subjects:
    - kind: ServiceAccount
      name: dave-user
      namespace: kube-system
    roleRef:
       apiGroup: rbac.authorization.k8s.io
       kind: ClusterRole
       name: restricted-psp-user

    This will enable dave-user to create Pods in billing-dept-ns namespace subject to the restricted policy.

  2. Define the required RoleBinding for system:serviceaccounts:kube-system in the target namespace.

    For example, the following RoleBinding assigns the 'restricted' to all kube-system ServiceAccounts operating in billing-dept-ns namespace.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: kube-system-restricted-psp-users
      namespace: billing-dept-ns
    roleRef:
       apiGroup: rbac.authorization.k8s.io
       kind: ClusterRole
       name: restricted-psp-user
    subjects:
    - kind: Group
      name: system:serviceaccounts:kube-system
      apiGroup: rbac.authorization.k8s.io