Cloud-Native Security

Cloud-native architectures require security approaches designed for dynamic, distributed, and ephemeral infrastructure. Traditional security tools don't work in environments where resources are created and destroyed in seconds.

Cloud-Native Security Controls

Scroll sideways to see the whole diagram

View full size View full size

Container Security

Containers are the unit of trust on a cloud-native platform, so hardening the image is the first control that matters. A container image is an immutable, layered filesystem — every build step leaves a layer behind, which means a secret copied into a layer cannot be removed by deleting it in a later step; it stays recoverable from the registry. NIST SP 800-190 (Application Container Security Guide) is the canonical reference: it maps risk across the image lifecycle, registry, orchestrator, container, and host.

The common failure is treating image scanning as a one-time gate. A base image that was clean at build time accumulates CVEs the moment a new advisory lands, and a scan at deploy time is too late if the running workload was never rebuilt. Enforce Kubernetes Pod Security Standards, pin digests rather than mutable tags, and rebuild on a schedule — not only on application changes. The OWASP Kubernetes Top 10 covers the workload-level risks — over-privileged service accounts, exposed dashboards, secrets in manifests — that an image scanner will not catch.

Practical: Hardened Dockerfile

# Stage 1: Build
FROM golang:1.25-alpine AS builder
RUN apk add --no-cache git ca-certificates
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server .

# Stage 2: Production — distroless image (no shell, no package manager)
FROM gcr.io/distroless/static-debian12:nonroot

# Copy only the binary and CA certs
COPY --from=builder /app/server /server
COPY --from=builder /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/

# Run as the distroless nonroot user (UID 65532)
USER nonroot:nonroot

# Distroless has no shell or curl, so the health check must invoke the binary.
# This requires the app to implement a health subcommand/flag.
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD ["/server", "-healthcheck"]

EXPOSE 8080

ENTRYPOINT ["/server"]

# What this achieves:
# ✓ Multi-stage build — no build tools in final image
# ✓ Distroless base — no shell, no package manager, ~2MB
# ✓ Non-root user — container cannot escalate to root
# ✓ Static binary — no libc dependency
# ✓ Stripped binary — smaller attack surface

Practical: Kubernetes Pod Security

# Kubernetes Pod Security Standards — Restricted profile
apiVersion: v1
kind: Pod
metadata:
  name: secure-app
  namespace: production
spec:
  automountServiceAccountToken: false  # Don't mount SA token
  securityContext:
    runAsNonRoot: true
    runAsUser: 65534
    runAsGroup: 65534
    fsGroup: 65534
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: registry.example.com/app:v1.2.3@sha256:abc123...
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
        # No privileged, no hostNetwork, no hostPID, no hostIPC
      resources:
        limits:
          cpu: "500m"
          memory: "256Mi"
          ephemeral-storage: "100Mi"
        requests:
          cpu: "100m"
          memory: "128Mi"
      volumeMounts:
        - name: tmp
          mountPath: /tmp
  volumes:
    - name: tmp
      emptyDir:
        sizeLimit: "50Mi"

Service Mesh Security

A service mesh (Istio, Linkerd, or Consul Connect) moves service-to-service security out of application code and into the sidecar proxy that interposes every call. That matters because TLS, certificate rotation, and per-call authorization are easy to implement inconsistently in each service and almost impossible to audit once they are. Centralizing them in the data plane gives one policy model and one telemetry stream for east-west traffic; the Istio security model documents how identity, certificates, and policy fit together.

The common failure is deploying the mesh but leaving mTLS in PERMISSIVE mode. In permissive mode the sidecar accepts both plaintext and mTLS, so a workload that never joined the mesh can still reach the service — encryption is available but not enforced. Move to STRICT mesh-wide only after every workload has a sidecar, and pair transport authentication with an AuthorizationPolicy that denies by default: mTLS proves who the caller is, not whether that caller may reach this route.

Practical: Istio mTLS & Authorization

# Enforce strict mTLS mesh-wide
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
# Allow only frontend -> api-server communication
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: api-server-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: api-server
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/production/sa/frontend"]
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/v1/*"]

CNAPP Comparison

Serverless Security

Cloud Security Posture Management (CSPM)

CSPM tools continuously monitor cloud configurations to detect misconfigurations, compliance violations, and security risks.

The control is continuous, API-driven configuration assessment: the tool reads the control plane of your cloud accounts (IAM policies, security groups, storage ACLs, encryption settings) and compares each resource against a benchmark such as the CIS Foundations Benchmarks. Its real value is the inventory and the drift signal, not the individual alert — a misconfiguration is a change, and the useful question is who can now reach that resource and what data it holds.

The common failure is running CSPM as an unfiltered firehose. Thousands of low-context findings train teams to ignore the tool, so the one critical public-data-store alert is lost in the noise. Scope the baseline to controls that map to your threats, route each finding to the owning team, and re-scan on infrastructure change instead of on a weekly cadence.

Infrastructure as Code Security

Evidence to Capture

Likely False Positives

Review Checklist

Remediation