Forem: DEVOPS DYNAMO

CKS SecurityContext Patterns You Must Memorize (Pod vs Container + Fast Verification)

DEVOPS DYNAMO — Thu, 29 Jan 2026 22:47:50 +0000

CKS securityContext questions look scary until you realize they are mostly the same patterns repeated.

Here are the ones you should memorize to move fast during the CKS exam and CKS practice labs.

Pod vs container-level securityContext (quick rule)

Pod-level securityContext = generic defaults for all containers
Container-level securityContext = specific rules for one container

Exam trick:

If they say “Pod”, use Pod-level. If they say “container X”, use container-level. If unsure and lab checker is strict, apply runAs settings in both places.

1) runAsNonRoot + UID/GID

securityContext:
  runAsNonRoot: true
  runAsUser: 101
  runAsGroup: 101

If strict checker, set both Pod-level and container-level:

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 101
    runAsGroup: 101
  containers:
  - name: app
    securityContext:
      runAsNonRoot: true
      runAsUser: 101
      runAsGroup: 101

2) allowPrivilegeEscalation false

securityContext:
  allowPrivilegeEscalation: false

3) Drop ALL capabilities, add NET_BIND_SERVICE

securityContext:
  capabilities:
    drop:
    - ALL
    add:
    - NET_BIND_SERVICE

4) readOnlyRootFilesystem true

securityContext:
  readOnlyRootFilesystem: true

If app breaks, mount emptyDir for writable paths (often /tmp):

volumeMounts:
- name: tmp
  mountPath: /tmp
volumes:
- name: tmp
  emptyDir: {}

Fast verification (kubectl jsonpath)

kubectl -n security-context get pod secure-app -o jsonpath='{.spec.containers[0].securityContext.runAsNonRoot}{"\n"}'
kubectl -n security-context get pod secure-app -o jsonpath='{.spec.containers[0].securityContext.allowPrivilegeEscalation}{"\n"}'

RBAC check:

kubectl auth can-i create rolebindings -n ci-cd --as=system:serviceaccount:ci-cd:ci-bot

nginx-ingress Retirement: Free Checklist To Plan a Safe Migration

DEVOPS DYNAMO — Thu, 25 Dec 2025 16:04:01 +0000

Are you responsible for an nginx ingress migration, or someone on your team is?

I put together a set of free resources to make the process safer and less stressful.

Free migration checklist (Excel):
Payhip: https://payhip.com/b/WgBRS
Gumroad: https://devopsdynamo.gumroad.com/l/Ingress-nginx-migration

If you want more context and patterns, here’s the article:
Medium: https://medium.com/@DynamoDevOps/a-zero-panic-guide-to-migrating-off-ingress-nginx-with-a-free-detailed-checklist-caf355088b6a?postPublishedType=repub

Feel free to share the checklist with teammates who own ingress, DNS, TLS, or cutovers.
If it helps avoid one outage, that’s already a win.

How to Enforce Allowed Kubernetes Image Registries with Kyverno

DEVOPS DYNAMO — Tue, 16 Dec 2025 12:51:35 +0000

If you prefer learning by watching rather than reading, the full lab walkthrough is available in video form on my YouTube channel.

Kubernetes Image Security with Kyverno (Real-World Lab) - Part 1

Controlling which container registries can be used inside a Kubernetes cluster is a core part of supply chain security. If workloads can pull images from any external source, you lose visibility and risk introducing untrusted software. A simple way to lock this down at admission time is to use Kyverno.

This guide walks through building policies that only allow images from approved registries and block everything else. The same approach applies in real production clusters and aligns well with CKS preparation.

Objective

Only permit images from:

registry.company.io

harbor.internal.local

Any Pod pulling from an unapproved registry, including Docker Hub, should be denied during admission.

Confirming the Active Cluster Context

Before you start, verify you're working on the correct cluster:

kubectl config current-context
kubectl get nodes

If the context looks wrong, switch:

kubectl config use-context <context>
kubectl get nodes

Move forward once your nodes show Ready.

Installing Kyverno

Kyverno operates as a set of controllers inside the cluster. If it's not already deployed, install it with Helm.

Check whether it exists:

kubectl get pods -n kyverno

If nothing shows up, add the repo:

helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

Create the namespace if needed:

kubectl create namespace kyverno

Install Kyverno:

helm install kyverno kyverno/kyverno -n kyverno

Verify the controllers are running:

kubectl get pods -n kyverno

Once everything is Running, Kyverno begins intercepting admission requests.

Building the Global Registry Restriction Policy

Create a ClusterPolicy that validates image sources at admission.

File: restrict-registries.yaml

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: enforce
  background: true
  rules:
    - name: validate-registries
      match:
        resources:
          kinds:
            - Pod
      validate:
        message: "Only registry.company.io or harbor.internal.local are allowed."
        pattern:
          spec:
            containers:
              - image: "registry.company.io/* | harbor.internal.local/*"

Apply the policy:

kubectl apply -f restrict-registries.yaml

Check registration:

kubectl get clusterpolicy

You should see restrict-image-registries in the list.

Testing the Policy

You need to validate both failure and success paths.

Test 1: Disallowed registry

kubectl run testbad --image=nginx

This is denied because the image does not match the allowed patterns. The admission error confirms the rule is active.

Test 2: Allowed registry

kubectl run testgood --image=registry.company.io/app:v1
kubectl get pods

Admission succeeds. The Pod may still fail to pull if the registry does not exist, but that is unrelated to the policy.

