What Are Containers?

A container is a standard unit of software that packages code and all its dependencies so the application runs quickly and reliably across different computing environments. Unlike virtual machines, containers share the host operating system kernel and do not require a full OS per instance, making them lightweight, fast, and highly portable.

Containers vs. Virtual Machines

Linux Kernel Security Primitives

Container security is built on several Linux kernel features. Understanding these primitives is essential for evaluating container isolation and knowing where it breaks down.

Container Security Threat Surface

The container security threat surface spans four distinct layers, each requiring dedicated controls:

Docker Security Hardening

Docker Engine exposes significant security controls that are disabled or permissive by default. Hardening requires explicit configuration at both the daemon and container levels.

Docker Daemon Security

• Never expose the Docker socket (/var/run/docker.sock) to containers — this grants root-equivalent host access
• If access is required (e.g., for CI/CD), use Docker-in-Docker (DinD) with proper isolation, or the Kaniko/Buildah alternatives
• Enable Docker Content Trust (DCT) to verify image signatures before pulling: export DOCKER_CONTENT_TRUST=1
• Configure daemon to use user namespaces (userns-remap) to map container root to unprivileged host user
• Enable live-restore to keep containers running during daemon restarts, reducing availability risk
• Restrict the Docker daemon to a Unix socket and never bind to TCP without TLS mutual authentication

Container Runtime Security Flags

Secure Container Image Construction

Image security begins at build time. The image is the supply chain artifact — vulnerabilities, misconfigurations, and secrets baked into images persist to every deployment.

Minimal Base Image Strategy

• Use distroless or scratch base images for production workloads — eliminate shells, package managers, and unused binaries
• If a base OS is needed, prefer Alpine Linux (musl libc, ~5MB) or slim variants of official images
• Never use latest tag — pin to specific immutable digest: FROM node:20.11.0-alpine3.19@sha256:<digest>
• Regularly rebuild images to pick up base image security patches; automate via CI/CD pipeline

Dockerfile Security Best Practices

• USER instruction — always switch from root before the final CMD/ENTRYPOINT: USER nonroot or USER 1001:1001
• Multi-stage builds — use a build stage with build tools and copy only the final artifact to a minimal runtime stage
• COPY vs ADD — always use COPY unless ADD’s tar extraction feature is explicitly needed
• No secrets in layers — never use ENV or ARG for passwords/API keys; use runtime secret injection
• Minimize layers — combine RUN commands to reduce attack surface; delete package caches in same RUN
• HEALTHCHECK instruction — add health checks so orchestrators can detect and restart compromised containers

Container Image Scanning

Image scanning analyzes container images for known CVEs, misconfigurations, exposed secrets, and malware. It must be integrated into the CI/CD pipeline (shift-left) and run continuously in the registry.

Scanning Integration Points

• Pre-commit: Developer IDE plugins (Snyk, Trivy VS Code extension) for immediate feedback
• CI pipeline: Mandatory scan gate — fail build if CRITICAL/HIGH CVEs above defined threshold
• Registry: Continuous scanning of stored images (Amazon ECR scanning, Azure Container Registry, JFrog Xray)
• Pre-deployment: Admission controller webhook validates scan results before pods are created in Kubernetes
• Runtime: Behavioral scanning to detect anomalies at execution time (Falco, Aqua, Sysdig)

Secrets Management in Containers

Secrets (passwords, API keys, TLS certificates, tokens) must never be baked into container images, passed as environment variables from insecure sources, or stored in plaintext in configuration files.

Secrets Anti-Patterns to Avoid

• ENV DB_PASSWORD=SuperSecret123 in Dockerfile — visible in image history, all layers, and docker inspect
• Storing secrets in environment variables passed via docker run -e — visible to all processes in the container
• Copying .env files or config files with credentials into the image during build
• Hard-coding credentials in application code committed to source control

Recommended Secrets Injection Patterns

• Docker Secrets (Swarm mode) or Kubernetes Secrets (with encryption at rest) — mounted as tmpfs files
• External secrets manager: AWS Secrets Manager, Azure Key Vault, HashiCorp Vault — retrieved at runtime via sidecar or init container
• CSI Secrets Store Driver (Kubernetes) — mounts secrets from external vault directly as volume at pod startup
• IRSA / Workload Identity — use cloud provider’s pod identity mechanism to grant IAM-based access without credentials

