CKA Scenario: Create a Secure Deployment with BusyBox in a Custom Namespace

When preparing for the Certified Kubernetes Administrator (CKA) exam, you'll encounter scenarios that test not only your ability to create workloads, but also your understanding of security contexts and custom configurations. Let's explore a typical exam challenge and break down both the requirements and the solution.

Scenario

Question:
Create a deployment named rtro in the cal namespace using the image busybox:1.31.1. The deployment should have 2 replicas. The only container in the pod must:

• Run the command sleep 24h

• Use user ID (uid) 1000 and group ID (gid) 1000

• Not allow privilege escalation

The deployment and pods must be created using best security practices.

Step-by-Step Solution

1. Break Down the Requirements

Let’s understand what’s being asked:

• Deployment: We want a managed workload, not a single Pod.

• Namespace: The resources must exist in the cal namespace.

• Image: The container must use busybox:1.31.1.

• Replicas: Set to 2.

• Command/Args: The container should run sleep 24h (using args).

• Security Context:

  • Run as UID and GID 1000.

  • Disallow privilege escalation (allowPrivilegeEscalation: false).

2. Create the Namespace (if not exists)

First, make sure the namespace cal exists:

kubectl create namespace cal

3. Generate the Deployment YAML

You can generate a baseline YAML for the deployment using kubectl with a dry-run. This doesn't create the resources, but instead outputs the manifest, which you can edit and apply26:

kubectl create deployment rtro \
  --image=busybox:1.31.1 \
  --replicas=2 \
  --namespace=cal \
  --dry-run=client -o yaml > rtro.yaml

4. Edit the YAML File

Open rtro.yaml and edit the following:

• Add args under the container for sleep 24h

• Add securityContext to set UID, GID, and privilege escalation settings

Final YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rtro
  namespace: cal
spec:
  replicas: 2
  selector:
    matchLabels:
      app: rtro
  template:
    metadata:
      labels:
        app: rtro
    spec:
      containers:
      - name: busybox
        image: busybox:1.31.1
        args: ["sleep", "24h"]
        securityContext:
          runAsUser: 1000
          runAsGroup: 1000
          allowPrivilegeEscalation: false

5. Apply the Deployment

Deploy using:

kubectl apply -f rtro.yaml

6. Verify the Deployment

Check if the deployment and pods are running as expected:

kubectl get deployment rtro -n cal
kubectl get pods -n cal

You can describe one of the pods to ensure the security settings are in place:

kubectl describe pod <rtro-pod-name> -n cal

Detailed Explanation

Why use sleep 24h?
This command ensures the pod stays alive for 24 hours, useful as a placeholder or for debugging.

Why set runAsUser and runAsGroup?
For security, running containers as a non-root user (UID/GID 1000 in this case) is a best-practice, minimizing the risk in case of container compromise25.

Why is allowPrivilegeEscalation: false important?
This prevents processes in the container from trying to gain more privileges (such as root), even if vulnerable binaries exist. This aligns with Kubernetes security best practices for runtime hardening2.

Why use YAML and not a single imperative command?
While some simple workloads can be created imperatively, complex scenarios (like custom args and security contexts) are best handled with manifests, a practice also recommended for the CKA exam26.

Summary Table

Conclusion

Such a scenario is highly representative of the CKA exam’s focus on both practical Kubernetes usage and security. If you practice with dry-run, YAML edits, and understand the why behind security settings, you’ll be well-prepared for similar real-world and exam challenges.