Container and Kubernetes Security

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: Modern cloud applications are overwhelmingly packaged in containers and run at scale by orchestration platforms like Kubernetes. This is the technology of how software actually runs today — and it has its own substantial security considerations at every layer. This page secures that stack. It connects directly to the container material in your On-Prem/DevOps module: you already understand containers and orchestration — this is the security layer over them.

Part 1: The Problem

The way software is packaged and run has changed. Modern applications are largely built as containers — and run, at scale, by container orchestration platforms, the dominant one being Kubernetes. This is not a niche; it is how a great deal of modern cloud software runs.

That shift brings its own security considerations. A containerized, orchestrated application has layers — the container image, the running container, the orchestration platform, the underlying hosts — and each layer has things that can go wrong. Securing this stack is a real and in-demand part of cloud security.

This page assumes you understand what containers and orchestration are — and you do: your On-Prem/DevOps module covers exactly this technology. That is a genuine advantage. Where someone new to the field would have to learn containers and their security at once, you already have the foundation. This page is the security layer over technology you already know. (If the container/orchestration concepts feel rusty, review that module’s relevant pages alongside this one.)

Part 2: The Concept — Containers and Their Security Model

A quick security-focused framing of what a container is (full coverage is in your DevOps module).

A container packages an application together with everything it needs to run, as a single, portable, isolated unit. Containers are created from container images — the templates that define what is in a container. Containers run isolated from one another and from the host.

The security-relevant points:

• Containers provide isolation — but it is not the same as a separate machine. Containers isolate applications from each other, which is a security benefit. But that isolation is not as strong as the isolation between separate virtual machines. This matters: a container is not an impenetrable box, and “container escape” — breaking out of a container’s isolation — is a real category of concern.
• A container is only as secure as its image. A container is created from an image. If the image is insecure — built with vulnerabilities, with secrets baked in, from an untrustworthy source — every container created from it inherits that insecurity (Part 3).
• Containers run with permissions. A container, and the processes in it, run with some level of privilege. Over-privileged containers are a real risk (Part 4) — the least-privilege principle, applied to containers.
• The container stack has layers. Image → container → orchestration → host. Security applies at each layer (Parts 3–5). A weakness at any layer is a weakness in the whole.

The mindset: containers are a packaging-and-running technology with real security benefits (isolation, consistency) and real security responsibilities at every layer. Treating “we use containers” as automatically secure is a mistake.

Part 3: The Concept — Image Security and the Supply Chain

Because a container is created from an image, image security is foundational — get the image wrong and every container from it is compromised.

The key image security concerns:

Vulnerable components in the image. A container image bundles an application and its dependencies and often an operating-system layer. All of that can contain known vulnerabilities — this is exactly the vulnerable-components / supply-chain problem from 2.10, now packaged into an image. An image built on an outdated base, or bundling vulnerable libraries, ships those vulnerabilities into every container.

The defense: image scanning — automatically scanning container images for known vulnerabilities (the SCA idea from 2.10 / 5B.3, applied to images). Scanned ideally before images are deployed, and continuously (because new vulnerabilities are disclosed in components that were “clean” yesterday).

Untrusted image sources. Images are often pulled from registries — image repositories. Pulling images from untrustworthy sources, or pulling a tampered image, means running code you cannot trust (the supply-chain integrity problem from 2.10). The defense: use trusted, verified image sources; verify image integrity.

Secrets baked into images. A common, serious mistake: hard-coding secrets — credentials, keys, tokens — inside a container image. Anyone who obtains the image obtains the secrets (the leaked-secrets problem from 2.10 / 4.2, now baked into an artifact that gets distributed widely). Secrets must never be built into images; they are supplied to containers at runtime through proper secrets management.

Bloated images. An image that includes far more than the application needs — extra tools, extra packages — has a larger attack surface (the attack-surface-reduction principle from 0.4 / 4.4). Minimal images — containing only what the application genuinely needs — are more secure.

Image hardening. Beyond the above: images built following secure practices — minimal, current, from trusted bases, no secrets, scanned.

The principle: the image is the foundation of container security. A scanned, minimal, trusted, secret-free, current image is the starting point for a secure container; an insecure image poisons everything built from it.

Part 4: The Concept — Runtime and Orchestration Security

Beyond the image, security applies to running containers and to the orchestration platform that runs them at scale.

Running container security:

• Least privilege for containers. Containers should run with the minimum privileges needed — not as a privileged/root-equivalent container unless genuinely unavoidable (the least-privilege principle, and the “don’t run as root” lesson from 0.2 / 3.4, applied to containers). An over-privileged container is a far more dangerous thing if compromised, and makes container escape easier.
• Resource limits. Containers should have limits on the resources they can consume — preventing one container from starving others (an availability concern — CIA, 1.1).
• Runtime monitoring. Watching running containers for suspicious or unexpected behavior — the detection principle (4.6), applied to the container layer.

Orchestration (Kubernetes) security. Orchestration platforms like Kubernetes manage many containers across many hosts — and the orchestration platform itself is a major security surface:

• The orchestration platform is high-value and complex. It controls the whole containerized environment — compromising it can mean compromising everything it runs. And it is complex (the complexity-breeds-misconfiguration lesson, 2.9 / 5C.2), so it is easy to misconfigure.
• Orchestration access control. Kubernetes and similar platforms have their own access-control systems governing who and what can do what within the platform. These must be configured with least privilege — exactly the identity/access discipline from 5C.1 / 5C.2, applied to the orchestration layer.
• Orchestration misconfiguration. Like everything in the cloud, the orchestration platform can be misconfigured — insecure settings, over-broad access, exposed components, missing security controls. Securing it is, in large part, configuration discipline (the 5C.2 lesson).
• Network controls within orchestration. Orchestration platforms can control how containers communicate — and network controls here provide segmentation (the 4.3 principle) within the containerized environment, limiting how far a compromised container can reach.
• Secrets management. Orchestration platforms provide mechanisms for supplying secrets to containers at runtime (the alternative to baking secrets into images, Part 3) — these must be used, and used correctly.

The host layer. Underneath it all, containers and orchestration run on hosts — and those hosts must be hardened too (Phase 4.4). The stack is only as secure as its foundation.

Part 5: The Concept — Defense in Depth Across the Stack

The unifying way to think about container and Kubernetes security: it is defense in depth (4.3) applied across the layers of the container stack.

   THE CONTAINER STACK — secure EVERY layer
   ┌─────────────────────────────────────────────┐
   │ ORCHESTRATION  — platform config, access     │
   │                  control, network controls   │
   │  ┌──────────────────────────────────────┐    │
   │  │ RUNTIME      — least-privilege         │    │
   │  │  containers  containers, resource      │    │
   │  │              limits, monitoring        │    │
   │  │  ┌────────────────────────────────┐    │    │
   │  │  │ IMAGE  — scanned, minimal,      │    │    │
   │  │  │          trusted, no secrets    │    │    │
   │  │  └────────────────────────────────┘    │    │
   │  └──────────────────────────────────────┘    │
   │ HOST           — hardened underlying hosts    │
   └─────────────────────────────────────────────┘
   A weakness at ANY layer is a weakness in the whole.

No single layer’s security is sufficient. A perfectly scanned image running as an over-privileged container is not secure. Least-privilege containers on a misconfigured orchestration platform are not secure. Everything well-configured on un-hardened hosts is not secure. Container security means securing every layer — image, runtime, orchestration, host — and the principles you need are all ones you already have:

• Least privilege (0.2, 3.4, 4.3, 5C.1) — for containers, and for orchestration access.
• Attack surface reduction (0.4, 4.4) — minimal images.
• Vulnerability / supply-chain management (2.10) — image scanning.
• Secure configuration / hardening (2.9, 4.4, 5C.2) — orchestration and host configuration.
• Segmentation (4.3) — network controls within orchestration.
• Monitoring and detection (4.6) — runtime monitoring.
• Secrets management (4.2) — runtime secrets, never baked into images.

Container security is not a new set of principles — it is the principles you already know, applied to a specific, layered, modern technology stack.

Part 6: The Concept — How This Fits, and the Bridge to DevSecOps

Container and Kubernetes security sits within the broader picture of Track C and connects forward.

• It is part of “security in the cloud.” Containers and orchestration are how much cloud software runs — so securing them is a core part of the customer-side responsibility from 5C.1.
• It is subject to the same misconfiguration risk (5C.2). Orchestration platforms especially are complex and easily misconfigured — the 5C.2 lesson applies directly.
• It connects to your DevOps module. Containers and orchestration are core DevOps technology — you already understand them; this page added the security layer. The “you already know the technology, now add security” advantage is strongest here of anywhere in Track C.
• It is best secured by building security in — the bridge to DevSecOps. Notice the recurring theme: image scanning works best done automatically, before deployment; secure configuration works best defined and checked rather than manually applied. The most effective container security is built into how containers and infrastructure are defined and delivered — which is exactly DevSecOps (5C.4, 5C.5). Image scanning belongs in the pipeline (5C.5); orchestration configuration belongs in Infrastructure as Code that is checked before deployment (5C.4).

So this page completes the “securing the cloud” half of Track C (5C.1 fundamentals, 5C.2 misconfiguration, 5C.3 containers/orchestration) and points firmly at the second half: building that security in, automatically, through DevSecOps.

🔑 The deep lesson: modern software runs in containers orchestrated by platforms like Kubernetes, and that stack has security at every layer — image (scanned, minimal, trusted, secret-free), runtime (least-privilege containers, limits, monitoring), orchestration (configuration, access control, network segmentation), and host (hardened). It is defense in depth across the stack, using principles you already hold — least privilege, attack-surface reduction, supply-chain management, hardening, segmentation, monitoring, secrets management. And because you already know the underlying technology from your DevOps module, this is the most direct “add security to what you know” page in the track — best realized by building the security in through DevSecOps.

📓 Key Terms

🧪 Hands-On Lab

Use containers and (where possible) a local or learning Kubernetes environment. This connects directly to your On-Prem/DevOps module — use that knowledge.

Task 1 — Review the technology. Revisit the container and orchestration material in your On-Prem/DevOps module. Confirm you are solid on what containers, images, and orchestration are — this page is the security layer over that.

Task 2 — Scan a container image. Take a container image (build one, or use a public one). Use an image-scanning tool (free/open-source options exist) to scan it for known vulnerabilities. Read the results — this is 2.10’s supply-chain scanning, applied to images.

Task 3 — Build a minimal, secure image. Build a container image deliberately: minimal (only what the app needs), from a trusted current base, with no secrets baked in. Compare its attack surface to a bloated image. Practice image hardening.

Task 4 — Run a least-privilege container. Run a container configured with minimum privileges (not privileged/root-equivalent) and with resource limits. Understand how an over-privileged container would be more dangerous if compromised.

Task 5 — Explore orchestration security. In a learning Kubernetes environment, explore its access-control system. Configure least-privilege access for something. See how the identity/access discipline from 5C.1/5C.2 applies to the orchestration layer.

Task 6 — Examine orchestration configuration. Look at the security-relevant configuration of an orchestration setup. Identify settings that matter for security. Connect this to the 5C.2 misconfiguration lesson — the orchestration platform is complex and easily misconfigured.

Task 7 — Map the defense-in-depth stack. In Notion, draw the container stack (image → runtime → orchestration → host) and, for each layer, write the security measures and the curriculum principle each comes from. See container security as principles you already know, layered.

Task 8 — Write a container security note. In Notion, create a “Container & Kubernetes Security” page — the layers, image security, runtime and orchestration security, and defense in depth across the stack.

⚠️ Common Mistakes

• Assuming “we use containers” means secure. Containers have security responsibilities at every layer — image, runtime, orchestration, host. Containerizing is not securing.
• Treating container isolation as machine-strength. Container isolation is real but weaker than VM isolation; container escape is a genuine concern. Do not over-trust it.
• Running insecure or untrusted images. A container inherits its image’s insecurity. Use scanned, minimal, current, trusted, secret-free images.
• Baking secrets into images. Secrets in an image are distributed with the image. Supply secrets at runtime through proper secrets management — never bake them in.
• Running over-privileged containers. A privileged container is far more dangerous if compromised. Least privilege for containers.
• Ignoring the orchestration platform. The orchestration platform is high-value, complex, and easily misconfigured. Securing it — configuration and access control — is essential, not optional.
• Forgetting the host layer. Containers run on hosts; un-hardened hosts undermine everything above. Harden the hosts (4.4).
• Securing containers manually after deployment. Best done built-in — image scanning in the pipeline, orchestration config as checked code (the DevSecOps bridge, 5C.4/5C.5).

✅ Recap & What’s Next

• Modern software runs in containers orchestrated by platforms like Kubernetes — a stack with security at every layer.
• Secure each layer: image (scanned, minimal, trusted, no baked-in secrets), runtime (least-privilege containers, limits, monitoring), orchestration (configuration, access control, network segmentation), host (hardened) — defense in depth across the stack, using principles you already hold.
• It connects directly to your DevOps module (you know the technology — this added the security), and is best realized by building security in through DevSecOps.

Next (5C.4): Cloud infrastructure is defined through software — which means it can be defined as code. Page 5C.4 covers Infrastructure as Code security: finding and fixing infrastructure issues before deployment, preventing misconfiguration at the source.