Kubernetes Security Architecture

Kubernetes orchestrates containerized workloads across clusters of nodes. Its distributed architecture introduces a large and complex security surface. Compromising the API server is effectively equivalent to compromising every workload in the cluster.

Key Components & Their Security Roles

Kubernetes RBAC

Role-Based Access Control (RBAC) is the primary authorization mechanism in Kubernetes. Misconfigured RBAC is the most common path to cluster-wide privilege escalation.

RBAC Concepts

• Role / ClusterRoleDefines a set of permissions (verbs: get, list, create, delete, etc.) on resources (pods, secrets, deployments, etc.)
• RoleBinding / ClusterRoleBindingBinds a Role to a Subject (User, Group, or ServiceAccount) within a namespace or cluster-wide
• ServiceAccountIdentity for pod workloads; each pod runs under a ServiceAccount and can be granted RBAC permissions

RBAC Security Best Practices

• Apply least privilege — grant only the minimum verbs and resources needed; avoid wildcards (verbs: ["*"], resources: ["*"])
• Use kubectl auth can-i and tools like Rakkess or kubectl-who-can to audit what subjects can do
• Never bind cluster-admin to service accounts, users, or groups in production
• cluster-admin grants full access to all resources and namespaces — treat like a break-glass account
• Disable auto-mounting of service account tokens for pods that do not need API access: automountServiceAccountToken: false
• Audit RBAC bindings regularly — use rbac-tool, Polaris, or Tetragon to detect over-permissive bindings
• Avoid using default service accounts — create dedicated service accounts per workload with minimal permissions

Pod Security Standards (PSS)

Pod Security Standards replaced PodSecurityPolicies in Kubernetes v1.25. They define three security profiles enforced via the built-in Pod Security Admission controller:

Kubernetes Network Policies

By default, all pods in a Kubernetes cluster can communicate with all other pods across all namespaces. Network Policies are namespace-scoped resources that define ingress and egress rules for pod-to-pod communication, implementing micro-segmentation within the cluster.

Network Policy Best Practices

• Start with a default-deny-all ingress and egress policy in every namespace, then explicitly allow required traffic
• Use namespace selectors to restrict cross-namespace communication to only required service dependencies
• Use pod selectors with specific labels to limit which pods can communicate with sensitive workloads (databases, secret stores)
• Egress policies are equally important — prevent pods from exfiltrating data or reaching C2 infrastructure
• Use a CNI plugin that enforces Network Policies: Calico, Cilium, Weave Net (confirm CNI supports Network Policy objects)

Admission Controllers for Security

• OPA Gatekeeper / KyvernoPolicy-as-code engines that enforce organizational policies at admission time
• ImagePolicyWebhookValidates image signatures and registry allowlists before pod creation
• ValidatingAdmissionWebhookCustom validation logic for any Kubernetes resource
• MutatingAdmissionWebhookAutomatically injects security controls (sidecars, labels, annotations)

What Is Serverless Computing?

Serverless computing is a cloud execution model where the cloud provider dynamically manages the allocation of compute resources. Developers write and deploy individual functions; the provider handles provisioning, scaling, patching, and infrastructure management entirely. The term ‘serverless’ is a misnomer — servers still exist, but they are completely abstracted from the developer.

Function as a Service (FaaS) Execution Model

• Functions are stateless, short-lived execution units triggered by events (HTTP, queue messages, database changes, schedules)
• Execution environments are ephemeral — a ‘cold start’ provisions a new container; ‘warm’ instances may be reused within a short window
• Billing is per-invocation and per-millisecond of execution — unused functions cost nothing
• Maximum execution timeout limits apply: AWS Lambda (15 min), Azure Functions (Consumption: 5–10 min), GCF (9 min)

Serverless vs. Containers — Security Comparison

Shared Responsibility in Serverless

The serverless model shifts the majority of infrastructure responsibility to the provider, but does not eliminate customer security obligations. The customer’s security focus shifts from infrastructure to application code, dependencies, IAM, and event source security.

