Merge "PSP Removal in support of transition to k8s 1.25/1.26"

This commit is contained in:
Zuul 2024-10-28 18:33:55 +00:00 committed by Gerrit Code Review
commit 391e222c6e
11 changed files with 12 additions and 450 deletions

View File

@ -255,7 +255,7 @@
.. |index-security-84d0d8aa401b| replace:: :ref:`Security <index-security-84d0d8aa401b>`
.. |pod-security-admission-controller-8e9e6994100f| replace:: :ref:`Pod Security Admission Controller <pod-security-admission-controller-8e9e6994100f>`
.. |install-update-the-starlingx-rest-and-web-server-certificate| replace:: :ref:`Install/Update the StarlingX Rest and Web Server Certificate <install-update-the-starlingx-rest-and-web-server-certificate>`
.. |pod-security-policies| replace:: :ref:`Pod Security Policies <pod-security-policies>`
.. .. |pod-security-policies| replace:: :ref:`Pod Security Policies <pod-security-policies>`
.. |remove-portieris| replace:: :ref:`Remove Portieris <remove-portieris>`
.. |delete-ldap-linux-accounts-7de0782fbafd| replace:: :ref:`Delete LDAP Linux Accounts <delete-ldap-linux-accounts-7de0782fbafd>`
.. |security-rest-api-access| replace:: :ref:`REST API Access <security-rest-api-access>`
@ -307,14 +307,14 @@
.. |kubernetes-certificates-f4196d7cae9c| replace:: :ref:`Kubernetes Certificates <kubernetes-certificates-f4196d7cae9c>`
.. |security-access-the-gui| replace:: :ref:`Access the GUI <security-access-the-gui>`
.. |install-portieris| replace:: :ref:`Install Portieris <install-portieris>`
.. |disable-pod-security-policy-checking| replace:: :ref:`Disable Pod Security Policy Checking <disable-pod-security-policy-checking>`
.. .. |disable-pod-security-policy-checking| replace:: :ref:`Disable Pod Security Policy Checking <disable-pod-security-policy-checking>`
.. |configure-local-cli-access| replace:: :ref:`Configure Local CLI Access <configure-local-cli-access>`
.. |deprovision-ldap-server-authentication| replace:: :ref:`Deprovision LDAP Server Authentication <deprovision-ldap-server-authentication>`
.. |overview-of-ldap-servers| replace:: :ref:`Overview of LDAP Servers <overview-of-ldap-servers>`
.. |etcd-certificates-c1fc943e4a9c| replace:: :ref:`Etcd Certificates <etcd-certificates-c1fc943e4a9c>`
.. |install-the-kubernetes-dashboard| replace:: :ref:`Install the Kubernetes Dashboard <install-the-kubernetes-dashboard>`
.. |enable-https-access-for-starlingx-rest-and-web-server-endpoints| replace:: :ref:`Enable HTTPS Access for StarlingX REST and Web Server Endpoints <enable-https-access-for-starlingx-rest-and-web-server-endpoints>`
.. |assign-pod-security-policies| replace:: :ref:`Assign Pod Security Policies <assign-pod-security-policies>`
.. .. |assign-pod-security-policies| replace:: :ref:`Assign Pod Security Policies <assign-pod-security-policies>`
.. |install-vault| replace:: :ref:`Install Vault <install-vault>`
.. |configure-vault| replace:: :ref:`Configure Vault Using the Vault REST API <configure-vault>`
.. |configure-rest-api-applications-and-web-administration-server-certificates-after-installation-6816457ab95f| replace:: :ref:`Configure REST API Applications and Web Administration Server certificate <configure-rest-api-applications-and-web-administration-server-certificates-after-installation-6816457ab95f>`
@ -357,7 +357,7 @@
.. |portieris-clusterimagepolicy-and-imagepolicy-configuration| replace:: :ref:`Portieris ClusterImagePolicy and ImagePolicy Configuration <portieris-clusterimagepolicy-and-imagepolicy-configuration>`
.. |selectively-disable-ssh-for-local-openldap-and-wad-users-e5aaf09e790c| replace:: :ref:`Selectively Disable SSH for Local OpenLDAP and WAD Users <selectively-disable-ssh-for-local-openldap-and-wad-users-e5aaf09e790c>`
.. |security-cert-manager| replace:: :ref:`Cert Manager <security-cert-manager>`
.. |enable-pod-security-policy-checking| replace:: :ref:`Enable Pod Security Policy Checking <enable-pod-security-policy-checking>`
.. .. |enable-pod-security-policy-checking| replace:: :ref:`Enable Pod Security Policy Checking <enable-pod-security-policy-checking>`
.. |starlingx-rest-api-applications-and-the-web-administration-server| replace:: :ref:`StarlingX REST API Applications and the Web Administration Server Certificate <starlingx-rest-api-applications-and-the-web-administration-server>`
.. |starlingx-openstack-kubernetes-from-stsadmin-account-login| replace:: :ref:`For StarlingX, Platform OpenStack and Kubernetes CLIs from the 'sysadmin' Linux Account Login <starlingx-openstack-kubernetes-from-stsadmin-account-login>`
.. |configure-users-groups-and-authorization| replace:: :ref:`Configure Users, Groups, and Authorization <configure-users-groups-and-authorization>`

