Pod security standards in Kubernetes - Commands & Configuration

Introduction

Pod security standards help keep your Kubernetes pods safe by setting rules about what pods can and cannot do. They protect your cluster from risky or harmful pod configurations.

When you want to prevent pods from running as root user to improve security.

When you need to restrict pods from accessing the host network or host filesystem.

When you want to enforce consistent security settings across all pods in a namespace.

When you want to block pods that use privileged containers or dangerous capabilities.

When you want to apply different security levels for development and production environments.

Config File - pod-security-standards.yaml

pod-security-standards.yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-psp
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
  readOnlyRootFilesystem: false

This PodSecurityPolicy named restricted-psp sets strict rules:

• privileged: false disallows privileged containers.
• allowPrivilegeEscalation: false blocks privilege escalation.
• requiredDropCapabilities: ALL drops all extra Linux capabilities.
• volumes limits allowed volume types.
• hostNetwork, hostIPC, hostPID: false prevents pods from using host namespaces.
• runAsUser: MustRunAsNonRoot forces pods to run as non-root users.
• supplementalGroups and fsGroup enforce group ID ranges.

This policy helps enforce the restricted Pod Security Standard.

Commands

This command applies the PodSecurityPolicy to the Kubernetes cluster, creating the restricted security rules for pods.

Terminal

kubectl apply -f pod-security-standards.yaml

Expected Output

podsecuritypolicy.policy/restricted-psp created

This command retrieves and shows the details of the applied PodSecurityPolicy to verify it was created correctly.

Terminal

kubectl get podsecuritypolicy restricted-psp -o yaml

Expected Output

apiVersion: policy/v1beta1

kind: PodSecurityPolicy

metadata:

  name: restricted-psp

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

  readOnlyRootFilesystem: false

→

-o yaml - Outputs the policy details in YAML format for easy reading

This command checks if your current user or service account has permission to use the restricted PodSecurityPolicy.

Terminal

kubectl auth can-i use podsecuritypolicy restricted-psp

Expected Output

yes

Key Concept

If you remember nothing else from this pattern, remember: Pod security standards set clear rules to keep pods safe by limiting risky permissions and actions.

Common Mistakes

Not applying the PodSecurityPolicy to the correct namespace or user roles.

The policy exists but pods or users cannot use it, so security is not enforced.

Bind the PodSecurityPolicy to the right namespaces and user roles using RoleBindings or ClusterRoleBindings.

Allowing privileged containers or running pods as root unintentionally.

This opens security risks like privilege escalation or host access.

Set privileged to false and runAsUser rule to MustRunAsNonRoot in the policy.

Summary

Create a PodSecurityPolicy YAML file that defines strict security rules for pods.

Apply the policy to the cluster using kubectl apply.

Verify the policy is created and check permissions with kubectl commands.

Practice

1. What is the main purpose of Kubernetes Pod Security Standards?

easy

A. To control pod permissions and prevent risky behaviors

B. To increase pod resource limits automatically

C. To schedule pods on specific nodes

D. To monitor pod network traffic

Solution

1. Step 1: Understand Pod Security Standards

   Pod Security Standards define rules to restrict pod permissions and behaviors.

2. Step 2: Identify the main goal

   The goal is to prevent risky pod behaviors like running as root or privileged mode.

3. Final Answer:

   To control pod permissions and prevent risky behaviors -> Option A

4. Quick Check:

   Pod Security Standards = Control permissions [OK]

Hint: Pod Security Standards limit pod permissions to keep cluster safe [OK]

Common Mistakes:

• Confusing security standards with resource management
• Thinking it schedules pods on nodes
• Assuming it monitors network traffic

2. Which of the following is the correct way to label a namespace to enforce the 'restricted' Pod Security Standard in Kubernetes?

easy

A. kubectl set security namespace myns restricted

B. kubectl label pod mypod pod-security.kubernetes.io/enforce=restricted

C. kubectl annotate namespace myns pod-security.kubernetes.io/enforce=restricted

D. kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted

Solution

1. Step 1: Identify correct resource and command

   Pod Security Standards are enforced by labeling namespaces, not pods.

2. Step 2: Check correct syntax for labeling namespace

   The correct command is 'kubectl label namespace <name> pod-security.kubernetes.io/enforce=restricted'.

3. Final Answer:

   kubectl label namespace myns pod-security.kubernetes.io/enforce=restricted -> Option D

4. Quick Check:

   Label namespace with enforce=restricted [OK]

Hint: Label namespaces, not pods, to enforce Pod Security Standards [OK]

Common Mistakes:

• Labeling pods instead of namespaces
• Using annotate instead of label
• Using invalid kubectl commands

3. Given this pod spec snippet, which Pod Security Standard will it most likely violate?

{
  "securityContext": {
    "runAsUser": 0,
    "privileged": true
  }
}

medium

A. Baseline

B. Restricted

C. Privileged

D. None

Solution

1. Step 1: Analyze pod securityContext

   The pod runs as user 0 (root) and uses privileged mode, which is risky.

2. Step 2: Match with Pod Security Standards

   Restricted standard forbids running as root and privileged mode, so this pod violates Restricted.

3. Final Answer:

   Restricted -> Option B

4. Quick Check:

   Root + privileged = violates Restricted [OK]

Hint: Root user and privileged mode break Restricted standard [OK]

Common Mistakes:

• Confusing Baseline and Restricted standards
• Thinking privileged mode is allowed in Restricted
• Assuming no violation if pod runs as root

4. You labeled a namespace with pod-security.kubernetes.io/enforce=restricted, but pods running as root are still allowed. What is the most likely reason?

medium

A. The Pod Security Admission controller is not enabled in the cluster

B. The label was applied to the pod instead of the namespace

C. The pod spec is missing the securityContext field

D. The namespace label should be 'pod-security.kubernetes.io/warn=restricted'

Solution

1. Step 1: Understand enforcement mechanism

   Pod Security Standards enforcement requires the Pod Security Admission controller enabled in the cluster.

2. Step 2: Check other options

   Labeling pod instead of namespace or missing securityContext won't bypass enforcement if controller is active. Warning label only warns, does not enforce.

3. Final Answer:

   The Pod Security Admission controller is not enabled in the cluster -> Option A

4. Quick Check:

   Admission controller must be enabled for enforcement [OK]

Hint: Enforcement needs admission controller enabled [OK]

Common Mistakes:

• Applying label to pod instead of namespace
• Confusing warn label with enforce label
• Assuming missing securityContext disables enforcement

5. You want to enforce the 'baseline' Pod Security Standard but allow some pods to run as root for legacy reasons. Which approach best balances security and flexibility?

hard

A. Disable Pod Security Admission controller and manually review pods

B. Label the namespace with 'pod-security.kubernetes.io/enforce=restricted' and remove root user from all pods

C. Label the namespace with 'pod-security.kubernetes.io/enforce=baseline' and use Pod Security Exceptions for specific pods

D. Label each pod with 'pod-security.kubernetes.io/enforce=baseline' individually

Solution

1. Step 1: Understand baseline enforcement with exceptions

   Baseline standard is less strict than restricted and allows some flexibility.

2. Step 2: Use exceptions for legacy pods

   Pod Security Exceptions allow specific pods to bypass some rules while enforcing baseline on the namespace.

3. Step 3: Evaluate other options

   Restricted is stricter, disabling admission controller removes security, labeling pods individually is not standard practice.

4. Final Answer:

   Label the namespace with 'pod-security.kubernetes.io/enforce=baseline' and use Pod Security Exceptions for specific pods -> Option C

5. Quick Check:

   Baseline + exceptions = balance security and legacy needs [OK]

Hint: Use baseline label plus exceptions for legacy pods [OK]

Common Mistakes:

• Using restricted standard which is too strict
• Disabling admission controller reduces security
• Labeling pods individually instead of namespace