Serverless Platform Security Features

OWASP Serverless Top 10

OWASP has identified the top 10 security risks specific to serverless architectures. These differ meaningfully from the traditional OWASP Top 10 due to the unique execution model:

Serverless-Specific Attack Techniques

Event Injection

Every event source that triggers a serverless function is a potential injection vector. Unlike web applications where the HTTP request is the primary input, serverless functions may process data from dozens of sources simultaneously:

• S3 Event injection: Attacker uploads a file with a malicious filename containing path traversal or command injection characters
• SQS/SNS message injection: Attacker places crafted JSON payloads into a message queue consumed by a function
• DynamoDB Streams: Database record changes processed by functions — attacker with DynamoDB write access can inject payloads
• API Gateway: Standard HTTP injection vectors (SQLi, XSS, XXE, SSRF) — all apply when functions process HTTP events

Denial of Wallet (DoW) Attacks

Serverless billing is consumption-based. Attackers who can trigger function invocations can generate massive compute bills, causing financial damage without causing availability impact.

• Flood an unauthenticated API Gateway endpoint with millions of requests — each invokes a Lambda at fractions of a cent, totaling thousands of dollars
• Trigger recursive function chains — a function that calls itself or creates a cycle of invocations
• Mitigation: Set Lambda concurrency limits (reserved and provisioned), API Gateway throttling, AWS Budgets alerts, WAF rate limiting

Lateral Movement via IAM

In serverless environments, lateral movement occurs through IAM rather than network connections. A compromised function’s execution role is the attacker’s access vehicle:

• Excessive permissions on the execution role allow the attacker to enumerate other AWS services, read S3 buckets, invoke other Lambda functions, or access databases
• AssumeRole capability in the execution role can allow cross-account movement
• Mitigation: Least-privilege execution roles scoped to exactly what the function needs; AWS IAM Access Analyzer to detect overly broad policies

Shift-Left Security in Container & Serverless Pipelines

Shift-left security embeds security controls earlier in the software development lifecycle, catching vulnerabilities when they are cheapest to fix — in development, not in production. For container and serverless workloads, this means integrating security tooling directly into the developer workflow and CI/CD pipeline.

Security Gates Across the SDLC Pipeline

Software Bill of Materials (SBOM)

An SBOM is a formal, machine-readable inventory of all software components and dependencies in an application or container image. It is the foundation of software supply chain security, enabling rapid identification of components affected by newly disclosed CVEs.

SBOM Standards

• SPDXSoftware Package Data Exchange — Linux Foundation standard; ISO/IEC 5962:2021; supported by GitHub
• CycloneDXOWASP standard; feature-rich; supports VEX (Vulnerability Exploitability eXchange) for CVE context

SBOM Generation for Containers & Serverless

• Syft (Anchore) — generates SBOMs from container images, directories, and archives in SPDX, CycloneDX, and JSON formats
• Trivy — combined scanner and SBOM generator; outputs CycloneDX and SPDX formats
• Amazon Inspector — generates SBOMs from ECR images; exports to S3 for governance programs
• For serverless: generate SBOM from the deployment package (ZIP/JAR) before packaging and deploying

Supply Chain Attack Prevention

Supply chain attacks compromise software at the build or distribution stage, affecting all downstream consumers. SolarWinds (2020) and the XZ Utils backdoor (2024) demonstrated the catastrophic potential of build pipeline compromise.

Key Controls

• Code signing — sign all container images and serverless deployment packages with Cosign (Sigstore) or AWS Signer; verify signatures at deployment
• Hermetic builds — CI/CD builds should only access pre-approved, pinned dependencies from internal mirrors; no live internet dependency resolution
• Pinned dependencies — use exact version hashes (package-lock.json, poetry.lock, go.sum) not floating version ranges
• Trusted base image registry — maintain an internal registry of approved, scanned base images; block pulls from public registries in production
• Build environment hardening — build agents should be ephemeral, isolated, and minimal; rotate secrets and credentials after each build
• SLSA Framework (Supply chain Levels for Software Artifacts) — adopt SLSA Level 2+ for provenance attestation of all artifacts

