pod security policies updates

New content: Minor Usability Enhancement to Default Pod Security Policies
Implemented patchset 2 comment
Implemented patchset 3 comments

Signed-off-by: Ron Stone <ronald.stone@windriver.com>
Change-Id: I82d31f412c47bfecf4601169400bf090ceda636c
Signed-off-by: Ron Stone <ronald.stone@windriver.com>
This commit is contained in:
Ron Stone 2021-03-31 13:51:01 -04:00
parent f9d1b4905d
commit 398041b403
2 changed files with 57 additions and 46 deletions

View File

@ -20,44 +20,33 @@ cluster-admin users
------------------- -------------------
After enabling |PSP| checking, all users with **cluster-admin** roles can After enabling |PSP| checking, all users with **cluster-admin** roles can
directly create pods as they have access to the **privileged** |PSP|. directly create pods since they have access to the **privileged** |PSP|. Also,
However, when creating pods through deployments/ReplicaSets/etc., the pods based on the ClusterRoleBindings and RoleBindings automatically added by
are validated against the |PSP| policies of the corresponding controller |prod|, all users with cluster-admin roles can also create privileged
serviceAccount in kube-system namespace. Deployment/ReplicaSets/etc. in the kube-system namespace and restricted
Deployment/ReplicaSets/etc. in any other namespace.
Therefore, for any user \(including cluster-admin\) to create
deployment/ReplicaSet/etc. in a particular namespace:
.. _assign-pod-security-policies-ul-hsr-1vp-bmb: In order to enable privileged Deployment/ReplicaSets/etc. to be created in
another namespace, a role binding of a |PSP| role to
- the user must have |RBAC| permissions to create the **system:serviceaccounts:kube-system** for the target namespace, is required.
deployment/ReplicaSet/etc. in this namespace, and However, this will enable *ANY* user with access to Deployments/ReplicaSets/etc
in this namespace to create privileged Deployments/ReplicaSets. The following
- the **system:serviceaccounts:kube-system** must be bound to a role with example describes the required RoleBinding to allow "creates" of privileged
access to |PSPs| \(for example, one of the system created Deployments/ReplicaSets/etc in the 'default' namespace for any user with access
**privileged-psp-user** or **restricted-psp-user** roles\) in this to Deployments/ReplicaSets/etc. in the default namespace.
namespace
**cluster-admin users** have |RBAC| permissions for everything. So it is only
the role binding of a |PSP| 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 |PSP| capabilities\) in the 'default' namespace.
.. code-block:: none .. code-block:: none
apiVersion: rbac.authorization.k8s.io/v1 apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding kind: RoleBinding
metadata: metadata:
name: kube-system-restricted-psp-users name: default-privileged-psp-users
namespace: default namespace: default
roleRef: roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
kind: ClusterRole kind: ClusterRole
name: restricted-psp-user name: privileged-psp-user
subjects: subjects:
- kind: Group - kind: Group
name: system:serviceaccounts:kube-system name: system:serviceaccounts:kube-system
@ -71,19 +60,22 @@ restricted |PSP| capabilities\) in the 'default' namespace.
non-cluster-admin users non-cluster-admin users
----------------------- -----------------------
They have restricted |RBAC| capabilities, and may not have access to |PSP| Based on the ClusterRoleBindings and RoleBindings automatically added by
policies. They require a new RoleBinding to either the |prod|, non-cluster-admin users have at least restricted |PSP| privileges, for
**privileged-psp-user** role, or the **restricted-psp-user** role to create both Pods and Deployment/ReplicaSets/etc., for any namespaces they have access
pods directly. For creating pods through deployments/ReplicaSets/etc., the to based on other [Cluster]RoleBindings. If a non-cluster-admin user requires
target namespace being used will also require a RoleBinding for the privileged capabilities for the namespaces they have access to, they require a
corresponding controller serviceAccounts in kube-system \(or generally new RoleBinding to the **privileged-psp-user** role to create pods directly.
For creating privileged 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**\). **system:serviceaccounts:kube-system**\).
.. rubric:: |proc| .. rubric:: |proc|
#. Define the required RoleBinding for the user in the target namespace. #. Define the required RoleBinding for the user in the target namespace.
For example, the following RoleBinding assigns the 'restricted' |PSP| For example, the following RoleBinding assigns the 'privileged' |PSP|
role to dave-user in the billing-dept-ns namespace, from the examples role to dave-user in the billing-dept-ns namespace, from the examples
in :ref:`Enable Pod Security Policy Checking in :ref:`Enable Pod Security Policy Checking
<enable-pod-security-policy-checking>`. <enable-pod-security-policy-checking>`.
@ -93,7 +85,7 @@ corresponding controller serviceAccounts in kube-system \(or generally
apiVersion: rbac.authorization.k8s.io/v1 apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding kind: RoleBinding
metadata: metadata:
name: dave-restricted-psp-users name: dave-privileged-psp-users
namespace: billing-dept-ns namespace: billing-dept-ns
subjects: subjects:
- kind: ServiceAccount - kind: ServiceAccount
@ -102,15 +94,15 @@ corresponding controller serviceAccounts in kube-system \(or generally
roleRef: roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
kind: ClusterRole kind: ClusterRole
name: restricted-psp-user name: privileged-psp-user
This will enable dave-user to create Pods in billing-dept-ns namespace This will enable dave-user to create Pods in billing-dept-ns namespace
subject to the restricted |PSP| policy. subject to the privileged |PSP| policy.
#. Define the required RoleBinding for system:serviceaccounts:kube-system #. Define the required RoleBinding for system:serviceaccounts:kube-system
in the target namespace. in the target namespace.
For example, the following RoleBinding assigns the 'restricted' |PSP| to For example, the following RoleBinding assigns the 'privileged' |PSP| to
all kube-system ServiceAccounts operating in billing-dept-ns namespace. all kube-system ServiceAccounts operating in billing-dept-ns namespace.
.. code-block:: none .. code-block:: none
@ -118,15 +110,18 @@ corresponding controller serviceAccounts in kube-system \(or generally
apiVersion: rbac.authorization.k8s.io/v1 apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding kind: RoleBinding
metadata: metadata:
name: kube-system-restricted-psp-users name: billing-dept-ns-privileged-psp-users
namespace: billing-dept-ns namespace: billing-dept-ns
roleRef: roleRef:
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
kind: ClusterRole kind: ClusterRole
name: restricted-psp-user name: privileged-psp-user
subjects: subjects:
- kind: Group - kind: Group
name: system:serviceaccounts:kube-system name: system:serviceaccounts:kube-system
apiGroup: rbac.authorization.k8s.io apiGroup: rbac.authorization.k8s.io
This will enable dave-user to create Deployments/ReplicaSets/etc. in
billing-dept-ns namespace subject to the privileged |PSP| policy.

View File

@ -24,11 +24,27 @@ access to any |PSPs|, the Pod security policy checking will fail to authorize
the command. the command.
|prod-long| provides a system service-parameter to enable Pod security |prod-long| provides a system service-parameter to enable Pod security
policy checking. In addition to enabling Pod security policy checking, policy checking. Setting this parameter also creates:
setting this service parameter also creates two |PSPs| \(privileged and
restricted\) such that users with cluster-admin role \(which has access to
all resources\) has |PSPs| to authorize against. It also creates two
corresponding roles for specifying access to these |PSPs|
\(privileged-psp-user and restricted-psp-user\), for binding to other
non-admin type subjects.
- Two |PSPs| (privileged and restricted) such that users with cluster-admin
role (which has access to all resources) has |PSPs| to authorize against.
- Two corresponding roles for specifying access to these |PSPs|
(privileged-psp-user and restricted-psp-user), for binding to other
non-admin type subjects.
- A RoleBinding for the kube-system namespace of the privileged-psp-user Role
to serviceAccounts in kubesystem, such that privileged
Deployments/ReplicaSets/etc. can be created by any user with access to
Deployments/ReplicaSets/etc. in the kube-system namespace (e.g. user with
cluster-admin role).
- A ClusterRoleBinding of the restricted-psp-user Role to any authenticated
user, such that at least restricted Pods can be created by any
authenticated user in any namespaces that user has access to based on other
[Cluster]RoleBindings.
- A ClusterRoleBinding of the restricted-psp-user Role to serviceAccounts in
kube-system, such that at least restricted Deployments/ReplicaSets/etc. can
be created by any authenticated user in any namespaces that user has access
to based on other [Cluster]RoleBindings.