Pod security standards in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Pod Security Standards Levels

Which of the following best describes the restricted Pod Security Standard level in Kubernetes?

A Allows all privileges and capabilities, suitable for trusted workloads.

B Allows some privileges but restricts host networking and volume types.

C Only restricts container image sources but allows all capabilities.

D Disallows privileged containers and host namespaces, enforcing strict security.

💡 Hint

Think about the strictest security level that blocks privileged access.

The restricted level enforces the highest security by disallowing privileged containers and host namespaces, ensuring minimal risk.

💻 Command Output

intermediate

Output of Applying a Pod Security Admission Label

What is the output when you run the following command to label a namespace for the baseline Pod Security Standard enforcement?

kubectl label namespace dev pod-security.kubernetes.io/enforce=baseline

A Error from server (NotFound): namespaces "dev" not found

B namespace/dev labeled

C Warning: label pod-security.kubernetes.io/enforce already exists

D No resources labeled

💡 Hint

Check if the namespace exists before labeling.

If the namespace 'dev' exists, the command labels it and outputs 'namespace/dev labeled'.

❓ Configuration

advanced

Correct Pod Security Admission Configuration in Namespace YAML

Which snippet correctly configures a namespace YAML manifest to enforce the restricted Pod Security Standard at the enforce level?

A

metadata:
  name: secure-ns
  annotations:
    pod-security.kubernetes.io/enforce-level: restricted

B

metadata:
  name: secure-ns
  labels:
    pod-security.kubernetes.io/enforce-level: restricted

C

metadata:
  name: secure-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted

D

metadata:
  name: secure-ns
  annotations:
    pod-security.kubernetes.io/enforce: restricted

💡 Hint

Pod Security Admission uses labels, not annotations, for enforcement.

The correct way is to use the label 'pod-security.kubernetes.io/enforce' with the value 'restricted' under metadata.labels.

❓ Troubleshoot

advanced

Troubleshooting Pod Creation Failure Due to Pod Security Admission

A developer tries to create a pod in a namespace labeled with pod-security.kubernetes.io/enforce=restricted but gets an error. Which of the following pod specs is most likely causing the failure?

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: app
    image: nginx
    securityContext:
      privileged: true

A The pod uses a privileged container which is disallowed by the restricted policy.

B The pod image nginx is not allowed in restricted mode.

C The pod lacks resource limits causing the failure.

D The pod is missing a service account annotation.

💡 Hint

Restricted policy blocks privileged containers.

The restricted Pod Security Standard disallows privileged containers, so setting privileged: true causes rejection.

✅ Best Practice

expert

Best Practice for Gradual Pod Security Standard Adoption

You want to gradually enforce Pod Security Standards in a large cluster without breaking existing workloads immediately. Which approach is best?

A Use <code>pod-security.kubernetes.io/warn=baseline</code> labels first to audit violations before enforcing.

B Label all namespaces with <code>pod-security.kubernetes.io/enforce=restricted</code> at once.

C Remove all Pod Security Admission controllers to avoid enforcement issues.

D Manually edit each pod to comply before applying any namespace labels.

💡 Hint

Start by warning to identify issues before blocking pods.

Using the warn label allows you to see policy violations without blocking pod creation, enabling gradual adoption.

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