System Design FAQ: Top Questions

A Secrets Management System securely stores and provides access to sensitive data like API keys, passwords, certificates, and encryption keys. The system must prevent unauthorized access, provide auditability, and integrate with dynamic infrastructure.

📋 Functional Requirements

• Securely store and retrieve secrets
• Access control by role or policy
• Support for secret leasing and dynamic secrets
• Full audit logs for every access

📦 Non-Functional Requirements

• High availability and failover
• Strong encryption and tamper-proof storage
• Low-latency access APIs

🏗️ Core Components

• Storage Backend: Encrypted store (e.g., Consul, DynamoDB, FileSystem)
• Auth Backends: Token, LDAP, AWS IAM, Kubernetes SA
• Secrets Engines: Static (KV), dynamic (DB creds, PKI)
• Audit Logs: Tamper-evident logs to file or syslog

🔐 Secret Storage Example (KV v2)

# Store a secret
vault kv put secret/api stripe_key=sk_test_abc123

# Retrieve it
vault kv get secret/api
        

🔑 Dynamic Secret Example (PostgreSQL)

path "database/creds/readonly" {
  capabilities = ["read"]
}
        

vault read database/creds/readonly

# Output:
# {
#   "data": {
#     "username": "v-token-readonly-abc",
#     "password": "9dP4Zs4m3KwH"
#   },
#   "lease_duration": 3600
# }
        

🔒 Policies Example

path "secret/data/team-dev/*" {
  capabilities = ["create", "read", "update"]
}
        

📁 Audit Logging Example

vault audit enable file file_path=/var/log/vault_audit.log
        

🧰 Tools/Infra Used

• Secrets Engine: HashiCorp Vault, AWS Secrets Manager, Doppler
• Storage: S3, Consul, PostgreSQL, DynamoDB
• Auth: IAM, GitHub, JWT, LDAP, Kubernetes

📈 Observability

• Secrets access latency
• High-frequency access by path
• Unauthorized access attempts

📌 Final Insight

A secure secrets manager supports fine-grained access, dynamic credentials, and encrypted at-rest storage. Auditability and integrations with orchestration systems (K8s, CI/CD) make it indispensable in modern infra.