How container isolation actually works (and where it breaks), image security with Trivy and Cosign, runtime security with Falco, the 4Cs of cloud-native security, and the Kubernetes-specific risks that appear in every cluster audit.
Sign in to mark this article as read and track your progress.
Containers are not virtual machines. They share the host kernel and use three Linux mechanisms to provide isolation:
| Mechanism | Purpose | What It Isolates |
|---|---|---|
| Namespaces | Separate view of system resources | PID tree, network, mount points, user IDs, hostname |
| cgroups | Limit resource consumption | CPU, memory, disk I/O, network bandwidth |
| Seccomp profiles | Restrict available system calls | Block dangerous syscalls (e.g., ptrace, mount, setuid) |
| AppArmor/SELinux | Mandatory access control | File and network access per process |
Critically: a kernel vulnerability exploitable from within a container affects the host kernel directly. Container isolation is a defence-in-depth layer, not a hard security boundary like a hypervisor.
| Weakness | Risk | Control |
|---|---|---|
Running as root inside container | Maps to root on host if isolation fails | USER directive in Dockerfile; runAsNonRoot: true in K8s |
--privileged flag | Disables almost all namespace and cgroup isolation | Never use in production |
| Host path mounts | Container writes to host filesystem | Audit hostPath volumes; use PersistentVolumeClaims |
| Capabilities | Linux capabilities not needed by app | Drop all capabilities; add only what is needed |
A container image is the software supply chain materialised. Every vulnerability in the base image runs inside your containers.
Trivy scans container images, filesystems, and git repositories for:
trivy image nginx:latest
trivy image --severity HIGH,CRITICAL myapp:v2.1
Cosign (part of the Sigstore project) signs container images so clusters can verify images were built by trusted pipelines and have not been tampered with since signing.
cosign sign --key cosign.key myregistry/myapp:v2.1
cosign verify --key cosign.pub myregistry/myapp:v2.1
GCP Binary Authorization and AWS Signer integrate image signing into deployment pipelines — the cluster will refuse to run unsigned or invalidly signed images.
Falco is an open-source runtime security tool that monitors container behaviour using eBPF probes and generates alerts when behaviour deviates from policy:
| Falco Rule | What It Detects |
|---|---|
| Shell spawned in container | Attacker executing commands post-compromise |
Write to /etc directory | Configuration tampering |
| Outbound connection from database container | Data exfiltration or C2 |
| Package manager executed in container | Attacker installing tools |
Sensitive file read (/etc/shadow, /root/.ssh) | Credential harvesting |
Falco integrates with SIEM, Slack, and alerting platforms to route findings to security operations in real time.
Security for cloud-native applications must be applied at four layers simultaneously:
| Layer | Scope | Key Controls |
|---|---|---|
| Cloud | Provider infrastructure and account | IAM, network security groups, encryption, compliance |
| Cluster | Kubernetes cluster itself | RBAC, network policies, audit logging, CIS benchmark |
| Container | Individual container runtime | Non-root user, read-only filesystem, dropped capabilities, seccomp |
| Code | Application source code | SAST, dependency scanning, secrets management, input validation |
A vulnerability at any layer can compromise workloads above it. Security at the Cloud and Cluster layers does not compensate for insecure code; conversely, perfectly written code running as root in a privileged container is still dangerous.
| Risk | Description | Control |
|---|---|---|
| Overprivileged RBAC | Service accounts with cluster-admin or wildcard verbs | Least-privilege RBAC; audit with kubectl auth can-i --list |
| Default service account auto-mount | All pods auto-mount a service account token | automountServiceAccountToken: false in pod spec |
| Unauthenticated API server | Kubernetes API server accessible without authentication | Always enable RBAC; never set --anonymous-auth=true |
| Secrets in environment variables | K8s Secrets base64-encoded but not encrypted | Enable etcd encryption at rest; use external secrets (Vault, AWS Secrets Manager) |
| Network policy absence | All pods can communicate with all pods by default | NetworkPolicy resources to enforce micro-segmentation |
| Privileged containers | Containers with securityContext.privileged: true | Admission controllers (OPA Gatekeeper, Kyverno) to deny privileged pods |
Run kube-bench to assess your cluster against the CIS Kubernetes Benchmark:
kube-bench run --targets master,node,etcd,policies
Kube-bench evaluates over 200 controls covering API server flags, etcd configuration, RBAC settings, network policies, and node configuration.
Containers introduce a unique security model where the isolation boundary is the Linux kernel, not hardware. Secure containers from the supply chain (image scanning and signing), through the runtime (Falco, seccomp, non-root), to the cluster (RBAC, network policies, kube-bench). Apply the 4Cs so that no single layer is the only line of defence.