View File

@ -23,8 +23,6 @@ General Configuration
system_config
time_sync_config
------------------------
Kubernetes Configuration
------------------------
@ -34,7 +32,6 @@ Kubernetes Configuration
k8s_auth_winactivedir
k8s_persistent_vol
k8s_pod_sec_policies
k8s_res_policies
k8s_upgrade

View File

@ -1,138 +0,0 @@
=====================
Pod Security Policies
=====================
.. note::
PodSecurityPolicy (PSP) ONLY applies if running on K8S v1.24 or earlier.
PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and removed from K8S v1.25.
Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using
:ref:`Pod Security Admission Controller <pod-security-admission-controller-8e9e6994100f>`
.. note::
This guide was replaced by: :ref:`Pod Security Policies <pod-security-policies>`
This guide describes how to enable Kubernetes pod security policies.
.. contents::
:local:
:depth: 1
--------
Overview
--------
Pod Security Policies (PSPs) enable fine-grained authorization of pod creation
and updates. :abbr:`PSPs (Pod Security Policies)` control access to security
sensitive aspects of pod specifications such as running of privileged
containers, use of host file system, running as root, etc. PSPs define a set of
conditions that a pod must run with in order to be accepted into the system, as
well as defaults for the related fields. PSPs are assigned to users using
Kubernetes RBAC RoleBindings. See
https://kubernetes.io/docs/concepts/policy/pod-security-policy/ for details.
When enabled, pod security policy checking authorizes all Kubernetes API
commands against the PSPs which the issuer of the command has access to. If
there are no PSPs defined in the system or the issuer does not have access to
any PSPs, PSP checking will fail to authorize the command.
StarlingX provides a system service parameter to enable pod security policy
checking. Setting this service parameter also creates two PSPs (privileged and
restricted). Users with the cluster-admin role can access all resources and
therefore have PSPs to authorize against. The parameter 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.
-------------------
Enable PSP checking
-------------------
Perform the following steps.
#. Set the Kubernetes ``kube_apiserver admission_plugins`` system parameter to
include PodSecurityPolicy.
::
system service-parameter-add kubernetes kube_apiserver admission_plugins=PodSecurityPolicy
#. Apply the Kubernetes system parameters.
::
system service-parameter-apply kubernetes
Use the following commands to view the automatically added PSPs, as well as
privileged and restricted PSPs.
::
kubectl get psp
kubectl describe psp privileged
kubectl describe psp restricted
-------------------------------
Update role for non-admin users
-------------------------------
After enabling Pod security policy checking in StarlingX, all users
with the cluster-admin role are unaffected because they have access to the
privileged PSP. However, other users require a new ``RoleBinding`` to either
the privileged-psp-user role or the restricted-psp-user role.
For example, the following ``RoleBinding`` assigns the restricted PSP to
``basic-user`` in the ``billing-dept-ns`` namespace:
::
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: basic-restricted-psp-users
namespace: billing-dept-ns
subjects:
- kind: ServiceAccount
name: basic-user
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: restricted-psp-user
This enables ``basic-user`` to create pods in the ``billing-dept-ns`` namespace
subject to the restricted PSP policy.
---------------------------------
Bind to the PSP for the namespace
---------------------------------
An unexpected behavior when PSP checking is enabled is that the above
``basic-user`` is able to create pods in ``billing-dept-ns`` (subject to the
restricted PSP), however they are **not** able to create deployments. This is
because the pods of the deployment are created using the replicaSet
controllers serviceAccount and RBAC bindings, not the ``basic-user``
serviceAccount and RBAC bindings.
The typical approach for addressing this is to bind all the serviceAccounts in
kube-system (which includes replicaSet controller serviceAccounts) to the
appropriate PSP for the specific namespace.
For example, the following RoleBinding assigns the restricted PSP to all
kube-system serviceAccounts operating in the ``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

