Container, orchestration and serverless workload security

Why this matters

The third and last lesson on objective 2.1 covers the workload types that have replaced the virtual machine as the default unit of deployment. Their security properties differ from a virtual machine's in ways that break assumptions carried over from an older estate — and carrying those assumptions across is exactly what scenarios probe.

Three differences drive everything below. Containers share a kernel, so the isolation boundary is weaker than a hypervisor's. Orchestration introduces a control plane whose compromise exceeds any individual workload. And serverless removes the host entirely, taking with it every control that assumed one.

A scope note before starting, because it shapes what this lesson does and does not do: CAS-005 examines whether you can reason about the architecture of these platforms and their controls. It does not examine cluster administration. Nothing here requires you to be able to operate a production cluster, and a candidate who studies for that is studying for a different certification.

The lesson

Image provenance, base image hygiene and the registry you actually trust

A container image is a filesystem plus metadata, and everything that runs in the container comes from it. So the security of the workload is largely decided before it ever runs.

Provenance is the chain from source to running container. A trustworthy chain has four links: source code in version control, a build that is reproducible and produces a signed image, a registry that only the build can write to, and a runtime that verifies the signature before starting. Break any link and the rest provides less assurance than it appears to — the signature is only as good as the key, and the registry is only as good as its write controls.

Base image hygiene is where most vulnerability counts come from. An application image inherits every package in its base, and a general-purpose base carries hundreds the application never uses. Three practices reduce that sharply: use minimal or distroless bases so the image contains the runtime and the application and little else; pin bases by digest rather than by tag, because a tag is mutable and today's build may not match yesterday's; and rebuild regularly, because an image is a point-in-time snapshot that accumulates vulnerabilities while sitting in a registry unchanged.

The registry is a trust anchor and is often treated as a file share. It needs authentication for pulls as well as pushes, write access restricted to the build identity, immutable tags for released versions, retention that removes images nobody should still be deploying, and its own audit log. An organisation that scans images thoroughly and lets anyone push to the registry has spent its effort on the wrong link.

Two further points recur. Images should not contain secrets — layers are readable, and deleting a file in a later layer does not remove it from the earlier one. And a software bill of materials generated at build time is what lets you answer "which of our images contain this library" within minutes of a disclosure, rather than by rebuilding and rescanning everything.

Orchestration security: the API server, RBAC, namespaces and admission control

The orchestrator's control plane schedules workloads, holds their configuration, and can usually create infrastructure. Its API is therefore the most consequential interface in a containerised estate.

The API endpoint. It should not be reachable from the internet, and where it must be, it should be restricted to known sources and fronted by strong authentication. A scenario describing an exposed orchestrator API is describing a complete compromise path, because everything else in this section assumes the API is reachable only by those entitled to it.

Role-based access control. Two mistakes dominate. Granting broad administrative roles because narrowing them is fiddly — which removes the distinction between operating one application and operating the platform. And overlooking that workload identities are principals too: a pod with a token that can read every secret in the cluster gives an application compromise the reach of a platform compromise. Default service account tokens mounted into every workload are the specific form this usually takes.

Namespaces partition the cluster logically. They are a useful unit for policy, quota and access scoping, and they are not a strong security boundary — workloads in different namespaces share the same nodes and the same kernel. Where real separation is required, separate clusters or dedicated nodes are the answer, and a scenario relying on namespaces to separate production from development is describing a design defect.

Admission control is the orchestrator's policy-as-code, evaluating every object as it is submitted: reject containers requesting privileged mode, require images from approved registries, require resource limits, forbid host network or host path mounts, require non-root users. This is where the standards from domain 1 become enforcement inside the cluster, and it is the single highest value control on this list.

Supporting controls worth naming: network policy, since container networks are flat by default and every workload can reach every other until a policy says otherwise; and secrets management, because the orchestrator's native secret storage is frequently only base64-encoded at rest unless encryption is explicitly enabled.

