Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Introduction to Vault

Introduction to Vault

Vault secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault handles leasing, key revocation, key rolling, and auditing. Vault presents a unified API to access multiple backends: HSMs, AWS IAM, SQL databases, raw key/value, and more.

This talk covers the design and brief tutorial of Vault.

Seth Vargo

May 20, 2015
Tweet

More Decks by Seth Vargo

Other Decks in Technology

Transcript

  1. WHAT IS A SECRET? Security-sensitive information Personally-identifiable information (PII) DB

    User/Pass, AWS IAM Credentials, SSL Keys, Encryption Keys Anything that would make the news
  2. HOW DO I DISTRIBUTE SECRETS? How do applications get secrets?

    How do operators get secrets? How do secrets get updated? How do secrets get revoked?
  3. WHY NOT (ONLINE) DATABASES? RDBMS, Consul, ZooKeeper, etc Not designed

    for secrets Limited access controls Plaintext Storage No Auditing, Revocation
  4. SECRET SPRAWL Secret material is distributed Who has access? When

    were secrets used? What is the attack surface? What do we do in the event of a compromise?
  5. STATE OF THE WORLD Secret Sprawl Decentralized Keys Limited Visibility

    Poorly defined “break glass” procedures
  6. VAULT GOALS Single source for Secrets Programmatic Application Access (Automated)

    Operator Access (Manual) Practical Security Modern Data Center Friendly
  7. VAULT FEATURES Secure Secret Storage (in-memory, Consul, file, and more)

    Dynamic Secrets Leasing, Renewal, and Revocation Auditing Rich ACLs Multiple Client Authentication Methods
  8. SECURE SECRET STORAGE Data is encrypted in transit and at

    rest 256bit AES in GCM mode TLS 1.2 for clients No HSM required
  9. DYNAMIC SECRETS Never provide “root” credentials to clients Provide limited

    access credentials based on role Generated on  demand when requested Leases are enforceable via revocation Audit trail can identify point of compromise
  10. ## DESCRIPTION The PostgreSQL backend dynamically generates database users. After

    mounting this backend, configure it using the endpoints within the "config/" path. ## PATHS The following paths are supported by this backend. To view help for any of the paths below, use the help command with any route matching the path pattern. Note that depending on the policy of your auth token, secure  master vault help postgresql
  11. Key Value lease_id postgresql/creds/production/a99b952e-222c-6eb... lease_duration 3600 lease_renewable true username vault-root-1432058254-7887

    password 17a21ba7-8726-97e4-2088-80b7a756702b secure  master vault read postgresql/creds/production
  12. 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 Not possible for transit backend
  13. AUDITING Pluggable Audit Backends Request and Response Logging Prioritizes Safety

    over Availability Secrets Hashed in Audits Searchable, but not reversible
  14. RICH ACLS Role Based Policies Restrict access to “need to

    know” Default Deny, must be explicitly allowed
  15. Sealed: true Key Shares: 10 Key Threshold: 7 Unseal Progress:

    6 High-Availability Enabled: false secure  master vault status
  16. Key (will be hidden): Sealed: false Key Shares: 10 Key

    Threshold: 7 Unseal Progress: 0 secure  master vault unseal
  17. WATCHING THE WATCHMEN Master Key is the “key to the

    kingdom” All data could be decrypted Protect against insider attack Two-Man Rule
  18. 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
  19. SUMMARY Solves the “Secret Sprawl Problem” Protects against external threats

    (Cryptosystem) Protects against internal threads (ACLs and Secret Sharing)
  20. PERSONALLY IDENTIFIABLE INFORMATION PII information is everywhere SSN, CC#, OAuth

    Tokens, etc. Email? Physical address? Security of storage? Scalability of storage? Audibility of access?
  21. PII WITH VAULT “transit” backend in Vault Encrypt/Decrypt data in

    transit Avoid secret management in client applications Builds on Vault foundation
  22. TRANSIT BACKEND Web server has no encryption keys Requires two-factor

    compromise (Vault + Datastore) Decouples storage from encryption and access control
  23. FUTURE: CERTIFICATE AUTHORITY Vault acts as Internal CA Vault stores

    root CA keys Dynamic Secrets - Generates signed TLS keys No more tears
  24. FUTURE: MUTUAL TLS FOR SERVICES Dynamic CA allows all services

    to generate keys All internal service communication can use mutual TLS End-to-End encryption inside the datacenter
  25. SECURITY FOUNDATION Early days of Vault “transit” backend shows clever

    uses of primitives Certificate Authority extends use cases, reduces moving pieces
  26. CONSUL TEMPLATE INTEGRATION Secrets templatized into application configuration Vault is

    transparent Lease management is automatic Non-secret configuration still via Consul
  27. {{ with $secret := vault "postgresql/creds/production" }} --- production: adapter:

    postgresql database: postgres.service.consul username: {{$secret.Data.username}} password: {{$secret.Data.password}} pool: {{key "production/postgres/pool"}} {{ end }} secure  master cat secrets.yml.ctmpl
  28. APPLICATION INTEGRATION Future: envconsul Vault oblivious, read environment variables Future:

    KeyWhiz-style FUSE FS Vault oblivious, Read “files”, in-memory only
  29. VAULT Secrets Management Modernized Fixes the Secret Sprawl Problem Easy

    to Integrate Small and lightweight (15MB) Provides Security Foundation
  30. VAULT ROADMAP Planned external code audit by security research firm

    Integrate across HashiCorp tools Tame the Modern Datacenter