Since its first release in 2015, HashiCorp Vault has grown from a place to keep secrets to a platform that provides comprehensive secrets management, encryption as a service, and identity-based security for some of the largest organizations in the world. While Vault 1.0 saw auto-unseal become open source and introduced batch tokens improved performance, feature completeness, and enterprise readiness, Vault 1.1 focuses on building workflow enablement and increasing scaling and operations.

1. Vault 1.1 Features
Secret caching, OIDC Authentication, and Transit
Auto-Unseal.

2. Vault 1.1 Webinar
Nick Cabatoff
Software Engineer at HashiCorp

3. OpenID Connect
Use third-party OIDC
providers to authenticate
users via web browser.
e.g. Azure AD, Auth0,
Gitlab, Google,
Keycloak, Okta
Secret Caching
Vault Agent can now run
as a caching proxy. This
can reduce load on Vault.
It can also simplify
applications by letting
them delegate lease
renewal.
Transit
Auto-Unseal
Instead of a cloud provider,
use another Vault cluster to
auto-unseal your Vault
cluster.

4. Links
This webinar's demos:
https://github.com/ncabatoff/vault-1.1-webinar
Tutorial: OIDC with Auth0:
https://learn.hashicorp.com/vault/operations/oidc-auth
Tutorial: Vault agent caching:
https://learn.hashicorp.com/vault/identity-access-management/agent-caching
Tutorial: Transit Auto-unseal:
https://learn.hashicorp.com/vault/operations/autounseal-transit

5. OIDC-based Authentication
Vault 1.1 Webinar

6. Copyright © 2019 HashiCorp
Vault Identity
6

7. OpenID Connect Concepts
● ID Token: a JWT token returned by OIDC
provider when user authenticates successfully
● Claim: name/value pair found in ID Token

8. OIDC and Vault
● Vault points browser at OIDC provider, with
redirect_url pointing back to itself
● User authenticates, then gets sent back to
redirect_url, along with ID Token
● Vault parses ID Token claims and logs user in

9. Demo can be found
at https://github.com/ncabatoff/vault-1.1-webinar
Auth0 OIDC Demo

10. Vault Agent Cache
Vault 1.1 Webinar

11. Agent auto_auth
● Configure agent with auth method, e.g. aws
● Agent logs in to Vault at startup, renews token
as needed
● Agent writes token to sink(s)

12. Agent cache
● Configure Agent with cache{} block, listener
● Set your app's VAULT_ADDR=agent listener
● Agent may proxy your request to Vault
● Agent may return without speaking to Vault
a. Might already have secret cached
b. Might decide you don't need to renew yet

13. Cache + auto-auth
● if a request includes a token, it will be used
● if no token in request but config has
cache { use_auto_auth_token = true }
then auto_auth token will be used

14. Cache characteristics
● Scope of cache: tokens and dynamic secrets (not KV)
● Eviction policy: Upon revocation, or on request.
● Auto-renews leases so you don't have to
* only renews leases created with tokens managed by
Agent

15. Cache, tokens, and auto-auth
WARNING
● When auto_auth token expires, so will any
secrets created this way
● Agent is stateless: when it exits, its auto_auth
token is lost, and any leases it created will
eventually expire

16. Security concerns
● Like Vault, secrets are kept in memory
● Unlike Vault, Agent is likely to be run in many
places, including closer to the "edge"
● Agent isn't going to have any more secrets than
your application would, so shouldn't increase
risk

17. Demo can be found at
https://github.com/ncabatoff/vault-1.1-webinar
Agent Cache Demo

18. Transit Auto-Unseal
Provider
Vault 1.1 Webinar

19. Manual Unseal
● Split key into many pieces
● Give each piece to one person
● Need people to supply those
keys at startup to unseal Vault

20. Auto-Unseal
Auto-Unseal recap: store the unseal keys locally,
but encrypted via some third-party key source
● Cloud: some cloud provider KMS
● HSM: hardware device
● Transit: another Vault cluster

21. Auto-Unseal

22. Transit Auto-Unseal #1a: create transit key
On primary Vault cluster:
● Create a transit key unseal-key
vault write -force /transit/keys/unseal-key

23. Transit Auto-Unseal #1b: create policy
On primary Vault cluster:
● Create a transit key unseal-key
● Create a policy use-unseal-key with only
"encrypt/decrypt with unseal-key" capabilities
cat - > policy-file <<EOF
path "/transit/encrypt/unseal-key" { capabilities = ["update"] }
path "/transit/decrypt/unseal-key" { capabilities = ["update"] }
EOF
vault policy write use-unseal-key policy-file

24. Transit Auto-Unseal #1c: create token
On primary Vault cluster:
● Create a transit key unseal-key
● Create a policy use-unseal-key with only
"encrypt/decrypt with unseal-key" capabilities
● Create a token
vault token create -policy=use-unseal-key

25. Transit Auto-Unseal #1d: new cluster
New Vault cluster seal config:
seal "transit" {
address = "$VAULT_ADDR_OF_PRIMARY"
disable_renewal = "false"
key_name = "unseal-key"
mount_path = "transit/"
}
Start and init cluster with $VAULT_TOKEN=token
from 1c. Now you can restart it and it will unseal
itself without your intervention.

26. Demo can be found at
https://github.com/ncabatoff/vault-1.1-webinar
Transit auto-unseal Demo 1

27. Links
This webinar's demos:
https://github.com/ncabatoff/vault-1.1-webinar
Tutorial: OIDC with Auth0:
https://learn.hashicorp.com/vault/operations/oidc-auth
Tutorial: Vault agent caching:
https://learn.hashicorp.com/vault/identity-access-management/agent-caching
Tutorial: Transit Auto-unseal:
https://learn.hashicorp.com/vault/operations/autounseal-transit

28. www.hashicorp.com
ncabatoff@hashicorp.com
Thank you