#Pod Security Policies

ACP supports Kubernetes Pod Security Admission (PSA) and Kyverno Policy to help enforce security standards for Pods running in your clusters.

#Pod Security Admission

Refer to the official Kubernetes documentation: Pod Security Admission

Pod Security Admission (PSA) is a Kubernetes admission controller that enforces security policies at the namespace level by validating Pod specifications against predefined standards.

#Security Modes

PSA defines three modes to control how policy violations are handled:

Key Notes:

• Enforce acts on Pods only (e.g., rejects Pods but allows non-Pod resources like Deployments).
• Audit and Warn apply to both Pods and their controllers (e.g., Deployments).

#Security Standards

PSA defines three security standards to restrict Pod privileges:

#Configuration

#Namespace Labels

Apply labels to namespaces to define PSA policies.

YAML file example

apiVersion: v1
kind: Namespace
metadata:
  name: example-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: baseline

CLI command

# Step 1: Update Pod Admission labels
kubectl label namespace <namespace-name> \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/audit=restricted \
  --overwrite

# Step 2: Verify labels
kubectl get namespace <namespace-name> --show-labels

#Exemptions

Exempt specific users, namespaces, or runtime classes from PSA checks.

Example Configuration:

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
exemptions:
  usernames: ['admin']
  runtimeClasses: ['nvidia']
  namespaces: ['kube-system']

#Kyverno Policy

ACP provides several samples to create the Kyverno policies for Pod security. The samples includes:

• Restricted: Restricted denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace.
• Restricted-v2: Restricted-v2 denies access to all host features and requires pods to be run with a UID, and SELinux context that are allocated to the namespace. This is the most restrictive policy and it is used by default for authenticated users. On top of the legacy 'restricted', it also requires to drop ALL capabilities and does not allow privilege escalation binaries. It will also default the seccomp profile to runtime/default if unset, otherwise this seccomp profile is required.
• Anyuid: Anyuid provides all features of the restricted policy but allows users to run with any UID and any GID.
• Hostaccess: Hostaccess allows access to all host namespaces but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. WARNING: this policy allows host access to namespaces, file systems, and PIDS. It should only be used by trusted pods. Grant with caution.
• Hostmount-anyuid: Hostmount-anyuid provides all the features of the restricted policy but allows host mounts and any UID by a pod. This is primarily used by the persistent volume recycler. WARNING: this policy allows host file system access as any UID, including UID 0. Grant with caution.
• Hostnetwork: Hostnetwork allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace.
• Hostnetwork-v2: Hostnetwork-v2 allows using host networking and host ports but still requires pods to be run with a UID and SELinux context that are allocated to the namespace. On top of the legacy 'hostnetwork' policy, it also requires to drop ALL capabilities and does not allow privilege escalation binaries. It will also default the seccomp profile to runtime/default if unset, otherwise this seccomp profile is required.
• Node-exporter: Node-exporter policy is used for the Prometheus node exporter.
• Nonroot: Nonroot provides all features of the restricted policy but allows users to run with any non-root UID. The user must specify the UID or it must be specified on the by the manifest of the container runtime.
• Nonroot-v2: Nonroot-v2 provides all features of the restricted policy but allows users to run with any non-root UID. The user must specify the UID or it must be specified on the by the manifest of the container runtime. On top of the legacy 'nonroot' policy, it also requires to drop ALL capabilities and does not allow privilege escalation binaries. It will also default the seccomp profile to runtime/default if unset, otherwise this seccomp profile is required.
• Privileged: Privileged allows access to all privileged and host features and the ability to run as any user, any group, any fsGroup, and with any SELinux context. WARNING: this is the most relaxed and should be used only for cluster administration. Grant with caution.

#Prerequisites

• Install Alauda Container Platform Compliance for Kyverno, refer to the document.
• Enable feature gate namespace-resource-manage in ACP featuregate settings.

#Apply Kyverno Policies

#Web Console

1. In the ACP console, navigate to Container Platform, choose the namespace where you want to apply the security policy.
2. Go to Advanced > Resources.
3. Search the resource type with name Policy for resource Policy of group kyverno.io.
4. Select the version "v2beta1", Click Create to create a new Kyverno Policy.
5. In the Create Resource dialog, select the Samples tab.
6. Choose the desired Pod security policy sample (e.g., Restricted), then click Try.
7. Review and modify the policy YAML as needed, then click Update to apply the policy.

#CLI

1. Log in to the kubernetes cluster where you want to apply the security policy.

2. Run the following command to create a Kyverno Policy from a sample resource:

   $ kubectl get consoleyamlsamples.console.alauda.io restricted-policy -otemplate --template={{.spec.yaml}}|kubectl apply -f -
   $ kubectl get policies.kyverno.io
   NAME         ADMISSION   BACKGROUND   READY   AGE   MESSAGE
   restricted   true        true         True    1m   Ready

The sample resources available are:

• restricted-policy
• restrictedv2-policy
• anyuid-policy
• hostaccess-policy
• hostmount-anyuid-policy
• hostnetwork-policy
• hostnetwork-v2-policy
• node-exporter-policy
• nonroot-policy
• nonroot-v2-policy
• privileged-policy