View File

@ -1,3 +1,4 @@
=================
Resource Policies
=================
@ -35,7 +36,7 @@ Specifically a LimitRange policy provides constraints that can:
See https://kubernetes.io/docs/concepts/policy/limit-range/ for more details.
An example of LimitRange policies for the ``billing-dept-ns`` namespace in the
:doc:`k8s_pod_sec_policies` example is shown below:
:ref:`private-namespace-and-restricted-rbac` example is shown below:
::
@ -96,6 +97,8 @@ An example of LimitRange policies for the ``billing-dept-ns`` namespace in the
memory: 10
type: Pod
-------------
ResourceQuota
-------------
@ -109,19 +112,3 @@ namespaced resource types such as secrets, configmaps, and others.
See https://kubernetes.io/docs/concepts/policy/resource-quotas/ for more details.
An example of ResourceQuota policies for the ``billing-dept-ns`` namespace of
the :doc:`k8s_pod_sec_policies` example is shown below:
::
apiVersion: v1
kind: ResourceQuota
metadata:
name: resource-quotas
namespace: billing-dept-ns
spec:
hard:
persistentvolumeclaims: "1"
services.loadbalancers: "2"
services.nodeports: "0"

View File

@ -1,134 +0,0 @@
.. ler1590089128119
.. _assign-pod-security-policies:
============================
Assign Pod Security Policies
============================
.. note::
PodSecurityPolicy (PSP) ONLY applies if running on K8S v1.24 or earlier.
PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and removed from K8S v1.25.
Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using
:ref:`Pod Security Admission Controller <pod-security-admission-controller-8e9e6994100f>`
This section describes Pod security policies for **cluster-admin users**,
and **non-cluster-admin users**.
.. contents::
:local:
:depth: 1
.. _assign-pod-security-policies-section-xyl-2vp-bmb:
-------------------
cluster-admin users
-------------------
After enabling |PSP| checking, all users with **cluster-admin** roles can
directly create pods since they have access to the **privileged** |PSP|. Also,
based on the ClusterRoleBindings and RoleBindings automatically added by
|prod|, all users with cluster-admin roles can also create privileged
Deployment/ReplicaSets/etc. in the kube-system namespace and restricted
Deployment/ReplicaSets/etc. in any other namespace.
In order to enable privileged Deployment/ReplicaSets/etc. to be created in
another namespace, a role binding of a |PSP| role to
**system:serviceaccounts:kube-system** for the target namespace, is required.
However, this will enable *ANY* user with access to Deployments/ReplicaSets/etc
in this namespace to create privileged Deployments/ReplicaSets. The following
example describes the required RoleBinding to allow "creates" of privileged
Deployments/ReplicaSets/etc in the 'default' namespace for any user with access
to Deployments/ReplicaSets/etc. in the default namespace.
.. code-block:: none
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: default-privileged-psp-users
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: privileged-psp-user
subjects:
- kind: Group
name: system:serviceaccounts:kube-system
apiGroup: rbac.authorization.k8s.io
.. _assign-pod-security-policies-section-bm5-vxp-bmb:
-----------------------
non-cluster-admin users
-----------------------
Based on the ClusterRoleBindings and RoleBindings automatically added by
|prod|, non-cluster-admin users have at least restricted |PSP| privileges, for
both Pods and Deployment/ReplicaSets/etc., for any namespaces they have access
to based on other [Cluster]RoleBindings. If a non-cluster-admin user requires
privileged capabilities for the namespaces they have access to, they require a
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**).
.. rubric:: |proc|
#. Define the required RoleBinding for the user in the target namespace.
For example, the following RoleBinding assigns the 'privileged' |PSP|
role to dave-user in the billing-dept-ns namespace, from the examples
in :ref:`Enable Pod Security Policy Checking
<enable-pod-security-policy-checking>`.
.. code-block:: none
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dave-privileged-psp-users
namespace: billing-dept-ns
subjects:
- kind: ServiceAccount
name: dave-user
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: privileged-psp-user
This will enable dave-user to create Pods in billing-dept-ns namespace
subject to the privileged |PSP| policy.
#. Define the required RoleBinding for system:serviceaccounts:kube-system
in the target namespace.
For example, the following RoleBinding assigns the 'privileged' |PSP| to
all kube-system ServiceAccounts operating in billing-dept-ns namespace.
.. code-block:: none
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: billing-dept-ns-privileged-psp-users
namespace: billing-dept-ns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: privileged-psp-user
subjects:
- kind: Group
name: system:serviceaccounts:kube-system
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