This proves the global restriction works.

Helpful Verification Commands

kubectl get clusterpolicy
kubectl describe clusterpolicy restrict-image-registries
kubectl get pods
kubectl describe pod testbad
kubectl describe pod testgood

Optional Cleanup

kubectl delete pod testbad testgood --ignore-not-found

Extending the Model for Multi-Environment Clusters

Most real clusters run several environments under the same control plane. A common setup is separate dev and prod namespaces. Each environment may rely on different registries, so policy enforcement must reflect that.

The global policy stays in place. Now add namespace-specific rules.

Creating Environment Namespaces

kubectl create namespace dev
kubectl create namespace prod
kubectl get namespaces

Applying Namespace-Based Registry Policies

Create a second ClusterPolicy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: registry-per-namespace
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: dev-registry-only
      match:
        resources:
          kinds:
            - Pod
          namespaces:
            - dev
      validate:
        message: "Dev namespace must use registry.dev.company.io."
        pattern:
          spec:
            containers:
              - image: "registry.dev.company.io/*"

    - name: prod-registry-only
      match:
        resources:
          kinds:
            - Pod
          namespaces:
            - prod
      validate:
        message: "Prod namespace must use registry.prod.company.io."
        pattern:
          spec:
            containers:
              - image: "registry.prod.company.io/*"

Apply it:

kubectl apply -f registry-per-namespace.yaml

Testing Namespace Restrictions

Dev namespace

kubectl run bad-dev --image=nginx -n dev

This should be rejected.

kubectl run good-dev --image=registry.dev.company.io/app:1.0 -n dev

This is accepted.

Prod namespace

kubectl run bad-prod --image=nginx -n prod
kubectl run good-prod --image=registry.prod.company.io/web:1.0 -n prod

The nginx Pod fails. The registry-approved one passes admission.

How the Layered Approach Works

The cluster-wide policy limits image usage to internal registries only. The per-namespace policy adds a second filter:

dev uses only dev registry images

prod uses only prod registry images

Both policies apply together. A Pod must satisfy both to be admitted. This structure prevents accidental cross-environment deployments and tightens supply chain controls without complicating developer workflows.

Summary

You installed Kyverno, created a global restriction policy for image registries, and validated correct admission behavior. You then extended the scenario with environment-specific rules, ensuring dev and prod cannot cross-pull container images. This is a core security pattern for Kubernetes and aligns directly with CKS study requirements. Once registry control is established, you can layer in tag policies, digest enforcement, and signing rules.

Migrating Off Ingress-NGINX Without Surprises

DEVOPS DYNAMO — Tue, 16 Dec 2025 12:45:12 +0000

While preparing for the ingress-nginx retirement, I documented the key things that actually matter during a real migration, including:

understanding what your ingress layer really does today, not what you think it does
inventorying annotations, TLS, DNS, and risk across services
translating ingress-nginx annotations to Gateway API behavior
running a new controller in parallel to avoid risky cutovers
designing rollback paths before touching production traffic
validating observability, security, and DR early

The full, detailed guide is published on Medium and walks through the entire migration step by step, from discovery to cleanup.

Free migration checklist included

The Medium article also includes a free Excel migration checklist that covers:

discovery and inventory
annotation translation
staging and validation
cutover steps
observability and DR checks
owners, risks, rollback paths, and environments

The checklist is designed for real planning meetings, not documentation theater.

👉 Read the full article on Medium:
A Zero-Panic Guide to Migrating Off Ingress-NGINX
(https://medium.com/@DynamoDevOps/a-zero-panic-guide-to-migrating-off-ingress-nginx-with-a-free-detailed-checklist-caf355088b6a)

If you are planning an ingress-nginx migration before the retirement deadline, the full article and checklist should help you avoid last-minute surprises.

5 Kubernetes YAML Patterns You’ll Actually Use in the Real World

DEVOPS DYNAMO — Thu, 03 Jul 2025 21:19:24 +0000

If you’re studying for the CKA (Certified Kubernetes Administrator) exam — or just trying to get better at managing real production clusters — chances are you've Googled half of these YAMLs at 2AM.

Let’s save you the trouble.

Here are 5 Kubernetes YAML patterns that show up over and over in interviews, in exam labs, and in real deployments.

1. Basic Deployment with Resource Limits

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "200m"
              memory: "256Mi"

✅ Exam-ready
✅ Production-safe

2. Pod with ConfigMap Mounted as Volume

apiVersion: v1
kind: Pod
metadata:
  name: config-demo
spec:
  containers:
    - name: app
      image: busybox
      command: ["/bin/sh", "-c", "cat /etc/config/myconfig"]
      volumeMounts:
        - name: config
          mountPath: /etc/config
  volumes:
    - name: config
      configMap:
        name: my-configmap

3. Service + Ingress Combo (for HTTP Routing)

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web-svc
                port:
                  number: 80

4. Horizontal Pod Autoscaler (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

5. Network Policy to Block All but One Namespace

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-traffic
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: allowed-ns

📘 Want More? Grab the Full CKA Study Guide (Free + Paid Options)

This post is a tiny slice of what’s inside my updated 2025 CKA exam guide. It’s built for engineers who want to actually pass, not just read docs.

🔹 Free Version (Preview)
Download here → Payhip

🔹 Full Edition (50+ Labs + YAML + Traps + 15% Off)
Get it here → Payhip
Use code CKA15SUMMER (expires July 8)

—
Follow me @DynamoDevOps for more clean Kubernetes content.