Container Runtime Security Monitoring

Runtime security monitoring detects threats that static scanning cannot: zero-days, misuse of legitimate tools, insider threats, and configuration drift. It observes the live behavior of containers and triggers alerts on anomalies.

Falco — Cloud-Native Runtime Security

Falco (CNCF project) is the de-facto open-source runtime security engine for containers and Kubernetes. It monitors Linux system calls and Kubernetes audit events, comparing them against a rule set to detect malicious or anomalous activity.

• Detects: shell spawned in container, sensitive file reads (/etc/shadow, /etc/passwd), outbound network connections to unexpected IPs
• Detects: privilege escalation, namespace changes, container image overrides, Kubernetes API abuse
• Integrates with: Slack, PagerDuty, Splunk, Elasticsearch, Falcosidekick for alerting and response automation

Key Falco Rules for Container Security

Serverless Runtime Security

AWS Lambda Runtime Security Controls

• AWS Lambda Power ToolsStructured logging, tracing, and input validation utilities for Lambda functions
• Amazon GuardDuty Lambda ProtectionDetects anomalous Lambda invocation patterns, exfiltration attempts, and credential abuse in function executions
• AWS CloudTrailLogs all Lambda management API calls; essential for detecting unauthorized function modification or invocation
• Function URL authenticationNever deploy Lambda function URLs without IAM authentication or custom authorizers
• Reserved concurrencySet maximum concurrent executions per function to limit blast radius of runaway invocations

Serverless Security Observability

• Log all invocations with structured JSON including: function name, version, request ID, event source, input schema hash, execution duration, outcome
• Emit custom metrics for: failed input validations, authentication failures, unexpected event sources, execution timeouts
• Distributed tracing (AWS X-Ray, Open Telemetry) to track request flow across function chains and identify anomalous call patterns

Incident Response for Ephemeral Environments

The ephemeral nature of containers and serverless functions creates unique forensic challenges: evidence may be destroyed within seconds of an incident if not captured proactively. Standard forensic procedures must be adapted for cloud-native environments.

Container Incident Response Playbook

• Detect
  GuardDuty/Falco alert fires; correlate with CloudTrail, VPC Flow Logs, and container runtime logs
• Preserve Evidence
  Immediately capture: running process list (docker top), network connections (netstat), environment variables (docker inspect), and take a container filesystem snapshot before stopping
• Contain
  Apply network policy deny-all to the compromised pod’s label selector; scale deployment to 0 replicas; preserve the original pod (do not delete) for forensics
• Isolate
  Cordon the node if host compromise is suspected (kubectl cordon <node>); drain non-affected workloads
• Analyze
  Mount container filesystem snapshot in an isolated forensic environment; analyze logs, binaries, and network artifacts
• Eradicate
  Rebuild image from known-good source; redeploy from clean artifact; rotate all credentials the workload had access to
• Recover
  Deploy patched workload; verify integrity with image signature verification; increase monitoring intensity for 72 hours
• Post-Incident
  Root cause analysis; update Falco rules, admission policies, and runbooks; report per regulatory timelines

References & Further Reading

• OWASP Serverless Top 10 — owasp.org/www-project-serverless-top-10
• CIS Docker Benchmark v1.6 — cisecurity.org/benchmark/docker
• CIS Kubernetes Benchmark v1.9 — cisecurity.org/benchmark/kubernetes
• NIST SP 800-190: Application Container Security Guide
• Kubernetes Official Security Documentation — kubernetes.io/docs/concepts/security
• CNCF Falco Project — falco.org / github.com/falcosecurity/falco
• Sigstore / Cosign — sigstore.dev for container image signing
• SLSA Framework — slsa.dev
• CISA SBOM Guidance — cisa.gov/sbom
• AWS Lambda Security Best Practices — docs.aws.amazon.com/lambda/latest/dg/lambda-security
• Google Cloud Functions Security — cloud.google.com/functions/docs/securing
• Microsoft Azure Functions Security — learn.microsoft.com/azure/azure-functions/security-concepts
• Aqua Security Blog — blog.aquasec.com — container and serverless security research
• Trail of Bits — Container Security Guide — github.com/trailofbits/algo