@ -1,34 +0,0 @@
.. ecz1590154334366
.. _disable-pod-security-policy-checking:
====================================
Disable Pod Security Policy Checking
====================================
.. note::
PodSecurityPolicy (PSP) ONLY applies if running on K8S v1.24 or earlier.
PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and removed from K8S v1.25.
Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using
:ref:`Pod Security Admission Controller <pod-security-admission-controller-8e9e6994100f>`
You can delete the previously added PodSecurityPolicy service parameter to
disable pod security policy checking.
.. rubric:: |proc|
#. Remove the kubernetes **kube_apiserver admission_plugins** system
parameter to exclude PodSecurityPolicy.
.. code-block:: none
~(keystone_admin)]$ system service-parameter-delete <uuid>
#. Apply the Kubernetes system parameters.
.. code-block:: none
~(keystone_admin)]$ system service-parameter-apply kubernetes

View File

@ -1,39 +0,0 @@
.. vca1590088383576
.. _enable-pod-security-policy-checking:
===================================
Enable Pod Security Policy Checking
===================================
.. note::
PodSecurityPolicy (PSP) ONLY applies if running on K8S v1.24 or earlier.
PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and removed from K8S v1.25.
Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using
:ref:`Pod Security Admission Controller <pod-security-admission-controller-8e9e6994100f>`
.. rubric:: |proc|
#. Set the kubernetes kube_apiserver admission_plugins system parameter to
include PodSecurityPolicy.
.. code-block:: none
~(keystone_admin)]$ system service-parameter-add kubernetes kube_apiserver admission_plugins=PodSecurityPolicy
#. Apply the Kubernetes system parameters.
.. code-block:: none
~(keystone_admin)]$ system service-parameter-apply kubernetes
#. View the automatically added pod security policies.
.. code-block:: none
$ kubectl get psp
$ kubectl describe <psp> privileged
$ kubectl describe <psp> restricted

View File

