COMP 6660 · Lesson 5.6 Container and Virtualization Security

Module 2 · Unit 5 · Lesson 5.6

COMP 6660 · Enterprise Cybersecurity Container and Virtualization Security

Most cloud workloads are delivered through containers and virtual machines. This lesson examines the specific security considerations of these platforms — the container lifecycle, orchestration hardening, runtime protection, and hypervisor security.

Start reading Unit home
Reading time: ~110 minutes Activities: 3 Unit 5 · Lesson 6 of 8

00 Introduction

Lesson 5.5 examined cloud security — the shared responsibility model, cloud identity, misconfiguration, and the cloud-native controls through which enterprises secure cloud environments. This lesson examines the specific platforms on which most cloud workloads are delivered: containers and virtual machines.

Containers and virtual machines are the practical form in which modern workloads exist. Applications are packaged into container images and deployed to orchestration platforms; virtual machines host the workloads and the platforms that containers rely on. Both are abstractions that simplify deployment, improve portability, and increase density — and both introduce specific security considerations distinct from those of traditional operating systems, applications, and databases.

The security considerations are distinct because the platforms are distinct. Containers share the host operating system kernel — meaning that a kernel compromise or a container escape affects every container on the host. Containers are ephemeral — created and destroyed continuously — which changes what "patching" and "hardening" mean. Container images are built from layers — including base images and dependencies the enterprise did not produce — which extends the supply chain into the deployment artifact itself. Orchestration platforms have their own control plane — compromise of which means compromise of every workload it manages. And virtual machines rely on hypervisors — the highest-privilege component of a virtualised environment — whose compromise is exceptionally consequential.

This lesson examines container and virtualisation security in detail. It establishes why the topic matters. It examines the security model of containers and virtual machines — how they differ and where each fits. It examines the container attack surface. It examines image security and provenance — the integrity of the artifacts enterprises deploy. It examines orchestration hardening — securing the platform that manages containers. It examines runtime container protection. It examines virtualisation security — hypervisors, VM isolation, and virtualisation management. It examines cloud-native security controls. It examines monitoring and incident response for containerised environments. And it closes with the pitfalls that recur across container and virtualisation programmes.

The material here builds directly on Lesson 5.5 (cloud security) and Lesson 5.3 (application security) — containers and virtual machines are platforms for applications, and their security depends on the security of the images and code they run. It prepares for Lesson 5.7 (mobile and IoT security), which extends the discussion to the device estate, and for Lesson 5.8 (critical infrastructure security), which examines the specific considerations of operational technology.

How to read this lesson

Sections 1–3 establish the framing, the models, and the attack surface. Sections 4–6 examine the container controls — image security, orchestration hardening, and runtime protection. Section 7 examines virtualisation security. Section 8 examines cloud-native controls. Section 9 addresses monitoring and incident response. Section 10 addresses the pitfalls. If you are short on time, read Sections 4, 5, and 7 carefully — image security, orchestration hardening, and virtualisation security are the most consequential material for enterprise practice and for the assessment.

01 Learning objectives

By the end of this lesson you should be able to:

Lesson objectives

  • Explain why container and virtualisation security matters and how it relates to cloud, application, and platform security.
  • Distinguish container and virtual-machine security models, and identify where each fits.
  • Describe the container attack surface — image, registry, orchestration, runtime, and host.
  • Apply container image security — image provenance, image scanning, and image signing.
  • Explain orchestration hardening — Kubernetes control plane, RBAC, network policies, and pod security.
  • Describe runtime container protection — behavioural detection, runtime policy, and containment.
  • Evaluate virtualisation security — hypervisor security, VM isolation, and virtualisation management.
  • Explain cloud-native security controls for container and virtualisation environments.
  • Describe container monitoring and incident response practices.
  • Identify common enterprise pitfalls in container and virtualisation security programmes.

These objectives contribute to Unit 5 outcome U5.2 (cloud and platform security), and to Module 2 outcomes M2.9 and M2.10. See the Unit 5 learning outcomes page for the full mapping.

02 Why container and virtualisation security matters

Containers and virtual machines are the practical form in which modern workloads exist. Understanding why their security matters clarifies the priorities that inform the rest of this lesson.

They are the platform for modern workloads

  • Container images package applications, dependencies, and configuration into portable artifacts deployed to orchestration platforms.
  • Virtual machines host workloads, orchestration platforms, and the infrastructure services on which cloud environments depend.
  • Most modern enterprise workloads are deployed on one of these two platforms — their security is the security of the enterprise's actual workloads.

They introduce distinct security considerations

  • Containers share the host operating system kernel — a kernel compromise or a container escape affects every container on the host.
  • Containers are ephemeral — patching and hardening work differently from traditional systems.
  • Container images are assembled from layers — extending the supply chain into the deployment artifact.
  • Orchestration platforms have their own control plane — whose compromise means compromise of every workload it manages.
  • Virtualisation relies on hypervisors — the highest-privilege component of a virtualised environment.

They expand the attack surface

  • The container supply chain introduces new attack paths — base images, registries, build pipelines, and dependencies.
  • The orchestration control plane is a high-value target — compromise provides access to every workload.
  • Container density increases the consequence of any single vulnerability — one host can run hundreds of containers.

They change the operational model

  • Immutable infrastructure means systems are replaced, not modified — security posture is defined in images.
  • Infrastructure as code and policy as code define cloud and container environments programmatically — requiring new security practices.
  • Deployment velocity is high — security must be integrated into the deployment pipeline, not applied after.

They are frequently under-secured

  • Container and orchestration security is a comparatively new discipline — practices are less mature than for traditional systems.
  • Deployment is easy and security expertise is scarce — producing gaps between what is deployed and what is secured.
  • The result is a recurring pattern of container and virtualisation incidents that exploit configuration, image, and orchestration weaknesses.

The consequence of container and virtualisation security failures

Container and virtualisation security failures appear across documented incidents:

  • Vulnerable container images. Container images built from outdated base images, with unpatched dependencies, or with vulnerable components — exposing every deployment of the image.
  • Exposed orchestration control planes. Kubernetes API servers exposed to the internet, with weak authentication or permissive authorization — permitting adversaries to control the entire cluster.
  • Over-privileged containers. Containers running with privileged access, with host filesystem mounts, or with excessive capabilities — permitting container escape.
  • Compromised container registries. Registries with weak authentication, or with images that have been tampered with — producing malicious deployments.
  • Malicious container images. Images from public registries containing malicious code — including cryptominers, backdoors, and exfiltration tools.
  • Hypervisor compromise. Vulnerabilities in hypervisors or their management — permitting compromise of every VM on the host.

The pattern is consistent: container and virtualisation security failures exploit the specific characteristics of these platforms — images, the orchestration control plane, runtime privilege, and hypervisor trust. Container and virtualisation security requires controls that address these specific considerations, in addition to the OS, application, and cloud controls examined in previous lessons.

The most useful framing

The most useful framing for container and virtualisation security is that these are platforms — and like any platform, they have their own security model. The security of the workloads that run on them depends on the security of the platform itself — the integrity of the images deployed, the security of the orchestration control plane, the isolation between workloads, and the security of the underlying hypervisor. Platform security is a distinct discipline, and it is essential to securing the workloads that depend on it.

03 Containers, VMs, and the security model

Containers and virtual machines are both abstraction technologies — they package and isolate workloads. But they achieve this in fundamentally different ways, with different security implications.

How containers work

  • Shared kernel. Containers share the host operating system kernel — each container is a set of isolated processes running on the same kernel.
  • OS-level isolation. Isolation is provided by kernel features — namespaces (for isolation of processes, network, filesystem) and cgroups (for resource limits).
  • Lightweight and fast. Containers start in milliseconds and consume minimal resources — enabling high density on a single host.
  • Immutable and ephemeral. Containers are typically treated as immutable and ephemeral — replaced rather than modified, created and destroyed continuously.
  • Image-based. Containers are instantiated from images — portable artifacts that contain the application and its dependencies.

How virtual machines work

  • Separate kernel. Each virtual machine runs its own operating system kernel — providing strong isolation between VMs.
  • Hardware-level abstraction. Isolation is provided by the hypervisor — which virtualises the hardware and manages VM execution.
  • Heavier and slower. VMs start in seconds to minutes and consume substantial resources — providing lower density than containers.
  • Full operating system. VMs contain a full operating system — providing compatibility with traditional workloads and processes.
  • Longer-lived. VMs are frequently longer-lived than containers — running for days, weeks, or months.

Security model comparison

Containers and virtual machines — security model comparison
Dimension Containers Virtual machines
Isolation boundary Kernel namespaces and cgroups (shared kernel) Hypervisor (separate kernel per VM)
Isolation strength Weaker — kernel compromise affects all containers Stronger — hypervisor compromise required for cross-VM impact
Attack surface Shared kernel, container runtime, orchestration platform, images Hypervisor, virtualisation management, guest OS
Patching model Rebuild images; replace running containers Patch within the VM (traditional) or replace (immutable)
Persistence Ephemeral — short-lived, replaced frequently Longer-lived — with persistent state
Supply chain Base images, dependencies, registries, build pipelines OS images, patches, virtualisation platform
Density Very high — hundreds per host Moderate — tens per host
Privilege model Container root is host root if not constrained VM root is isolated to the VM
Replacement strategy Immutable — replace, do not modify Mix of patching and replacement depending on workload

Where each fits

Containers and VMs serve different purposes — and frequently coexist:

  • Containers are well-suited to stateless, cloud-native applications — microservices, web applications, APIs, and workloads that benefit from rapid scaling, portability, and high density.
  • Virtual machines are well-suited to stateful, long-lived workloads — databases, legacy applications, workloads requiring specific operating systems or hardware, and workloads where stronger isolation is required.
  • Container host VMs. In cloud environments, containers typically run inside virtual machines — the hypervisor isolates the VM, the container runtime isolates the containers within the VM.
  • Hybrid patterns. Modern environments combine both — containers for microservices, VMs for stateful workloads and legacy applications, orchestration across both.

The most useful framing

The most useful framing is that containers and VMs are complementary platforms, each with a distinct security model. Containers provide weaker isolation (shared kernel) but greater density and faster lifecycle; VMs provide stronger isolation (separate kernels) with greater resource cost and slower lifecycle. Both models require specific security controls that address their specific characteristics — and both are essential components of the modern enterprise estate.

04 The container attack surface

Containers present a specific attack surface — the components, the lifecycle stages, and the interactions through which containerised workloads can be attacked. Understanding the attack surface informs the controls the container platform requires.

Components of the container attack surface

Components of the container attack surface
Component Attack opportunities
Base images Container images are built from base images — frequently public images from Docker Hub or equivalent. Malicious base images, outdated base images, and vulnerable base images expose every container built from them.
Application dependencies Applications inside containers use dependencies — libraries, frameworks, packages — that may contain vulnerabilities. The dependency risk from Lesson 5.3 applies to containers, extended by the container image layers.
Container image layers Container images are built from layers — each layer adding files, configuration, and code. Layers that are not removed may contain secrets, temporary files, or build artefacts that were not intended to ship.
Container registry Registries store container images — and are frequently accessible, weakly authenticated, and unmonitored. Compromised registries can deliver malicious images to every deployment.
Build pipeline The systems that build container images — CI/CD pipelines, build servers. Compromise of the build pipeline permits insertion of malicious code into images (the supply-chain pattern from Lesson 3.7).
Container runtime The runtime — containerd, CRI-O, Docker — executes containers. Vulnerabilities in the runtime, or misconfiguration, permit container escape or privilege escalation.
Orchestration platform The orchestration platform — Kubernetes, ECS, AKS — manages containers. Compromise of the control plane provides control of every workload on the cluster.
Container configuration Runtime configuration of containers — privileges, capabilities, mounts, network — determines what the container can do. Misconfiguration produces over-privileged containers.
Container network The network connecting containers — service mesh, CNI plugins, ingress. Misconfiguration produces exposure; compromise provides lateral movement within the cluster.
Secrets in containers Secrets — credentials, API keys, tokens — stored in container images, in environment variables, or in configuration. Exposed secrets permit account and service compromise.
Host operating system The host OS on which containers run — its kernel, its configuration, its vulnerabilities. A host compromise affects every container.
Persistent volumes Storage volumes mounted into containers — for stateful workloads. Misconfigured volumes can expose host filesystem, or permit cross-container access.

The container lifecycle and security

