PerconaLive 2016 Santa Clara presentation on Hashicorp Vault with CTO Armon Dadger
https://www.percona.com/live/data-performance-conference-2016/sessions/using-vault-decouple-secrets-applications
16. WHY NOT CONFIG MANAGEMENT?
Centrally stored
Eventually consistent
No access control
No audi3ng
No revoca3on
17. WHY NOT (ONLINE) DATABASES?
RDBMS, Consul, ZooKeeper, etc
Not designed for secrets
Limited access controls
Typically plaintext storage
No audi3ng or revoca3on abili3es
18. HOW TO HANDLE SECRET SPRAWL?
Secret material is distributed
Who has access?
When were secrets used?
What is the aMack surface?
What do we do in the event of a compromise?
19. STATE OF THE WORLD 1.0
Secret sprawl
Decentralized keys
Limited visibility
Poorly defined “break glass” procedures
22. VAULT GOALS
Single source for secrets
Programma3c applica3on access (Automated)
Operator access (Manual)
Prac3cal security
Modern data center friendly
23. VAULT FEATURES
Secure secret storage (in-memory, Consul, file, postgres, and more)
Audi3ng
Rich ACLs
Mul3ple client authen3ca3on methods
Leasing, renewal, and revoca3on
Dynamic secrets
24. SECURE SECRET STORAGE
Data is encrypted in transit and at rest
256bit AES in GCM mode
TLS 1.2 for clients
No HSM required
28. LEASING, RENEWAL, AND REVOCATION
Every Secret has a Lease*
Secrets are revoked at the end of the lease unless renewed
Secrets may be revoked early by operators
“Break Glass” procedure
Dynamic Secrets make leases enforceable
Not possible for arbitrary secrets
29. DYNAMIC SECRETS
Never provide “root” creden3als to clients
Provide limited access creden3als based on role
Generated on demand when requested
Leases are enforceable via revoca3on
Audit trail can iden3fy point of compromise
53. UNSEALING THE VAULT
Data in Vault encrypted
Vault requires encryp3on key
Must be provided online
54. WATCHING THE WATCHMEN
Master Key is the “key to the kingdom”
All data could be decrypted
Protect against insider aMack
Two-Man Rule
55. SHAMIR SECRET SHARING
Protect Encrypt Key with Master Key
Split Master Key into N shares
T shares to recompute Master
Quorum of key holders required to
unseal
Default N:5, T:3
56. SUMMARY
Solves the “Secret Sprawl Problem”
Protects against external threats (Cryptosystem)
Protects against internal threats (ACLs and Secret Sharing)
60. SECURITY FOUNDATION
Base of Trust
Core Infrastructure
Flexible Architecture
Founda3on for Security Infrastructure
61. PERSONALLY IDENTIFIABLE INFORMATION
PII informa3on is everywhere
SSN, CC#, OAuth Tokens, etc.
Email? Physical address?
Security of storage?
Scalability of storage?
Audibility of access?
62. PII WITH VAULT
“transit” backend in Vault
Encrypt/Decrypt data in transit
Avoid secret management in client applica3ons
Builds on Vault founda3on
63. TRANSIT BACKEND
Web server has no encryp3on keys
Requires two-factor compromise (Vault + Database)
Decouples storage from encryp3on and access control
64. EXTENSIBLE
PKI backend for Cer3ficate Authority + Signing
Mutual TLS for Applica3ons
SSH backend for SSH key management
“vault ssh” CLI command, dynamic keys or one-3me-passwords
68. CONSUL TEMPLATE INTEGRATION
Secrets templa3zed into applica3on configura3on
Vault is transparent
Lease management is automa3c
Non-secret configura3on s3ll via Consul
69. {{ with $secret := vault "mysql/creds/production" }}
---
production:
adapter: mysql
database: mysql.service.consul
username: {{$secret.Data.username}}
password: {{$secret.Data.password}}
pool: {{key "production/mysql/pool"}}
{{ end }}
secure master cat secrets.yml.ctmpl