This course was created by a community author. Community content is reviewed by the iximiuz Labs team on a best effort basis.

Course Last updated: Jun 3, 2026

DevSecOps in Practice: Container & Kubernetes Security

by Puru Tuladhar · on

Security Kubernetes Containers

Hands-on security course with live Docker and Kubernetes environments. Harden images, enforce Pod Security Standards, lock down RBAC, manage secrets with Vault, detect runtime threats with Falco, and prevent credential leaks with Gitleaks — all with automated feedback.

#devsecops #container-security #kubernetes-security #secrets-management #runtime-security

DevSecOps in Practice: Container & Kubernetes Security (cover image)

Reset Progress

Are you sure you want to reset your progress for this course? This action cannot be undone.

About This Course

Welcome to DevSecOps in Practice — a hands-on course that takes you through the most critical security controls in a modern containerised infrastructure stack.

Every lesson drops you into a live environment: a real Docker host or a running Kubernetes cluster. You run the commands, the platform checks your work, and you move on only when each step is verified.

What You Will Learn

Module	Topic	Environment
1	Container Security	Docker
2	Kubernetes Pod & Namespace Security	Kubernetes
3	Network Policy & Mutual TLS	Kubernetes
4	RBAC & Audit Logging	Kubernetes
5	Secrets Management	Kubernetes
6	Secret Scanning & Runtime Detection	Docker + Kubernetes

Start with Module 1 and work through them in order — each module builds on the previous.

What's Inside?

