Pod security admission
Pod security admission implements the Kubernetes pod security standards that restrict the behavior of pods, providing warning messages and kube-apiserver
audit events for pods that violate the pod security profile policy configured
for the relevant namespace.
IBM Cloud Kubernetes Service version 1.25 and later includes support for Kubernetes pod security admission. For more information, see Pod Security Admission and Pod Security Standards in the Kubernetes documentation.
Pod Security Admission is always enabled for IBM Cloud Kubernetes Service version 1.25 and later. Earlier versions of Kubernetes use pod security policies.
Understanding security profiles
The Kubernetes pod security standards define the following three profiles.
- Privileged
- The default pod security configuration globally enforces the
privileged
Kubernetes pod security profile, which is unrestricted and allows for known privilege escalations, and generates warnings and audit events based on the policies set by therestricted
profile. - Baseline
- The
baseline
profile is a restrictive profile that prevents known privilege escalations. Allows the default (minimally specified) Pod configuration. - Restricted
- The
restricted
profile is heavily restricted and follows the current pod hardening best practices.
For more information about pod security profiles, see Profile details in the Kubernetes documentation.
Pod Security Admission contains three modes that define what action the control plane takes if a potential violation is detected.
- enforce
- Policy violations cause the pod to be rejected.
- audit
- Policy violations trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.
- warn
- Policy violations trigger a user-facing warning, but are otherwise allowed.
As security standards or profiles implementations change to address new features, you can configure Pod Security Admission to use a specific version of the roles. The following versions are supported.
- A Kubernetes major.minor version (for example,
v1.25
) latest
What if Pod Security Admission isn't the right choice for me?
While Pod Security Admission is always enabled, it can be one of multiple admission controllers. You can configure third-party Kubernetes admission controllers to implement other security policy models that suit your use case.
If you configure Pod Security Admission to enforce, warn, and audit by using the privileged
profile, then the control plane allows all pods to run. You can then configure other admission controllers to reject them.
You can install a third-party admission controller as long as it doesn't take either of the following actions.
- It doesn't install its own pod security policies (PSPs).
- It doesn't rely on PSPs to enforce parts of the policy.
Configuring Pod Security admission namespace labels
You can define the admission control mode you want to use for pod security in each namespace. Kubernetes defines a set of labels that you can set to define which of the predefined Pod Security Standard profiles you want to use for a namespace. The label you select defines what action the control plane takes if a potential violation is detected.
By default, IBM Cloud Kubernetes Service adds the privileged
Pod Security labels to the following namespaces. These namespaces are labeled to enforce
, audit
, and warn
by using the privileged
profile.
kube-system
ibm-system
ibm-operators
calico-system
(Version 1.29 and later)tigera-operator
(Version 1.29 and later)calico-apiserver
(Version 1.31 and later)
Do not remove or change the labels for these namespaces.
A namespace can be labeled to set the pod security profile for any or all the Pod Security Admission modes
.
For example, you can label a namespace to enforce the privileged
profile in addition to using warn
or audit
by using the baseline
profile.
This label allows administrators and application developers to dry-run applications by looking for only warnings and audit records against the baseline
profile without rejecting pods. Then, you can make necessary changes to your
workloads before changing the enforce mode to baseline
.
The Pod Security Admission namespace labels are of the form pod-security.kubernetes.io/<MODE>: <LEVEL>
and pod-security.kubernetes.io/<MODE>-version: <VERSION>
.
pod-security.kubernetes.io/enforce
pod-security.kubernetes.io/enforce-version
pod-security.kubernetes.io/audit
pod-security.kubernetes.io/audit-version
pod-security.kubernetes.io/warn
pod-security.kubernetes.io/warn-version
To label a namespace to enforce the privileged
profile and generate warnings and audit events for violations of the baseline
profile, use the following labels.
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: latest
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/audit-version: latest
pod-security.kubernetes.io/warn: baseline
pod-security.kubernetes.io/warn-version: latest
Default Pod Security Admission plug-in configuration
IBM Cloud Kubernetes Service uses the following PodSecurityConfiguration
by default.
apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
enforce: "privileged"
enforce-version: "latest"
audit: "privileged"
audit-version: "latest"
warn: "privileged"
warn-version: "latest"
exemptions:
usernames: []
runtimeClasses: []
namespaces: []
Customizing the Pod Security Admission plug-in configuration
The cluster-wide Pod Security Admission plug-in configuration sets enforce
, audit
, and warn
behavior for all namespaces that don't have pod security labels or exemptions.
For Kubernetes 1.24 clusters the apiVersion
must be pod-security.admission.config.k8s.io/v1beta
. For 1.25 and later pod-security.admission.config.k8s.io/v1
is preferred, but the v1beta
API
version can still be used.
-
Create a YAML file containing a
PodSecurityConfiguration
resource. You can use the default configuration to start.apiVersion: pod-security.admission.config.k8s.io/v1 kind: PodSecurityConfiguration defaults: enforce: "privileged" enforce-version: "latest" audit: "privileged" audit-version: "latest" warn: "privileged" warn-version: "latest" exemptions: usernames: [] runtimeClasses: [] namespaces: []
-
Make the customizations that you want to use. Review the following the information about each section of the configuration.
defaults
-
The
defaults
section of the configuration defines cluster-wide defaults for namespaces that do not have pod security labels. The fields can have the same values as the corresponding namespace labels. exemptions
-
The
exemptions
section of the configuration allows you to create pods that are otherwise prohibited because of the policy associated with a specific namespace. Exemption dimensions include the following cases.-
Usernames: Requests from users with an exempt authenticated (or impersonated) username are ignored. Usernames are typically IAM users or service accounts. For example
usernames: [ "IAM#user@example.com" ]
. You can also exempt the username associated with anadmin kubeconfig
client certificate. If you want to specify anadmin kubeconfig
certificate, the username is theCN
component of the current client-certificate.kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}' /home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
In the following example, the username is
IBMid-27000xxxxx-admin-2023-05-12
. If you get a newadmin kubeconfig
, the username might be different.openssl x509 -in <client-certificate> -subject -noout` subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
-
RuntimeClassNames: Pods and workload resources specifying an exempt runtime class name are ignored.
-
Namespaces: Pods and workload resources in an exempt namespace are ignored.
-
-
Save your customizations YAML file.
-
Run the
ibmcloud ks cluster master pod-security set
command.ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE
When you run the ibmcloud ks cluster master pod-security set
command, the pod security admission is reset to the default configuration if you do not specify a configuration file.