Serverless: ephemeral compute, over-broad execution roles, and event-source trust

Serverless functions remove the host, which removes both a set of problems and a set of controls.

What goes away. No operating system to patch, no long-lived host to persist on, no agent to install — and therefore no host-based monitoring, no endpoint detection, and no file integrity monitoring. Organisations that relied on host controls for detection lose them silently, which is the gap a scenario describing a serverless estate with no visibility is pointing at.

What becomes central: the execution role. Every function runs with an identity that grants it permissions, and this is the dominant risk. Functions are numerous, are often created quickly, and their roles are frequently copied from a working example. A function that only needs to write one queue but holds broad data-store permissions turns any code-level flaw into a data breach. The control is per-function least privilege, generated from the function's actual calls rather than from a template.

Event-source trust. A function is triggered by an event — an HTTP request, a queue message, a file upload, a scheduled timer, a database change. The examinable point is that the event payload is untrusted input, and it is routinely treated as trusted because it arrived from an internal service. If any process can write to the queue that triggers a function, the function's input is attacker-controlled.

Dependencies matter more, not less. A function is mostly its dependency tree, and a compromised package runs with the function's role. Serverless does not reduce supply chain exposure; it concentrates it.

Two operational properties to carry: functions are short-lived, so an attacker seeking persistence attacks the deployment pipeline or the role rather than the runtime — which is why the previous lesson matters here; and concurrency is a cost and availability control, since an unbounded function triggered by an attacker-controllable event can both exhaust downstream systems and generate a substantial bill.

Why runtime isolation differs between containers, microVMs and functions

Isolation strength is the property that decides what may share hardware with what, and the three options differ materially.

• Containers share the host kernel. Isolation comes from kernel features — namespaces, control groups and mandatory access control. Strong enough for workloads within one trust level; a kernel vulnerability is a potential escape. Lowest overhead, fastest start.
• Virtual machines have separate kernels behind a hypervisor. Much stronger isolation, established attack surface, higher overhead and slower start. This is what multi-tenant infrastructure has historically relied on.
• MicroVMs run each workload in a minimal virtual machine with a reduced device model, aiming for hypervisor-grade isolation at close to container start-up cost. This is how several providers run containers and functions for mutually untrusted tenants.

The decision rule scenarios test: isolation strength must match the trust difference between co-located workloads. Two services from the same application at the same classification can share a kernel. A multi-tenant platform running customer-supplied code cannot, and needs at least microVM-grade separation. Production and development sharing nodes is a trust difference being ignored.

Practical mitigations within containers, where stronger isolation is not available: run as non-root, drop capabilities, make the root filesystem read-only, forbid privileged mode and host mounts, and apply seccomp and mandatory access control profiles. Each of these narrows what a container escape has to work with, and collectively they are the difference between a kernel bug being a serious incident and being a catastrophic one.

Deciding how deep to go: CAS-005 examines architecture, not operator development

A closing note on scope, because this objective is where candidates most often over-study.

CompTIA's bullet for 2.1 names container security, orchestration and serverless workloads alongside brokers, pipelines and shared responsibility — seven areas in one bullet, in a domain worth 27% of a 90-question exam. Arithmetically, this material is worth a handful of questions.

What those questions ask, based on the level the rest of the exam sits at: which isolation model suits a described trust difference; what the risk of a broadly permissioned workload identity is; where the control plane sits in an attack path; what admission control is for; what changes when a workload becomes serverless. All architecture questions.

What they do not ask: cluster installation, resource specifications, networking plugin internals, or operator development. Those belong to platform certifications and are a genuinely large body of knowledge that will not return marks here.

The practical study advice: be able to draw the estate — registry, pipeline, control plane, nodes, workloads, identities — and say for each component what compromising it would give an attacker and what control limits that. That drawing answers every question this objective is likely to ask, and it is the same skill lesson ten called an architecture review.