Container security spans the entire lifecycle — from image build through runtime and retirement:

  • Image build

    The container image is built — from base images, application code, and dependencies. Security at this stage means using trusted base images, minimising dependencies, removing secrets, and applying secure build practices.

  • Image scanning

    The built image is scanned for vulnerabilities and misconfigurations. Security at this stage means automated scanning — detecting vulnerable components, exposed secrets, and configuration issues before the image reaches production.

  • Image signing and storage

    The image is signed and stored in a registry. Security at this stage means signing images, storing them in trusted registries, and controlling access to those registries.

  • Image pull and deployment

    The image is pulled from the registry and deployed to the orchestration platform. Security at this stage means verifying image signatures, restricting which images can be deployed, and controlling what privileges the deployment grants.

  • Runtime

    The container runs and serves its workload. Security at this stage means runtime protection — detecting and blocking malicious behaviour, restricting what the container can do, and monitoring activity.

  • Scale and replacement

    Containers are created and destroyed continuously — new instances from new images, old instances retired. Security at this stage means maintaining the security of the images over time, removing deprecated images, and ensuring replacements are secure.

  • Retirement

    The container and its image are retired. Security at this stage means removing images from registries, removing associated secrets, and cleaning up resources.

    • Reducing the container attack surface

    The foundational principle of container security is to reduce the attack surface to what the workload requires:

    • Minimise base images. Use minimal base images — distroless, Alpine, or equivalent — reducing the components in the container.
    • Minimise layers. Reduce the number of image layers — fewer layers mean fewer opportunities for secrets, temporary files, or build artefacts to ship.
    • Minimise dependencies. Include only the dependencies the application requires — reducing the vulnerability surface.
    • Minimise privileges. Run containers with the minimum privilege required — non-root users, dropped capabilities, no privileged mode.
    • Minimise exposure. Limit container network exposure — only the ports and endpoints the workload requires.
    • Minimise secrets. Remove secrets from images, from build contexts, and from configuration — and use dedicated secret management.

    The most useful question

    A useful question for container security assessments is: what does this container actually need to do — and is it doing anything else? The gap between what the workload requires — the files, the dependencies, the privileges, the network exposure — and what the container currently has is the excess attack surface the enterprise is carrying. Reducing that gap is the first priority in container security.

    05 Image security and provenance

    Container images are the deployment artifacts — the units of software that enterprises build, store, and deploy. Their security determines the security of every deployment that uses them. Image security and provenance is the discipline of ensuring that images are trusted — from trusted sources, with known contents, and without tampering.

    Image security dimensions

    Provenance

    • Where did the image come from — which base image, which registry, which build pipeline, which maintainer?
    • Is the source trusted — official images, verified publishers, or the enterprise's own build pipeline?
    • Is the image's provenance documented and verifiable — through signatures, through attestations, through SBOMs?

    Contents

    • What is in the image — which components, which dependencies, which files?
    • Are there vulnerabilities in the components — from outdated packages, from known vulnerable libraries?
    • Are there secrets in the image — credentials, keys, tokens that were inadvertently included during build?
    • Is there unnecessary content — build tools, debug utilities, temporary files that could be removed?

    Configuration

    • What privileges does the image require — does it need to run as root, need privileged mode, need elevated capabilities?
    • What does the image expose — which ports, which endpoints?
    • What is the runtime configuration — restart policy, resource limits, security context?

    Integrity

    • Has the image been tampered with — since build, since signing, since storage?
    • Is the image signed by a trusted party — and is the signature verified before deployment?
    • Is the image stored in a trusted registry — with access controls and monitoring?

    Container image scanning

    Image scanning is the practice of analysing container images for vulnerabilities, misconfigurations, and secrets. It is the primary control for identifying image-level security issues before deployment.

    Container image scanning categories
    Category What is scanned
    Vulnerability scanning Components in the image — OS packages, language-specific dependencies, frameworks — for known vulnerabilities.
    Secret scanning Image contents for secrets — credentials, API keys, tokens, certificates — that were included during build.
    Configuration scanning Image configuration — Dockerfile instructions, base image choice, user, exposed ports — for security issues.
    Malware scanning Image contents for malware — trojans, backdoors, cryptominers, and other malicious content.
    SBOM generation Generation of a software bill of materials — a machine-readable inventory of the components in the image.
    Licence scanning Components for licence compliance — identifying licence obligations and conflicts.

    Image signing and verification

    Image signing provides cryptographic assurance of image integrity and provenance — verifying that images are what they claim to be, from whom they claim to be from, and have not been tampered with:

    • Signing images. Images are signed by the party that built them — using cryptographic keys managed securely.
    • Signature verification. The signature is verified before deployment — confirming that the image is from a trusted source and has not been modified.
    • Signing tools. Tools like Sigstore (with cosign), Notary, and equivalent provide image signing and verification capabilities.
    • Admission control. Orchestration platforms can be configured to admit only signed images — blocking deployment of unsigned or untrusted images.
    • Attestations. Beyond signing, attestations can document the build process, the source code, and the dependencies — providing richer provenance information.

    Registry security

    Container registries store and distribute images. Their security is essential — because compromised registries deliver malicious images to every deployment:

    • Authentication. Registries should require authentication — not permit anonymous access to images.
    • Authorization. Registry access should be restricted — who can push, who can pull, and which images.
    • Image signing enforcement. Registries should support image signing — and organisations should enforce signature verification for deployments.
    • Image scanning integration. Registries should integrate with scanning — so that images are scanned automatically as they are pushed.
    • Monitoring. Registry activity should be monitored — detecting unusual pushes, unusual pulls, and other suspicious activity.
    • Retention. Image retention should be managed — removing old images, keeping only what is required.
    • Private registries. Where feasible, use private registries — with internal images — reducing reliance on public registries.

    Base image selection

    Base image selection is one of the most consequential decisions in container security:

    • Minimal base images. Distroless images, Alpine, or equivalent minimal images — fewer components, smaller attack surface.
    • Trusted sources. Official images from trusted publishers, or images built and maintained by the enterprise.
    • Regularly updated images. Base images that are maintained and updated — not outdated images that accumulate vulnerabilities.
    • Signed base images. Base images that are signed and whose signatures can be verified.
    • Version pinning. Pinned versions — not floating tags like "latest" — so that the base image is deterministic.
    • Internal base images. Where feasible, build and maintain internal base images — providing control over what is used.

    The most consequential image security failure

    The most consequential image security failure is the deployment of images from untrusted sources — public images without verification, or images from registries without proper controls. Because containers are instantiated from images, an untrusted image means an untrusted workload — regardless of what the container runtime or orchestration platform does. Image provenance, image scanning, and image signing are the controls that address this — determining what images are trusted and enforcing their integrity.

    06 Orchestration hardening

    Container orchestration platforms — Kubernetes, Amazon ECS, Azure Kubernetes Service, and equivalent — manage the lifecycle of containers across a cluster of hosts. Their security determines the security of every workload they manage. Orchestration hardening is the discipline of securing the orchestration platform itself.

    Why orchestration hardening matters

    Orchestration platforms are high-value targets. A compromise of the orchestration control plane provides control over every workload the platform manages — the ability to deploy new workloads, to access secrets, to modify existing workloads, and to extract data. The consequence of orchestration compromise is correspondingly high.

    Orchestration hardening dimensions

    Control plane security

    • API server security. The Kubernetes API server is the primary control plane interface — it should not be exposed to the internet, should require authentication, and should enforce authorization.
    • Authentication. Strong authentication for cluster access — integrating with enterprise identity providers where feasible.
    • Authorization. RBAC-based authorization with least privilege — every user, service account, and workload should have only the permissions it requires.
    • Audit logging. Comprehensive audit logging of all API activity — recording who did what and when.
    • Admission control. Admission controllers that enforce security policy — restricting what can be deployed and how.

    Workload security

    • Pod Security Standards. Enforcing Pod Security Standards (or equivalent) — restricting what containers can do.
    • Non-root containers. Containers should run as non-root users — reducing the consequence of container compromise.
    • Dropped capabilities. Containers should drop Linux capabilities they do not require — reducing the privileges available.
    • Read-only filesystems. Where feasible, containers should run with read-only root filesystems — reducing the opportunity for persistent modification.
    • Resource limits. Containers should have CPU and memory limits — preventing resource exhaustion and denial of service.
    • No privileged containers. Privileged mode should be prohibited — it effectively removes container isolation.
    • No host path mounts. Host filesystem mounts should be restricted — they provide access to the host.

    Network security

    • Network policies. Kubernetes network policies that control traffic between pods — implementing micro-segmentation within the cluster.
    • Ingress and egress controls. Restricting traffic into and out of the cluster — limiting exposure and preventing data exfiltration.
    • Service mesh. A service mesh provides mutual TLS, authorization policy, and observability for service-to-service communication.
    • Ingress security. Ingress controllers and load balancers should be hardened — providing controlled access to cluster services.

    Secrets management

    • Kubernetes Secrets. Secrets should be managed through Kubernetes Secrets — not stored in images or environment variables in plain text.
    • External secret management. Secrets should be sourced from external secret managers — HashiCorp Vault, cloud provider secret services — rather than stored in the cluster.
    • Encryption at rest. Kubernetes secrets should be encrypted at rest — configured through the cluster's encryption configuration.
    • Access control. Secret access should be restricted — through RBAC and through policy.
    • Rotation. Secrets should be rotated — through automated rotation where supported.

    Node and cluster security

    • Node hardening. Cluster nodes should be hardened — the OS hardening principles from Lesson 5.1 apply.
    • Node access. Access to cluster nodes should be restricted — through SSH key management, through bastion hosts, through privileged access management.
    • Cluster upgrades. Orchestration platform versions should be kept current — patching vulnerabilities in the platform itself.
    • Multi-tenancy. Where clusters host multiple tenants, isolation should be enforced — through namespaces, network policies, and RBAC.

    Configuration and policy

    • Policy as code. Orchestration security policy should be defined as code — versioned, reviewed, and enforced automatically.
    • Configuration management. Cluster configuration should be managed through infrastructure as code — not modified manually.
    • Compliance scanning. Cluster configuration should be continuously scanned — using tools like kube-bench, kubesec, or equivalent.
    • Admission policy. Admission policies should enforce the security requirements — refusing deployments that violate policy.

    Kubernetes-specific considerations

    Kubernetes is the dominant container orchestration platform, and its specific security considerations are widely documented. Key areas include:

    • API server exposure. The Kubernetes API server should not be exposed to the internet — access should be through controlled channels, with strong authentication and authorization.
    • etcd security. etcd stores the cluster's state — including secrets. It should be encrypted, access-restricted, and protected.
    • Kubelet security. The kubelet — the agent on each node — should be configured securely — with authentication and authorization enabled, with restricted access.
    • Service accounts. Kubernetes service accounts should be managed with least privilege — and should not be granted excessive permissions.
    • Pod Security Standards. Enforce Pod Security Standards — the modern replacement for Pod Security Policies — to restrict pod privileges.
    • Network policies. Apply network policies to control traffic between pods — implementing default-deny network segmentation.
    • Admission controllers. Use admission controllers to enforce policy — OPA Gatekeeper, Kyverno, or equivalent.
    • Supply chain. Verify image signatures, verify provenance, and restrict which images can be deployed.

    Orchestration security benchmarks

    Orchestration security is informed by published benchmarks and guidance:

    • CIS Kubernetes Benchmarks. Detailed hardening guidance for Kubernetes components — API server, kubelet, etcd, and cluster configuration.
    • NSA/CISA Kubernetes Hardening Guidance. Joint guidance from the US National Security Agency and Cybersecurity and Infrastructure Security Agency.
    • Cloud provider guidance. AWS, Azure, and Google Cloud publish hardening guidance for their managed Kubernetes services.
    • Kubernetes documentation. The Kubernetes project maintains security documentation — including its own security best-practices guidance.

    The most consequential orchestration failure

    The most consequential orchestration failure is an exposed control plane — a Kubernetes API server reachable from the internet, with weak authentication or permissive authorization. Because the control plane manages every workload in the cluster, its compromise means compromise of everything. Exposed Kubernetes API servers have been found in substantial numbers by internet-wide scanning — and have been exploited for cryptomining, for data theft, and for lateral movement. Ensuring that the control plane is not exposed, that authentication is strong, and that authorization is least-privileged is the first priority in orchestration security.

    07 Runtime container protection

    Even with strong image security and hardened orchestration, containers can be compromised at runtime — through application vulnerabilities, through exploitation of misconfiguration, through malicious behaviour by other containers. Runtime container protection is the discipline of detecting and blocking malicious activity within containers while they are running.

    Runtime protection capabilities

    Behavioural detection

    • Detecting anomalous behaviour within containers — process execution, file access, network connections — that differs from the container's normal behaviour.
    • Established baselines of container behaviour — what processes run, what files are accessed, what connections are made — with deviations flagged.
    • Detection of specific attack patterns — shell execution, privilege escalation, lateral movement, cryptomining.

    Runtime policy enforcement

    • Enforcing policy at runtime — what processes can run, what files can be accessed, what network connections can be made.
    • Blocking actions that violate policy — pre-execution blocking, pre-write blocking, and equivalent.
    • Enforcing security context — non-root users, read-only filesystems, dropped capabilities.

    File integrity monitoring

    • Monitoring container filesystems for unauthorised modification — detecting changes to system files, executables, and configuration.
    • Detecting tampering with the container itself — as distinct from legitimate application activity.
    • Detecting files written that should not exist — indicators of compromise.

    Network monitoring

    • Monitoring container network connections — detecting unusual connections, unusual destinations, and command-and-control activity.
    • Detecting lateral movement within the cluster — unusual pod-to-pod communication.
    • Detecting data exfiltration — unusual egress traffic.

    Containment and response

    • Isolating compromised containers — removing them from the network while preserving their state for investigation.
    • Terminating malicious processes — stopping active incidents in progress.
    • Automated response — automatically isolating or terminating containers that exhibit malicious behaviour.
    • Integration with the SOC — feeding detections into the enterprise's detection and response platforms.

    Runtime protection tools

    Several categories of tools provide runtime container protection:

    Runtime container protection tools
    Category Characteristics
    Cloud-native container security Provider services — Amazon EKS Security, Azure Defender for Containers, Google Cloud Container Security — providing cluster security assessment and runtime protection.
    Container security platforms Specialised tools — Aqua Security, Sysdig, Prisma Cloud, Falco — providing runtime protection, image scanning, compliance, and policy enforcement.
    Falco Open-source runtime security tool — using kernel-level instrumentation to detect anomalous container behaviour. Frequently used as a foundation for custom detection.
    eBPF-based tools Tools using eBPF (extended Berkeley Packet Filter) — providing kernel-level observability and enforcement with minimal performance overhead.
    Service mesh Service mesh platforms (Istio, Linkerd) — providing mutual TLS, authorization, and observability at the service-to-service level.
    Admission controllers OPA Gatekeeper, Kyverno, and equivalent — enforcing policy at deployment time, complementing runtime enforcement.

    Runtime protection in context

    Runtime protection is one layer in the container security stack — complementing image security, orchestration hardening, and cloud-native controls:

    • Detection at the container level. Runtime protection detects activity that other controls did not prevent — through behavioural analysis, through policy enforcement, through network monitoring.
    • Response capability. Runtime protection can respond — isolating compromised containers, terminating malicious processes, blocking malicious activity.
    • Forensic evidence. Runtime protection provides evidence for investigation — what happened, what was accessed, what was affected.
    • Continuous operation. Runtime protection operates continuously — not at specific lifecycle stages — providing ongoing visibility into container behaviour.

    The most useful framing

    The most useful framing for runtime container protection is that containers can be compromised even when images are trusted and orchestration is hardened — through application vulnerabilities, through exploitation of misconfiguration, or through malicious behaviour by other containers. Runtime protection provides the visibility and response capability for the runtime state — detecting and blocking the activity that the other controls did not prevent.

    08 Virtualisation security

    Virtualisation provides the hardware-level abstraction that underlies cloud environments, container hosts, and many enterprise workloads. Virtualisation security is the discipline of securing the hypervisor, the VMs it manages, and the virtualisation management infrastructure.

    Why virtualisation security matters

    Virtualisation introduces a distinct trust hierarchy. The hypervisor is the highest-privilege component of a virtualised environment — it manages the virtual hardware on which VMs run. Compromise of the hypervisor compromises every VM it manages; compromise of the virtualisation management platform provides control over the hypervisor and through it every VM. The consequence of virtualisation compromise is correspondingly severe.

    Virtualisation security dimensions

    Hypervisor security

    • Patching. Hypervisors require patching — vulnerabilities in hypervisors are rare but consequential when they exist.
    • Hardening. Hypervisors should be hardened — minimal services, restricted access, secure configuration.
    • Access control. Access to the hypervisor should be restricted — through strong authentication, through privileged access management.
    • Isolation. The hypervisor should enforce strong isolation between VMs — and the isolation mechanism itself should be trustworthy.

    Virtual machine security

    • Guest OS hardening. The guest OS in each VM requires the same hardening as any operating system (Lesson 5.1).
    • Guest OS patching. The guest OS requires patching — the enterprise manages the OS in IaaS; the provider manages it in PaaS.
    • VM image security. The images from which VMs are deployed should be trusted, hardened, and up to date.
    • VM configuration. VM configuration should be hardened — minimal virtual hardware, no unnecessary devices, no shared folders with the host.
    • VM isolation. VMs should be isolated from each other — and from the host — through the hypervisor's isolation mechanisms.

    Virtualisation management security

    • Management platform security. Virtualisation management platforms — vCenter, Hyper-V Manager, cloud management planes — should be strongly protected.
    • Authentication. Strong authentication for management access — including multi-factor and privileged access management.
    • Authorization. Least privilege for management access — no more privilege than required for each role.
    • Monitoring. Monitoring of management activity — detecting unusual access or configuration changes.
    • Segmentation. The management plane should be segmented from workload traffic — not accessible from workload networks.

    VM lifecycle security

    • VM provisioning. VMs should be provisioned from trusted images, with secure configuration, and with appropriate access controls.
    • VM patching and updates. VMs require ongoing patching — through traditional patch management or through immutable replacement.
    • VM snapshots. Snapshots should be managed — removed when no longer needed, protected when retained, and not treated as backups.
    • VM retirement. VMs should be securely retired — data removed, credentials revoked, snapshots deleted.
    • VM sprawl. Unmanaged VMs should be detected and remediated — unmanaged VMs are unpatched, misconfigured, and frequently forgotten.

    Hypervisor-specific considerations

    Each hypervisor has its own specific security considerations:

    • VMware vSphere / ESXi. Hardening guides from VMware; management through vCenter; attention to network configuration, to permissions, and to update management.
    • Microsoft Hyper-V. Hardening guidance from Microsoft; integration with Active Directory; attention to host configuration, to virtual switch configuration, and to Shielded VMs.
    • KVM / QEMU. Open-source hypervisor; integration with Linux security features (SELinux, AppArmor); attention to configuration and to guest isolation.
    • Xen. Open-source hypervisor; used by some cloud providers; attention to dom0 security and to guest isolation.
    • Cloud provider virtualisation. Managed by the cloud provider — the enterprise does not manage the hypervisor but relies on the provider's security.

    Virtualisation security risks

    The most consequential virtualisation security risks include:

    • Hypervisor escape. A vulnerability that permits breaking out of a VM to the hypervisor — giving the attacker control of every VM the hypervisor manages. Rare but exceptionally consequential.
    • Virtualisation management compromise. Compromise of the management platform — providing control over the hypervisor and through it every VM.
    • VM sprawl. Unmanaged VMs — created without governance, unpatched, misconfigured, and frequently forgotten.
    • Snapshot exposure. VM snapshots containing sensitive data — stored insecurely, or retained longer than needed.
    • Shared resources. Virtualisation shares physical resources — CPU, memory, network — between VMs. Resource sharing introduces side-channel and co-tenancy risks.
    • Public VM images. Public VM images used without verification — potentially containing malicious content or vulnerabilities.

    The most consequential virtualisation risk

    The most consequential virtualisation risk is the compromise of the virtualisation management platform. Because the management platform controls the hypervisor and through it every VM, its compromise means compromise of the entire virtualised environment. Virtualisation management should be protected with the strongest controls in the enterprise — segmented from workload networks, accessed only through strong authentication and privileged access management, monitored continuously, and treated as one of the enterprise's most consequential trust anchors.

    09 Cloud-native security controls

    Cloud providers offer extensive security services for container and virtualisation environments. Cloud-native security controls integrate with the provider's platform — providing capabilities that are frequently easier to deploy and better integrated than third-party alternatives.

    Cloud-native container security services

    Cloud-native container security services
    Provider Services
    AWS Amazon ECR (container registry with scanning), Amazon EKS (managed Kubernetes), AWS App Mesh (service mesh), AWS Security Hub (findings), GuardDuty for EKS (threat detection).
    Azure Azure Container Registry (with scanning), Azure Kubernetes Service, Microsoft Defender for Containers, Azure Policy for Kubernetes, Azure Sentinel integration.
    Google Cloud Artifact Registry (with scanning), Google Kubernetes Engine, Container Security (in Security Command Center), Binary Authorization (image signing enforcement), Cloud Service Mesh.

    Cloud-native virtualisation security services

    Cloud providers offer security services for the virtualised infrastructure that underlies their platforms:

    • VM image scanning. Cloud provider services that scan VM images for vulnerabilities and misconfiguration.
    • VM security monitoring. Cloud provider services that monitor VM activity — detecting anomalies, detecting threats.
    • Confidential computing. Cloud provider services that protect data in use — through secure enclaves, through encrypted memory.
    • VM management services. Cloud provider services for managing VM lifecycle — patching, configuration, monitoring.

    Integration with enterprise security

    Cloud-native security controls should integrate with the enterprise's broader security programme:

    • Integration with SIEM. Cloud-native security findings should flow into the enterprise's SIEM — for correlation with other sources.
    • Integration with SOC. Cloud-native security alerts should be part of the SOC's detection and response — not a separate silo.
    • Integration with identity. Cloud-native security should integrate with the enterprise's identity infrastructure — providing consistent identity and access control.
    • Integration with compliance. Cloud-native compliance reporting should feed into the enterprise's compliance processes.
    • Integration with policy. Cloud-native policy should align with the enterprise's policy — ensuring consistent requirements.

    The most useful framing

    The most useful framing for cloud-native security controls is that they provide the capabilities that are hardest to replicate in a cloud environment — deep integration with the cloud platform, real-time visibility into cloud-native resources, and consistent policy across cloud workloads. Cloud-native controls are not a complete solution — third-party tools frequently provide additional capabilities — but they are the foundation on which container and virtualisation security in cloud environments is built.

    10 Container monitoring and incident response

    Container and virtualisation environments generate substantial telemetry — logs, metrics, events — that must be collected, monitored, and used to detect and respond to incidents. Monitoring and incident response in these environments require specific considerations.

    What to monitor

    • Container activity. Process execution, file access, network connections, and other activity within containers.
    • Orchestration platform activity. API activity — what was deployed, what was modified, what was deleted; authentication activity; policy violations.
    • Image activity. Image pulls, image pushes, image scanning results, and signature verification.
    • Cluster configuration. Configuration changes — detecting drift and unauthorised modifications.
    • Network activity. Traffic between containers, between containers and external services, and between the cluster and the enterprise.
    • Resource utilisation. CPU, memory, and network utilisation — detecting resource abuse such as cryptomining.
    • Secret access. Access to Kubernetes secrets and external secret managers — detecting unusual access patterns.

    Monitoring tools and integration

    Container monitoring uses a combination of tools:

    • Container security platforms. Tools that provide integrated monitoring, detection, and response for container environments — Aqua, Sysdig, Prisma Cloud, and equivalent.
    • Cloud-native monitoring. Cloud provider services — CloudWatch Container Insights, Azure Monitor for Containers, Google Cloud Monitoring — providing visibility into container activity.
    • Kubernetes audit logging. Native Kubernetes audit logging — capturing API activity at the orchestration level.
    • Service mesh observability. Service mesh platforms provide telemetry for service-to-service communication.
    • SIEM integration. Container logs fed into the enterprise's SIEM — for correlation with other sources.
    • eBPF-based monitoring. Tools using eBPF — providing kernel-level visibility with minimal overhead.

    Incident response in containerised environments

    Incident response in container environments has specific considerations:

    Ephemerality

    • Containers are ephemeral — a compromised container may be terminated before investigation can occur.
    • Evidence preservation requires capturing container state before replacement — through isolation, through snapshotting, through forensics collection.
    • Response procedures should be designed for ephemeral workloads — not for traditional long-lived systems.

    Scale and distribution

    • Container environments operate at scale — hundreds or thousands of containers.
    • Compromise may affect many containers simultaneously — through shared images, through shared secrets, through shared configuration.
    • Response must scale — through automation, through policy enforcement, through coordinated action.

    Isolation and containment

    • Isolating a compromised container — removing it from the network while preserving state.
    • Containing lateral movement — restricting the compromised container's access to other workloads and to cluster services.
    • Coordinating containment with the orchestration platform — through taints, through network policies, through admission controls.

    Recovery

    • Recovery typically involves replacing compromised containers — not cleaning them.
    • Deployment of new containers from trusted, scanned, verified images.
    • Remediation of the underlying cause — the image, the configuration, the orchestration policy.

    Investigation

    • Investigation requires collecting evidence from ephemeral containers — logs, process state, network connections, filesystem state.
    • Investigation spans the container, the orchestration platform, the host, and the underlying cloud environment.
    • Integration with cloud provider investigation tools — for access to cloud-level telemetry.

    Post-incident improvement

    • Improvement actions — new image controls, new orchestration policy, new runtime detections.
    • Rebuilding images with remediation — for the images that contained the exploited vulnerability.
    • Updating orchestration policy — for the misconfiguration that permitted the compromise.

    The most useful principle

    The most useful principle for container incident response is to treat containers as ephemeral — and to design response accordingly. The response to a compromised container is typically to isolate it, collect evidence, and replace it from a clean image — not to clean it. The response to a compromised image is typically to rebuild it and redeploy — not to patch running containers. Response procedures should match the characteristics of the platform — ephemeral, image-based, orchestrated.

    11 Common pitfalls

    Enterprise container and virtualisation security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

    Pitfall 1 — Trusting public images without verification

    Deploying container images from public registries without verification — potentially including malicious content, vulnerable components, or unintended secrets.

    Mitigation: Verify image provenance. Use signed images. Scan images before deployment. Prefer trusted sources.

    Pitfall 2 — No image scanning

    Container images deployed without scanning — vulnerable components, exposed secrets, and configuration issues reaching production.

    Mitigation: Implement automated image scanning — integrated into the build pipeline and into the registry.

    Pitfall 3 — Exposed orchestration control plane

    Kubernetes API servers or equivalent orchestration control planes exposed to the internet — with weak authentication or permissive authorization.

    Mitigation: Do not expose the control plane. Enforce strong authentication. Apply least privilege for authorization.

    Pitfall 4 — Over-privileged containers

    Containers running as root, in privileged mode, with excessive capabilities, or with host filesystem mounts — removing or weakening container isolation.

    Mitigation: Run containers as non-root users. Drop unnecessary capabilities. Prohibit privileged mode. Restrict host path mounts.

    Pitfall 5 — Secrets in images or configuration

    Secrets — credentials, API keys, tokens — stored in container images, in environment variables, or in configuration files — exposed to anyone who accesses the image or the running container.

    Mitigation: Remove secrets from images. Use dedicated secret management. Rotate secrets regularly.

    Pitfall 6 — Missing network policies

    Kubernetes clusters without network policies — permitting unrestricted pod-to-pod communication and lateral movement within the cluster.

    Mitigation: Apply network policies — implement default-deny network segmentation. Consider service mesh for service-to-service controls.

    Pitfall 7 — No runtime protection

    Container environments without runtime protection — malicious activity within containers not detected or blocked.

    Mitigation: Deploy runtime protection — behavioural detection, policy enforcement, network monitoring. Integrate with SOC.

    Pitfall 8 — Unpatched container images

    Container images with outdated base images and unpatched dependencies — accumulating vulnerabilities over time.

    Mitigation: Rebuild images regularly — with updated base images and dependencies. Retire outdated images.

    Pitfall 9 — Hypervisor and management plane not secured

    Hypervisors and virtualisation management platforms not patched, not hardened, and not monitored — despite their foundational importance.

    Mitigation: Patch and harden hypervisors. Protect management planes. Monitor management activity. Apply least privilege.

    Pitfall 10 — Container security treated separately

    Container security managed by a separate team, with separate tools, separate processes — disconnected from the enterprise's broader security programme.

    Mitigation: Integrate container security with the enterprise security programme. Align processes, tools, and governance. Include containers in SOC operations, incident response, and governance.

    Container and virtualisation security pitfalls and mitigations
    Pitfall Primary mitigation
    Trusting public images without verificationVerify provenance; use signed images; scan before deployment.
    No image scanningImplement automated image scanning in build pipeline and registry.
    Exposed orchestration control planeDo not expose; enforce strong authentication; apply least privilege.
    Over-privileged containersNon-root users; drop capabilities; prohibit privileged mode; restrict mounts.
    Secrets in images or configurationRemove secrets from images; use dedicated secret management.
    Missing network policiesApply network policies; default-deny segmentation; service mesh.
    No runtime protectionDeploy runtime protection; integrate with SOC.
    Unpatched container imagesRebuild images regularly; retire outdated images.
    Hypervisor and management plane not securedPatch and harden; protect management planes; monitor.
    Container security treated separatelyIntegrate with the enterprise security programme.

    The most consequential pitfall

    The most consequential pitfall in container and virtualisation security is treating these platforms as inherently secure because they are "new" or "modern". Containers and virtualisation do not eliminate security requirements — they change them. The attack surface is different, the trust model is different, and the operational practices are different. Effective container and virtualisation security requires understanding these differences and applying the appropriate controls — not assuming that the platform handles security.

    12 Key concepts

    The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

    Container
    A lightweight, isolated unit of software — packaged as an image and running as a set of processes on a shared host operating system kernel.
    Container image
    A portable artifact containing the application, its dependencies, and its configuration — from which containers are instantiated.
    Container runtime
    The software that executes containers — containerd, CRI-O, Docker — providing isolation through kernel features.
    Container registry
    A storage and distribution service for container images — Docker Hub, Amazon ECR, Azure Container Registry, Google Artifact Registry.
    Orchestration platform
    The platform that manages container lifecycle across a cluster — Kubernetes, Amazon ECS, Azure Kubernetes Service.
    Kubernetes
    The dominant open-source container orchestration platform — providing deployment, scaling, and management of containerised workloads.
    Pod
    The smallest deployable unit in Kubernetes — one or more containers that share network and storage.
    Kubernetes API server
    The primary control plane interface in Kubernetes — the interface through which the cluster is managed. A high-value target.
    etcd
    The distributed key-value store that holds Kubernetes cluster state — including secrets. Requires encryption, access control, and protection.
    kubelet
    The agent running on each Kubernetes node — responsible for managing pods on that node. Requires authentication and authorization to be enabled.
    Container escape
    A technique that breaks out of a container to the host operating system — permitting access to other containers and to the host.
    Image scanning
    The analysis of container images for vulnerabilities, secrets, misconfiguration, and malware — performed before deployment.
    Image signing
    The cryptographic signing of container images — providing integrity and provenance verification before deployment.
    Sigstore / cosign
    Tools for signing and verifying container images — providing cryptographic assurance of image integrity and provenance.
    SBOM (Software Bill of Materials)
    A machine-readable inventory of components in a software artifact — including container images. Examined in Lesson 3.7.
    Admission controller
    A Kubernetes component that intercepts requests to the API server — enforcing policy before resources are created.
    Pod Security Standards
    Kubernetes security standards — Privileged, Baseline, Restricted — defining what pods can and cannot do.
    Network policy
    Kubernetes resource that controls traffic between pods — implementing micro-segmentation within a cluster.
    RBAC (Role-Based Access Control)
    The Kubernetes authorization model — assigning permissions to roles, roles to users, groups, and service accounts.
    Service mesh
    A platform providing mutual TLS, authorization policy, and observability for service-to-service communication — Istio, Linkerd, and equivalents.
    eBPF (extended Berkeley Packet Filter)
    A technology for kernel-level observability and enforcement — used by container security tools for runtime monitoring and policy enforcement.
    Falco
    An open-source runtime security tool for containers — detecting anomalous behaviour through kernel-level instrumentation.
    Runtime protection
    Detection and blocking of malicious activity within containers while they are running — through behavioural analysis, policy enforcement, and monitoring.
    Virtual machine (VM)
    A software emulation of a physical computer — running its own operating system kernel on a hypervisor.
    Hypervisor
    The software that manages virtual machines — providing hardware virtualisation and VM isolation. The highest-privilege component of a virtualised environment.
    Hypervisor escape
    A vulnerability that permits breaking out of a VM to the hypervisor — permitting compromise of every VM on the host.
    Virtualisation management platform
    The platform through which virtualisation is managed — vCenter, Hyper-V Manager, cloud management planes. A high-value target.
    Confidential computing
    Cloud provider services that protect data in use — through secure enclaves, through encrypted memory.
    Binary Authorization
    Google Cloud service that enforces image signing — permitting only attested images to be deployed.
    Container security platform
    A specialised tool providing integrated container security — image scanning, runtime protection, compliance, and policy enforcement.

    13 Activities

    The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

    Activity 1 — Container security assessment

    For an enterprise context you know well, assess its container security posture:

    • what container platforms are used — Kubernetes, ECS, AKS, others?
    • where do images come from — public registries, private registries, internal builds?
    • is image scanning performed? Are images signed?
    • is the orchestration control plane exposed? Is authentication strong? Is RBAC least-privileged?
    • do containers run as non-root? Are capabilities dropped? Is privileged mode prohibited?
    • are network policies in place?
    • is runtime protection deployed?
    • are container logs integrated into the SOC?

    Write up your assessment (400–500 words). Identify the most significant gap and describe how it would be closed.

    Activity 2 — Container and virtualisation security programme design

    For an enterprise context of your choice, outline a container and virtualisation security programme (500–600 words) covering:

    • the scope — which container platforms, which virtualisation platforms, which workloads;
    • the image security approach — trusted base images, scanning, signing, registry controls;
    • the orchestration hardening approach — control plane security, RBAC, pod security, network policies, secrets;
    • the runtime protection approach — behavioural detection, policy enforcement, containment;
    • the virtualisation security approach — hypervisor hardening, VM security, management platform security;
    • the cloud-native controls approach — provider services, integration with enterprise security;
    • the monitoring approach — what is monitored, how it is integrated with SOC;
    • the metrics that would demonstrate the programme is working;
    • the principal challenges and how they would be addressed.

    Support your design with reference to the lesson material and to published guidance (CIS Kubernetes Benchmarks, NSA/CISA guidance, NIST, or equivalent).

    Activity 3 — Preparing for Forum 5 and Assignment 2

    Forum 5 includes discussion of container security and cloud security governance. Assignment 2 includes a secure cloud-migration architecture and a defence-in-depth strategy for a financial institution — both of which depend on the container and virtualisation security reasoning developed in this lesson.

    Review the Forum 5 prompts and the Assignment 2 brief, and note where the material from this lesson — particularly image security, orchestration hardening, runtime protection, and virtualisation security — will strengthen your analysis.

    14 Self-check

    Answer the questions below before moving to Lesson 5.7. If you cannot answer a question confidently, revisit the corresponding section.

    Question 1
    Which of the following best describes the difference between container and VM isolation?
    Reveal answer

    B. Containers share the host kernel and rely on kernel namespaces and cgroups; VMs run separate kernels and rely on a hypervisor for isolation. The shared kernel makes containers more vulnerable to escape but lighter and faster; the separate kernels make VMs more isolated but heavier and slower. A, C, and D misstate the distinction.

    Question 2
    Which of the following best describes the most consequential orchestration security failure?
    Reveal answer

    B. An exposed control plane is the most consequential orchestration security failure — its compromise means compromise of every workload the cluster manages. A, C, and D are not failures.

    Question 3
    Which of the following best describes image signing?
    Reveal answer

    B. Image signing provides cryptographic assurance of image integrity and provenance — verifying that images are from trusted sources and have not been tampered with. A, C, and D describe other image operations.

    Question 4
    Which of the following best describes why virtualisation management is a high-value target?
    Reveal answer

    B. Virtualisation management controls the hypervisor and through it every VM it manages — making it one of the enterprise's most consequential trust anchors. A, C, and D misstate the reason.

    Question 5
    Which of the following best describes the correct incident response to a compromised container?
    Reveal answer

    B. The correct response to a compromised container is to isolate it, collect evidence, and replace it from a clean image — treating containers as ephemeral. A, C, and D neglect evidence preservation and investigation.

    15 Summary

    This lesson has examined container and virtualisation security — the specific security considerations of the platforms on which most modern workloads are delivered. The essential points are:

    • Containers and virtualisation are the platforms for modern workloads. They introduce distinct security considerations — shared kernel for containers, hypervisor for VMs, image-based deployments, orchestration control planes — that require specific controls.
    • Containers and VMs have different security models. Containers provide weaker isolation (shared kernel) with greater density and speed; VMs provide stronger isolation (separate kernels) with greater resource cost. Both are essential components of the modern estate.
    • The container attack surface is broad. Base images, dependencies, image layers, registry, build pipeline, runtime, orchestration platform, configuration, network, secrets, host OS, and volumes — each with specific attack opportunities.
    • Image security and provenance determine the security of every deployment — through trusted base images, image scanning, image signing, and registry controls.
    • Orchestration hardening secures the platform that manages containers — control plane security, workload security, network security, secrets management, node and cluster security, and configuration management.
    • Runtime container protection detects and blocks malicious activity within containers — through behavioural detection, policy enforcement, file integrity monitoring, network monitoring, and containment.
    • Virtualisation security addresses the hypervisor, the VMs it manages, and the virtualisation management platform — with management plane compromise as the most consequential risk.
    • Cloud-native security controls provide integrated capabilities for container and virtualisation environments — complementing rather than replacing the enterprise's broader security programme.
    • Monitoring and incident response for container environments require specific approaches — treating containers as ephemeral, collecting evidence before replacement, and integrating with the enterprise SOC.
    • Common pitfalls recur. Trusting public images; no image scanning; exposed orchestration control plane; over-privileged containers; secrets in images; missing network policies; no runtime protection; unpatched container images; unsecured hypervisor and management plane; container security treated separately.

    These ideas prepare for Lesson 5.7, which examines mobile and IoT security — extending the discussion to the device estate, where constraints on devices and the diversity of the device population introduce additional security considerations.

    Before moving on

    Make sure you can distinguish container and VM security models, describe the container attack surface, explain image security and orchestration hardening, describe virtualisation security, and identify the specific incident response considerations for container environments. If you cannot yet do all five, revisit Sections 2, 3, 4, 5, 7, and 9.

    Next lesson

    Lesson 5.7 — Mobile and IoT Security examines the device estate — mobile devices, BYOD, and Internet of Things devices — and the specific security considerations that constrained devices and diverse populations introduce.

    👤