Juanita Balaraj 8a8059a1e4 PSP Removal in support of transition to k8s 1.25/1.26

Updated Patchset 1 comments
Removed topic from an archived folder
Commented out related links to these topics
Removed all PSP topics
Story: 2010590
Task: 50961

Change-Id: If129ebfc9f4622f69114c5dac0163a5e84caa27f
Signed-off-by: Juanita Balaraj <juanita.balaraj@windriver.com>

2024-10-09 19:12:30 +00:00

11 KiB

Raw Blame History

Pod Security Admission Controller

Pod Security Admission (PSA) Controller is the replacement, and this document describes the functionality, which is 'beta' quality in Kubernetes v1.24 .

The 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.

Pod Security levels

Pod Security Admission levels refer to the 3 policies defined by the Pod Security Standards: privileged, baseline, and restricted.

Privileged: Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. It aims at system- and infrastructure-level workloads managed by privileged, trusted users.
Baseline: Minimally restrictive policy which prevents known privilege escalations. It aims at ease of adoption for common containerized workloads for non-critical applications.
Restricted: Heavily restricted policy, following current Pod hardening best practices. It is targeted at operators and developers of security-critical applications, as well as lower-trust users.

Pod Security Admission labels for namespaces

Pod security restrictions are applied at the namespace level.

With feature enabled, namespaces can be configured to define the admission control mode to be used for pod security in each namespace. Kubernetes defines a set of labels to set predefined Pod Security levels for a namespace. The label will define what action the controller control plane takes if a potential violation is detected.

A namespace can configure any or all modes, or set different levels for different modes. The modes are:

enforce: Policy violations will cause the pod to be rejected.
audit: Policy violations will trigger the addition of an audit annotation to the event recorded in the Kubernetes audit log but are otherwise allowed.
warn: Policy violations will trigger a user-facing warning but are otherwise allowed.

For each mode, there are two labels that determine the policy used.

This is a generic namespace configuration using labels.

# label indicates which policy level to apply for the mode.
#
# MODE must be one of `enforce`, `audit`, or `warn`.
# LEVEL must be one of `privileged`, `baseline`, or `restricted`.
pod-security.kubernetes.io/<MODE>: <LEVEL>

# Optional: per-mode version label can be used to pin the policy to the
# version that shipped with a given Kubernetes minor version (e.g. v1.24).
#
# MODE must be one of `enforce`, `audit`, or `warn`.
# VERSION must be a valid Kubernetes minor version, or `latest`.
pod-security.kubernetes.io/<MODE>-version: <VERSION>

For more information refer to https://kubernetes.io/docs/concepts/security/pod-security-admission/.

Enable Pod Security Admission

To enable , Pod Security feature gate must be enabled.

Starting with Kubernetes 1.24 version, Pod Security feature gate is enabled by default.

For Kubernetes version 1.22, Pod Security feature gate can be enabled using option feature-gates in bootstrap overrides file, localhost.yml. As the example shown below:

apiserver_extra_args:
 feature-gates: "TTLAfterFinished=true,HugePageStorageMediumSize=true,RemoveSelfLink=false,MemoryManager=true,PodSecurity=true"

See Kubernetes Custom Configuration <kubernetes-custom-configuration-31c1fd41857d> for more details on kubernetes configuration, apiserver_extra_args and apiserver_extra_volumes.

Configure defaults for the Pod Security Admission Controller

The controller can be configured with default security polices and exemptions at bootstrap time.

The Default controller configuration will apply to namespaces that are not configured with the pod-security.kubernetes.io labels to specify a security level and mode. For example if you display the namespace description using kubectl describe namespace <namespace> and the pod-security.kubernetes.io labels are not displayed, then the behavior of the namespace will follow the default labels' level, mode and version configuration set with Pod Security plugin of the AdmissionConfiguration resource.

To configure cluster-wide default policies and/or exemptions, the Pod Security plugin of the AdmissionConfiguration resource can be used. The AdmissionConfiguration resource is configurable at bootstrap time with the api-server_extra_args and apiserver_extra_volumes overrides in the localhost.yml file.

Any policy that is applied via namespace labels will take precedence.

Example of configuration added to localhost.yml:

apiserver_extra_args:
  admission-control-config-file: "/etc/kubernetes/admission-control-config-file.yaml"

apiserver_extra_volumes:
  - name: admission-control-config-file
    mountPath: "/etc/kubernetes/admission-control-config-file.yaml"
    pathType: "File"
    readOnly: true
    content: |
      apiVersion: apiserver.config.k8s.io/v1
      kind: AdmissionConfiguration
      plugins:
      - name: PodSecurity
        configuration:
          apiVersion: pod-security.admission.config.k8s.io/v1beta1
          kind: PodSecurityConfiguration
          defaults:
            enforce: "privileged"
            enforce-version: "latest"
            audit: "privileged"
            audit-version: "latest"
            warn: "privileged"
            warn-version: "latest"

See Kubernetes Custom Configuration <kubernetes-custom-configuration-31c1fd41857d> for more details on kubernetes configuration, apiserver_extra_args and apiserver_extra_volumes.

The generic definition of the AdmissionConfiguration resource can be found at https://kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/.

Platform namespaces configuration

In preparation for controller full support, namespace labels have been added to all the namespaces used by the platform. System namespaces, such as kube-system, deployment, as well as application namespaces such as, cert-manager have been created by default with privileged label levels.

The following labels configuration is applied by default to Platform namespaces:

controller-0:~$ kubectl describe namespace kube-system
Name:         kube-system
Labels:       kubernetes.io/metadata.name=kube-system
              pod-security.kubernetes.io/audit=privileged
              pod-security.kubernetes.io/audit-version=latest
              pod-security.kubernetes.io/enforce=privileged
              pod-security.kubernetes.io/enforce-version=latest
              pod-security.kubernetes.io/warn=privileged
              pod-security.kubernetes.io/warn-version=latest

Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource