Pod security admission controller in Kubernetes - Commands & Configuration

Introduction

Sometimes pods in Kubernetes can run with unsafe settings that might cause security risks. The Pod Security Admission Controller helps by checking pods when they are created and making sure they follow security rules to keep the cluster safe.

When you want to prevent pods from running as root user to avoid privilege escalation.

When you need to enforce that pods do not use host network or host PID to limit access to the node.

When you want to make sure pods have proper security context settings like read-only root filesystem.

When you want to apply different security policies to different namespaces automatically.

When you want to block pods that do not meet your organization's security standards before they start.

Config File - pod-security.yaml

pod-security.yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535

This file defines a PodSecurityPolicy named 'restricted' that enforces strict security rules:

• privileged: false - Pods cannot run in privileged mode.
• allowPrivilegeEscalation: false - Prevents privilege escalation.
• requiredDropCapabilities: ALL - Drops all Linux capabilities.
• volumes - Only allows safe volume types.
• hostNetwork, hostIPC, hostPID: false - Disallows access to host networking and IPC.
• runAsUser: MustRunAsNonRoot - Pods must run as non-root user.
• supplementalGroups and fsGroup - Enforces group IDs for file permissions.

Commands

This command applies the PodSecurityPolicy configuration to the Kubernetes cluster to enforce the security rules defined.

Terminal

kubectl apply -f pod-security.yaml

Expected Output

podsecuritypolicy.policy/restricted created

This command lists all PodSecurityPolicies currently configured in the cluster to verify that the 'restricted' policy is active.

Terminal

kubectl get podsecuritypolicy

Expected Output

NAME         PRIV    CAPS   SELINUX   RUNASUSER          FSGROUP   SUPGROUP   READONLYROOTFS   VOLUMES

restricted   false   ALL    RunAsAny  MustRunAsNonRoot   MustRunAs MustRunAs  false            configMap,emptyDir,projected,secret,downwardAPI

Creates a new namespace called 'secure-app' where we can enforce the Pod Security Admission Controller policies.

Terminal

kubectl create namespace secure-app

Expected Output

namespace/secure-app created

Labels the 'secure-app' namespace to enforce the 'restricted' Pod Security Admission Controller policy on all pods created in this namespace.

Terminal

kubectl label namespace secure-app pod-security.kubernetes.io/enforce=restricted

Expected Output

namespace/secure-app labeled

Attempts to create a pod named 'test-pod' in the 'secure-app' namespace running as root user, which should be blocked by the Pod Security Admission Controller.

Terminal

kubectl run test-pod --image=nginx --namespace=secure-app --restart=Never --overrides='{ "apiVersion": "v1", "spec": { "securityContext": { "runAsUser": 0 } } }'

Expected Output

Error from server (Forbidden): error when creating "STDIN": pods "test-pod" is forbidden: violates PodSecurity "restricted": running as root is not allowed

Key Concept

If you remember nothing else from this pattern, remember: Pod Security Admission Controller automatically blocks pods that do not meet your security rules before they run.

Common Mistakes

Not labeling the namespace with the correct pod-security.kubernetes.io/enforce label.

Without the label, the Pod Security Admission Controller does not enforce any policy on pods in that namespace.

Always add the correct label to the namespace to activate the desired security policy.

Trying to create pods that run as root when the policy requires non-root users.

Pods running as root violate the security policy and will be rejected by the admission controller.

Set the pod's securityContext to run as a non-root user or omit runAsUser to use defaults.

Applying PodSecurityPolicy without enabling the admission controller in the cluster.

The policies won't be enforced if the admission controller is not enabled in the Kubernetes API server.

Ensure the Pod Security Admission Controller is enabled in your cluster configuration.

Summary

Apply a PodSecurityPolicy YAML file to define security rules for pods.

Label namespaces to enforce these policies automatically on pods created inside them.

Try creating pods that violate the policy to see the admission controller block them.

Use kubectl commands to verify policies and namespace labels.

Practice

1. What is the primary purpose of the Pod Security Admission Controller in Kubernetes?

easy

A. To monitor pod resource usage

B. To manage network traffic between pods

C. To schedule pods on specific nodes

D. To enforce security policies on pods based on predefined security levels

Solution

1. Step 1: Understand the role of Pod Security Admission Controller

   This controller enforces security policies on pods to ensure they meet security standards.

2. Step 2: Differentiate from other controllers

   It does not manage networking, scheduling, or resource monitoring, which are handled by other components.

3. Final Answer:

   To enforce security policies on pods based on predefined security levels -> Option D

4. Quick Check:

   Pod Security Admission = Enforce security policies [OK]

Hint: Remember: Pod Security Admission controls pod security levels [OK]

Common Mistakes:

• Confusing it with network or scheduling controllers
• Thinking it monitors resource usage
• Assuming it manages pod lifecycle

2. Which of the following is the correct way to specify the enforce mode for the Pod Security Admission Controller in a Kubernetes API server configuration?

easy

A. --enable-admission-plugins=PodSecurity --pod-security-enforce=audit

B. --enable-admission-plugins=PodSecurity --pod-security-mode=enforce

C. --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted

D. --admission-control=PodSecurity --pod-security-enforce=baseline

Solution

1. Step 1: Identify correct flag names for Pod Security Admission

   The correct flags are --enable-admission-plugins=PodSecurity and --pod-security-enforce=LEVEL where LEVEL is one of privileged, baseline, or restricted.

2. Step 2: Verify option syntax and values

   --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted: --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted uses correct flag names and a valid security level 'restricted'. Options A uses invalid level, B uses incorrect flag --pod-security-mode, and C uses deprecated --admission-control.

3. Final Answer:

   --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted -> Option C

4. Quick Check:

   Correct flags + valid level = --enable-admission-plugins=PodSecurity --pod-security-enforce=restricted [OK]

Hint: Look for exact flag names and valid security levels [OK]

Common Mistakes:

• Using wrong flag names like --admission-control
• Confusing enforce mode with audit or warn
• Using invalid security levels

3. Given this Pod Security Admission configuration snippet:

apiVersion: policy/v1
kind: PodSecurity
metadata:
  name: enforce-baseline
spec:
  enforce:
    level: baseline
    version: "latest"
  warn:
    level: restricted
    version: "latest"
  audit:
    level: privileged
    version: "latest"

What will happen if a pod with privileged permissions is created?

medium

A. The pod creation will be blocked due to enforcement at baseline level

B. The pod creation will succeed but a warning will be logged

C. The pod creation will succeed without any warnings or audits

D. The pod creation will be audited but allowed

Solution

1. Step 1: Understand enforcement level

   The enforce level is set to baseline, which blocks pods that do not meet baseline security standards, including privileged pods.

2. Step 2: Analyze pod permissions against levels

   Privileged pods exceed baseline restrictions, so enforcement blocks creation. Warnings and audits apply to lower levels but enforcement is strictest.

3. Final Answer:

   The pod creation will be blocked due to enforcement at baseline level -> Option A

4. Quick Check:

   Enforce baseline blocks privileged pods [OK]

Hint: Enforce blocks pods below level; privileged > baseline [OK]

Common Mistakes:

• Confusing warn or audit with enforce
• Assuming privileged pods pass baseline enforcement
• Ignoring enforcement priority over warnings

4. You configured the Pod Security Admission Controller with --pod-security-enforce=restricted, but pods with privileged containers are still being created. What is the most likely cause?

medium

A. The pods are created in namespaces labeled to exempt enforcement

B. The admission controller is not enabled in the API server

C. The pod spec has incorrect securityContext fields

D. The Kubernetes version does not support Pod Security Admission Controller

Solution

1. Step 1: Check admission controller enablement

   If the controller was not enabled, no enforcement would occur cluster-wide, but the question implies partial enforcement.

2. Step 2: Understand namespace labels impact

   Namespaces can be labeled to exempt or relax enforcement, allowing privileged pods despite cluster-wide settings.

3. Step 3: Consider other options

   Incorrect pod specs or Kubernetes version issues would cause errors or no enforcement at all, not selective allowance.

4. Final Answer:

   The pods are created in namespaces labeled to exempt enforcement -> Option A

5. Quick Check:

   Namespace labels can exempt enforcement [OK]

Hint: Check namespace labels for enforcement exemptions [OK]

Common Mistakes:

• Assuming controller is disabled without checking labels
• Ignoring namespace-level exemptions
• Blaming pod spec errors for enforcement bypass

5. You want to enforce the Pod Security Admission Controller to block all pods that request hostPath volumes except in a specific namespace called trusted. How should you configure this?

hard

A. Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: baseline

B. Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: privileged

C. Set cluster-wide enforcement to baseline and label the trusted namespace with pod-security.kubernetes.io/enforce: baseline

D. Set cluster-wide enforcement to privileged and label the trusted namespace with pod-security.kubernetes.io/enforce: restricted

Solution

1. Step 1: Understand security levels and hostPath restrictions

   The restricted level blocks hostPath volumes, while privileged allows them.

2. Step 2: Apply cluster-wide enforcement and namespace override

   Set cluster-wide enforcement to restricted to block hostPath everywhere by default. Label the trusted namespace with pod-security.kubernetes.io/enforce: privileged to allow exceptions.

3. Step 3: Verify option correctness

   Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: privileged correctly sets cluster-wide to restricted and trusted namespace to privileged, allowing hostPath only there.

4. Final Answer:

   Set cluster-wide enforcement to restricted and label the trusted namespace with pod-security.kubernetes.io/enforce: privileged -> Option B

5. Quick Check:

   Cluster restricted + trusted privileged = hostPath allowed only in trusted [OK]

Hint: Cluster restrict + namespace privileged allows exceptions [OK]

Common Mistakes:

• Setting cluster enforcement too low to block hostPath
• Using baseline instead of privileged for exceptions
• Labeling trusted namespace with a stricter level