Authentication, Policies & Operational Patterns

The Bootstrap Problem: "Secret Zero"

Vault removes the need to hand out most secrets directly — but something still has to bootstrap trust: the initial credential an app uses to authenticate to Vault at all. Platform-native auth methods exist specifically to avoid "secret zero" being yet another long-lived static secret to manage.

Kubernetes Auth Method

vault write auth/kubernetes/role/myapp \
  bound_service_account_names=myapp \
  bound_service_account_namespaces=default \
  policies=myapp-policy \
  ttl=1h

A pod authenticates by presenting its existing Kubernetes service account token; Vault verifies it against the Kubernetes API and issues a scoped Vault token — no separate long-lived credential needs to be injected into the pod.

Policies & Least Privilege

path "secret/data/myapp/*" {
  capabilities = ["read", "list"]
}

Policies (HCL/JSON) define exactly which paths and operations an identity may access. Least privilege means granting each identity only the specific secrets it needs — so a compromised service only exposes the narrow set it was authorized to read, not the whole Vault.

Vault Agent & Audit Logging

Vault Agent runs as a sidecar, handling authentication, token renewal, and secret retrieval/templating so application code doesn't need Vault-specific logic — it just reads a rendered file or environment variable. Audit devices record every request/response Vault handles, giving a tamper-evident trail of who accessed which secret and when, critical for compliance and incident investigation.

Multi-Tenancy: Namespaces

Vault Enterprise namespaces give isolated administrative and access-control boundaries within a single cluster — separate policies, auth methods, and secrets engines per team or business unit, without standing up a fully separate Vault deployment for each.