Defense in Depth

Multiple layers of independent security controls. Assume any single layer can fail. The strategy under network policy + mTLS + RBAC + auth + audit logs all together.

Multiple independent layers. Each layer assumes the others might fail. A single bypass doesn’t compromise the system. Status: STUB — promoted to OUTLINE in Y3 Phase 27.

What this pattern is

Defense in depth layers multiple independent security controls so that breaching any single one does not compromise the system. The mental model: assume every layer will be bypassed eventually; design so the next layer catches what the previous missed. For basecamp this means simultaneously running NetworkPolicy (network layer), mTLS via mesh (transport layer), service-account-scoped RBAC (authz layer), application-level auth (request layer), Kyverno admission policies (cluster layer), Vault-managed secrets with rotation (credential layer), and audit logs (forensic layer). No single layer is sufficient; all together, the system has real security posture.

The independence between layers is the load-bearing invariant. If every “layer” is enforced by the same policy engine reading the same data, they’re not independent layers; they’re one layer painted three colors. Real defense in depth requires layers with independent failure modes: a NetworkPolicy bypass doesn’t defeat mTLS, an mTLS bypass doesn’t defeat RBAC, an RBAC bypass doesn’t defeat audit logging. Each layer’s failure surface is distinct enough that a single vulnerability, a single misconfiguration, or a single compromised component doesn’t collapse the entire posture.

The pattern matters because security is not a binary “we secured the perimeter” property. Every CVE, every misconfiguration, every social-engineering breach starts by penetrating one layer. Defense in depth turns “compromised” from a single event into a chain of events, and gives operators time to detect and respond. A senior security engineer thinks in these chains: not “how do we prevent all breaches” (impossible), but “when the first layer fails, does the second catch it?” and “when we notice the second layer catching things, does that alert the operators?”

Concrete instances in the wild

  • basecamp Y3+ posture. NetworkPolicy (Cilium L3/L4) + mTLS between pods (mesh) + service account RBAC (K8s) + application auth (OIDC) + Kyverno admission policies + Vault secrets rotation + audit logging (Loki + Tempo). Seven layers, each with independent enforcement.
  • AWS multi-account architecture. Root account isolated from workload accounts + IAM roles per service + VPC security groups + subnet ACLs + application auth + CloudTrail logging + GuardDuty anomaly detection. Distinct AWS services enforce each layer.
  • Zero-trust enterprise networks. Corporate VPN + device certificates + mesh mTLS + identity-aware proxies + application-level authorization + audit logging. Google’s BeyondCorp is the canonical public architecture.
  • Financial services APIs. WAF at the edge + rate limiting + API keys + OAuth2 scopes + downstream service-account scoping + database row-level security + audit trail. Regulatory requirements often mandate this stack.
  • Container escape defenses. Container runtime security (SELinux/AppArmor) + seccomp filters + read-only filesystem + non-root user + resource limits + admission-time policy checks. Each layer defends against a different class of container escape.
  • Multi-cloud disaster resilience. Data replicated across regions + backup snapshots + off-site storage + immutable audit logs + DR-tested restore procedures. Not classical security, but the same “assume any single layer fails” mindset applied to durability.
  • Password authentication with modern hygiene. Password + rate limiting + geographic anomaly detection + device fingerprinting + optional 2FA + session monitoring. Each layer catches a different attack class.

Why this pattern matters

The alternative to defense in depth is single-perimeter security: harden one boundary, trust everything inside it. This model dominated corporate networks through the 1990s and 2000s. It fails whenever anything crosses the perimeter (VPN compromise, insider threat, supply chain attack). Every major breach in the post-2015 era involved a compromised perimeter component; each was contained (or wasn’t) by whatever depth existed inside.

Real security incidents illustrate the pattern’s value. The Capital One breach: an SSRF vulnerability in a web app compromised an IAM role that had broad S3 access. Missing depth: the IAM role’s scope was too wide. The 2020 SolarWinds attack: compromised build system pushed malicious code to thousands of customer environments. Missing depth: no independent verification that build artifacts matched expected content. The Equifax breach: unpatched Struts vulnerability in a public-facing service that also had database credentials. Missing depth: the compromised service shouldn’t have had those credentials.

Modern platforms make depth cheaper than the 2000s era’s “one shared admin role.” Kubernetes RBAC, cloud IAM roles, service mesh identity, Kyverno policies, Vault secrets — each layer is essentially free to configure once you have the substrate. What was heroic engineering in 2010 (identity-aware proxies, mesh mTLS) is a checkbox in 2026. Skipping depth in 2026 is a choice, not a constraint.

The pattern also matters for detection. Independent layers produce independent signals. When a network policy blocks traffic that RBAC would also have blocked, both events are logged; correlation reveals attempted intrusions. Without depth, you get one signal per attack (often the successful one); with depth, you get chains of signals that reveal attacks in progress.

Depth progression

STUB     ← you are here.
OUTLINE  Promoted when Y3 Phase 27 lands the full layered stack on basecamp.
DEEP     Promoted after Y3 end — at least one observed near-miss where one
         layer caught what another would have allowed.

Preview: what OUTLINE will answer

When Y3 Phase 27 promotes this entry to OUTLINE, it will name:

  • PROBLEM. How do you build a security posture that survives the failure of any single control?
  • PRINCIPLES. Independence between layers. Each layer defends against a distinct attack class. Layers produce independent signals for detection. Every layer’s bypass surface is documented. No single point of failure across the stack.
  • TRADE-OFFS. Operational overhead (more layers to configure and monitor) vs security posture. False-positive rate (strict layers block legitimate traffic) vs false-negative rate. Detection latency (log-based) vs prevention latency (in-line). Cost of each layer vs risk mitigated.
  • TOOLS (time-stamped as of 2026-06): Network layer (Cilium NetworkPolicy, AWS security groups, Azure NSGs). Transport layer (mesh mTLS via Cilium, Istio, Linkerd). Authz layer (K8s RBAC, cloud IAM, OPA). Admission layer (Kyverno, OPA Gatekeeper, K8s validating webhooks). Secrets layer (Vault, External Secrets Operator, cloud KMS). Audit layer (Loki, CloudTrail, Kubernetes audit logs, mesh access logs).

The DEEP promotion, after Y3 end with at least one near-miss observed, will add MASTERY (operating the full stack for months), COMPARE (Cilium NetworkPolicy vs Calico NetworkPolicy vs cloud security groups as three layers of the same concept), OPERATE (a real incident where multiple layers activated to contain a breach), and CONTRIBUTE (documentation for a specific layer configuration or a Kyverno policy contributed upstream).

Canonical references

  • NIST SP 800-207, Zero Trust Architecture — the authoritative modern reference. Free from NIST.
  • Google’s BeyondCorp papers (2014-2018) — the canonical public zero-trust and defense-in-depth architecture.
  • Ross Anderson, Security Engineering — classic textbook, chapters on layered defenses.
  • Kelsey Hightower’s Kubernetes security talks — practical layered K8s security.
  • CNCF Kubernetes Security Whitepaper — modern reference for K8s-specific layers.

Cross-references