Secrets Management & Machine Identity

Secret sprawl is one of the most dangerous problems in cloud-native security. API keys in environment variables, database passwords in ConfigMaps, certificates that never rotate, and Vault tokens that need their own distribution mechanism. Each secret is a breach vector. Workload identity replaces most of these with cryptographic proof that needs no distribution.

Kubernetes Secrets: The Problem

Kubernetes Secrets are base64-encoded (not encrypted) by default. They are accessible to anyone with RBAC access to the namespace. They persist in etcd and must be encrypted at rest explicitly. They have no automatic rotation mechanism.

HashiCorp Vault Integration

Vault provides encrypted secret storage, dynamic credentials (database passwords generated on demand and automatically revoked), PKI certificates, and transit encryption. The key integration: workloads authenticate to Vault using their SPIFFE SVID instead of static Vault tokens.

Dynamic Secrets

# Instead of: static database password shared across all services
# Vault generates: unique short-lived credentials per service
# Each credential is automatically revoked after TTL expires

# Vault dynamic database credential:
vault read database/creds/readonly
# Key             Value
# lease_id        database/creds/readonly/abc123
# lease_duration  1h
# username        v-svc-readonly-xyz123  (unique per request!)
# password        A1b2C3-random-xyz      (auto-revoked in 1 hour)

Replacing Secrets with Workload Identity

The ultimate goal: eliminate static secrets entirely. Services authenticate with their SVID (automatic, short-lived, no distribution needed). Vault issues dynamic credentials based on verified identity. Certificates are managed by SPIRE (automatic rotation). The only secret that remains is the Vault unseal key — protected by cloud KMS.