@ -44,10 +44,6 @@ Manage Non-Admin Type Users
:maxdepth: 1
private-namespace-and-restricted-rbac
pod-security-policies
enable-pod-security-policy-checking
disable-pod-security-policy-checking
assign-pod-security-policies
resource-management
pod-security-admission-controller-8e9e6994100f

View File

@ -8,7 +8,7 @@ Pod Security Admission (PSA) Controller is the |PSP| replacement, and this
document describes the |PSA| functionality, which is 'beta' quality in
Kubernetes v1.24 .
The |PSA| admission controller acts on creation and modification of the pod and
The |PSA| controller acts on creation and modification of the pod and
determines if it should be admitted based on the requested security context and
the policies defined by Pod Security Standards.

View File

@ -1,71 +0,0 @@
.. pui1590088143541
.. _pod-security-policies:
=====================
Pod Security Policies
=====================
.. note::
PodSecurityPolicy (PSP) ONLY applies if running on K8S v1.24 or earlier.
PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and removed from K8S v1.25.
Instead of using PodSecurityPolicy, you can enforce similar restrictions on Pods using
:ref:`Pod Security Admission Controller <pod-security-admission-controller-8e9e6994100f>`
|PSPs| enable fine-grained authorization of pod creation and updates.
|PSPs| control access to security sensitive aspects of Pod specifications
such as running of privileged containers, use of host filesystem, running as
root, etc. |PSPs| define a set of conditions that a pod must run with, in
order to be accepted into the system, as well as defaults for the related
fields. |PSPs| are assigned to users through Kubernetes |RBAC| RoleBindings.
See `https://kubernetes.io/docs/concepts/policy/pod-security-policy/
<https://kubernetes.io/docs/concepts/policy/pod-security-policy/>`__ for
details.
When enabled, Pod security policy checking will authorize all Kubernetes
API commands against the |PSPs| which the issuer of the command has access
to. If there are no |PSPs| defined in the system or the issuer does not have
access to any |PSPs|, the Pod security policy checking will fail to authorize
the command.
|prod-long| provides a system service-parameter to enable Pod security
policy checking. Setting this 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.
- 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.
PodSecurityPolicy (PSP) is deprecated as of Kubernetes v1.21 and will be
removed in v1.25. PSP will continue to be fully functional until being removed
in v1.25.
Since first introduced PSP has shown some serious usability problems.
The way PSPs are applied to Pods has proven confusing especially when trying to
use them. It is easy to accidentally grant broader permissions than intended,
and difficult to inspect which PSPs apply in a certain situation.
As a beta feature, Kubernetes offers a built-in Pod Security Admission (PSA)
controller, the successor to PSP. See :ref:`Technology Preview - Pod Security
Admission Controller <pod-security-admission-controller-8e9e6994100f>`.

View File

@ -44,8 +44,8 @@ Specifically a **LimitRange** policy provides constraints that can:
See `https://kubernetes.io/docs/concepts/policy/limit-range/ <https://kubernetes.io/docs/concepts/policy/limit-range/>`__ for more details.
An example of **LimitRange** policies for the billing-dept-ns namespace of
the example in :ref:`Assign Pod Security Policies
<assign-pod-security-policies>` is shown below:
the example in :ref:`Private Namespace and Restricted RBAC
<private-namespace-and-restricted-rbac>` is shown below:
.. code-block:: none
@ -107,7 +107,6 @@ the example in :ref:`Assign Pod Security Policies
type: Pod
.. _resource-management-section-ur2-q5m-tlb:
-------------
@ -127,7 +126,7 @@ See `https://kubernetes.io/docs/concepts/policy/resource-quotas/
details.
An example of **ResourceQuota** policies for the billing-dept-ns namespace
of :ref:`Assign Pod Security Policies <assign-pod-security-policies>`
of :ref:`Private Namespace and Restricted RBAC <private-namespace-and-restricted-rbac>`
is shown below:
.. code-block:: none
@ -142,4 +141,3 @@ is shown below:
persistentvolumeclaims: "1"
services.loadbalancers: "2"
services.nodeports: "0"