Module 1: Container SecurityBuild and harden Docker images. Learn why base image choice matters, how multi-stage builds eliminate build tools from production images, and how to use Trivy to block deployments with critical CVEs.
Lesson: Docker Image HardeningA typical production Docker image runs as root and carries hundreds of CVEs. Using only standard Dockerfile techniques, you'll shrink it from 921 MB to under 60 MB, eliminate root, and lock down the filesystem.
Lesson: Trivy: CVE Scanning & SBOMScan images for known vulnerabilities, compare a bloated Debian image against a minimal Alpine image, generate a Software Bill of Materials (SBOM), and configure Trivy as a CI/CD gate that fails the build on critical CVEs.
Module 2: Kubernetes FoundationsDeploy your first workload with security defaults baked in from day one — non-root, pinned image tags, resource limits. Understand why each setting matters before moving on to more advanced security controls.
Lesson: Your First Deployment — Security Defaults from Day OneMost tutorials deploy nginx as root with no resource limits and call it done. This lab does it the right way from the start: non-root container, read-only filesystem, resource limits, and a proper Service for exposure. You will also learn the core kubectl commands that every Kubernetes operator uses daily.
Lesson: Resource Limits & Denial-of-Service PreventionA pod without resource limits can consume all CPU and memory on its node — whether by bug, misconfiguration, or deliberate attack. This is a denial-of-service condition. Kubernetes Quality of Service (QoS) classes give you three levels of resource guarantee. This lab demonstrates the noisy neighbour problem and then shows how limits isolate the blast radius.
Module 3: Resilience & Safe OperationsKubernetes can patch a fleet of pods with zero downtime — but only if you know how to drive the rollout. Use rolling updates to swap out a CVE-laden image while traffic keeps flowing, and add health probes so Kubernetes self-heals without human intervention.
Lesson: Rolling Updates — Zero-Downtime CVE PatchingA vulnerability is discovered in your running container image. In a traditional server environment, patching means downtime. In Kubernetes, a rolling update replaces every pod one by one while traffic keeps flowing. This lab scans a running deployment for CVEs, patches it to a clean image, and proves no requests were dropped during the upgrade.
Lesson: Health Probes & Self-HealingWithout health probes, Kubernetes routes traffic to pods that are starting up, overloaded, or broken — silently dropping requests. With liveness and readiness probes configured, Kubernetes self-heals: it restarts unhealthy pods and stops routing traffic to pods that aren't ready. Availability is part of the CIA triad — this lab shows how Kubernetes enforces it automatically.
Module 4: Configuration & ObservabilitySensitive configuration managed the wrong way is a breach waiting to happen. Walk from hardcoded secrets to ConfigMaps to Kubernetes Secrets and prove base64 is not encryption. Then deploy Prometheus and Grafana to build the visibility needed to detect incidents early.
Lesson: ConfigMaps & Secrets — The Right and Wrong WaySensitive configuration baked into a container image is a breach waiting to happen. Walk through the full progression: hardcoded credentials → ConfigMap (still visible) → Kubernetes Secret (base64 is not encryption — live proof) → correct secret consumption patterns. This lab sets up the "why" before the companion course shows you Vault and the External Secrets Operator.
Lesson: Observability — Detecting Security Anomalies with PrometheusYou cannot defend what you cannot see. Deploy Prometheus to scrape cluster metrics, then simulate real attack signals — crash loops and OOMKills — and catch them by querying metrics directly. Observability is the foundation that makes security incidents detectable before they become outages.
Module 5: Secrets ManagementKubernetes Secrets are base64, not encrypted — but they keep credentials out of manifests and git history. Learn correct secret consumption patterns, then upgrade to HashiCorp Vault with the External Secrets Operator for centralised management and automatic rotation.
Lesson: Kubernetes Secrets: Safe ConsumptionProve that base64 is not encryption — decode a Kubernetes Secret in two commands. Then see what we are actually avoiding: hardcoded credentials in manifests that end up in git history and the API server forever. Both env vars and volume mounts solve the problem by keeping credentials out of manifests entirely.
Lesson: HashiCorp Vault + External Secrets OperatorDeploy Vault, store database credentials and API keys in it, then install the External Secrets Operator to sync them into Kubernetes Secrets automatically. Update the secret in Vault and watch Kubernetes rotate it — no manual intervention required.
Module 6: Workload SecurityEnforce Pod Security Standards to block privileged containers, apply different security levels per namespace, and scope RBAC so a compromised service account in dev cannot reach production.
Lesson: Pod Hardening & Pod Security AdmissionDeploy an insecure privileged pod, then apply Kubernetes Pod Security Admission (PSA) to a namespace. Watch PSA block the insecure pod at admission time — before any code runs. Finally, deploy a fully hardened pod that passes the restricted standard.
Lesson: Namespace & RBAC IsolationApply different Pod Security Standard levels to dev, staging, and production namespaces. Create a service account scoped to the dev namespace and prove that a compromised dev account cannot list pods in production.
Module 7: Network SecurityKubernetes allows all pod-to-pod traffic by default. Apply NetworkPolicy to enforce a strict traffic matrix, then add mutual TLS so services authenticate each other's certificates — no certificate, no connection.
Lesson: Kubernetes Network PolicyBy default, every pod in a Kubernetes cluster can reach every other pod. Apply a default-deny NetworkPolicy, then selectively re-open only the paths that need to exist: frontend to backend, backend to database — but never frontend directly to database.
Lesson: Mutual TLS with Istio Service MeshWith Istio, mTLS between services is automatic — no certificate files to manage, no nginx config to touch. Install Istio, label a namespace for sidecar injection, deploy two services, and enforce STRICT mTLS with a single PeerAuthentication resource. The Envoy proxy handles everything transparently.
Module 8: Access ControlDemonstrate how cluster-admin on a service account gives an attacker full cluster control, then implement least-privilege RBAC. Enable Kubernetes audit logging to capture who accessed secrets, created pods, and changed RBAC bindings.
Lesson: RBAC — Least PrivilegeCreate a service account with cluster-admin and prove it can delete nodes, read any secret, and escalate privileges. Then create a properly scoped service account that can only read ConfigMaps and Secrets in one namespace — nothing else.
Lesson: Kubernetes Audit LoggingEnable audit logging on a kubeadm cluster by editing the kube-apiserver static pod manifest, write an audit policy that captures secret access and RBAC changes, generate real API events, and read the structured log entries.
Module 9: GitOps & Policy EnforcementGitOps makes every cluster change auditable and reversible. Argo CD detects drift the moment someone runs a manual kubectl apply. Kyverno enforces security policies at admission time — no latest tags, no root containers, no missing limits — before any workload ever starts.
Lesson: GitOps with Argo CD — Every Change AuditableWithout GitOps, anyone with kubectl access can change the cluster and leave no trace. With Argo CD, git is the single source of truth — every change is a commit, every deployment is a reconciliation. This lab installs Argo CD, deploys an application from a git-tracked manifest, and demonstrates drift detection: make a manual change and watch Argo CD flag and reverse it.
Lesson: Policy-as-Code with KyvernoRBAC controls who can do things. Kyverno controls what can be done — at admission time, before any container ever starts. Write policies that block the latest image tag (unpinned versions are a supply-chain risk), require resource limits on every container, and mandate non-root execution. Then prove that non-compliant workloads are rejected by the API server before they reach the scheduler.
Module 10: Secure Packaging & Supply-Chain TrustHelm charts are the standard packaging format for Kubernetes applications. A well-designed chart bakes security defaults into its templates. Image signing with cosign ensures only cryptographically verified images run in your cluster.
Lesson: Helm — Packaging Security Into Your App TemplateHelm charts are the standard packaging format for Kubernetes applications. A well-designed chart bakes security defaults into its templates: non-root securityContext, resource limits, and NetworkPolicy are set correctly by default — making the insecure path require explicit opt-out. This lab creates a chart from scratch, codes security settings as required defaults, and uses helm template to dry-run before deploying.
Lesson: Supply-Chain Security — Image Signing & VerificationEven if your image passes Trivy scanning, an attacker who gains registry write access can push a malicious image with the same tag. Image signing with cosign adds a cryptographic signature — and a Kyverno policy enforces that only signed images run in your cluster. An unsigned image is rejected at admission time, even if the tag and digest look correct.
Module 11: Secret Scanning & Runtime Threat DetectionCredentials committed to git persist in history forever. Gitleaks scans the full git history and blocks secrets at commit time. Falco watches kernel syscalls to detect attacks at runtime — shell in container, sensitive file reads, unexpected network connections.
Lesson: Secret Scanning with GitleaksCommit API keys to a git repo, then "remove" them. Gitleaks finds them anyway — they're still in history. Install a pre-commit hook that blocks secrets before they ever enter the repository, and verify it catches the next attempt.
Lesson: Runtime Threat Detection with FalcoInstall Falco using its modern eBPF driver. Deploy a test pod, then trigger real security events — spawn a shell inside the container, read sensitive files, make outbound connections. Read the Falco alerts and understand how to route them to a SIEM.

About the author

Puru Tuladhar

✍️ Author | 👨‍🏫 Kubernetes Trainer | 👥 Kubernetes Consultant | 🎡 Kubestronaut

Find this author online

How to Author Courses on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull course content

labctl content pull course devsecops-security-hands-on-9dc87991

This will create a local copy of the course content in a directory named devsecops-security-hands-on-9dc87991. You only need to do this once per course.

Stream your changes

labctl content push -fw course devsecops-security-hands-on-9dc87991

Run this command in a separate terminal to continuously upload your changes to the server while editing the course in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help