This document discusses how to retrofit applications to use Vault for secret management. It describes options for authenticating applications to Vault such as using approle authentication where the application is given a role ID and single-use secret ID. It also discusses tools like Vault Agent and Consul Template that can help retrieve secrets from Vault and make them available to applications. The document emphasizes best practices for secure introduction such as short token lifetimes and limiting exposure of authentication secrets.

2. Copyright © 2020 HashiCorp
Keeping a Secret
Retrofitting applications to use Vault

3. Nick Cabatoff
Vault software engineer at HashiCorp

4. Why do
secrets
matter?
▪ Data breaches are a routine occurrence these
days.
▪ These can result in lawsuits and fines (GDPR) for
the breachee.
▪ Victims whose personal information was stolen
face privacy loss & identity theft.
▪ Securing your secrets can prevent or limit scope of
breaches.

5. Harm:
Unauthorized data access,
identity spoofing, private data
egress, fines
Secret:
Something that would increase
your risk if someone else got it
Secret vs.
sensitive data:
▪ Secret: used for auth
▪ Sensitive: confidential
What’s a secret?

6. How do you
keep a
secret?
Forget about computers for now.
What best practices should a person follow
to keep a secret?

7. Keep track of who
you told
Tell as few people
as possible
Try not to have long-
term secrets
What’s a secret?

8. How does Vault help you keep a secret?
▪ Centralized secrets
▪ Identity-based authentication
▪ Automated secret rotation
▪ Audit Logs

9. All consumers of Vault secrets must solve
two problems:
1. Authentication to Vault
2. Retrieval of secrets
– At startup
– When secret expires or is rotated
Onboarding
applications

10. Vault Authentication /
Secure Introduction

11. How can app prove to Vault who it is without
storing a secret outside of Vault?
▪ Running in Nomad or Kubernetes? Scheduler can vouch
for app.
▪ Running in a cloud? Cloud IAM service can identify app.
If none of the above? This talk is for you.
We may have to store a secret outside of Vault, but we can
mitigate the risks.
Secure
Introduction

12. 1. Don't let authentication secrets live forever
2. Distribute auth secrets securely
3. Limit exposure if auth secrets disclosed
4. Have a break-glass procedure if auth secret stolen
5. Detect unauthorized access to auth secrets
Secure
Introduction
Best practices

13. Secure Introduction
Best practices
1. Don't let secrets live forever Limited uses, short ttl
2. Distribute secrets securely
3. Limit exposure: Use principle of least privilege in
your roles
4. Break-glass procedure: Use audit log and revoke API
5. Detect unauthorized access: App should alert if secret absent/no good

14. Options:
1. Deploy Vault token alongside app
2. Deploy approle roleid/secretid alongside app
3. Deploy TLS client certificates and use cert auth method
Secure
Introduction
On premise,
no scheduler

15. Option 1: Distributing tokens
One reason you might want to do this instead of using approle: it makes it easy
to use envconsul or consul-template
If distributing tokens directly:
▪ use a token role, similar to what we do with approle roles
▪ distribute single-use token with a short TTL
▪ use response wrapping to embed another longer-lived token

16. Option 2: Approle Authentication
Setup
vault auth enable approle
vault write auth/approle/role/myrole token_policies="myapp" token_ttl=1h
vault read -field=role_id auth/approle/role/myrole/role-id > role-id
vault write -f -field=secret_id auth/approle/role/myrole/secret-id > secret-id
Administrator
Deployer

17. Approle Authentication
Application Login
$ grep . role-id secret-id
role-id:4bdd6e8e-47e5-5d6f-c698-397a373c9c56
secret-id:6490149e-aa11-2cb1-f4ae-b2f9da824a62
$ vault write auth/approle/login role_id=$(cat role-id) secret_id=$(cat secret-id)
Key Value
--- -----
token s.pstokYLHuv3rBGrb7zHVCF6l
token_duration 1h
policies ["default" "myapp"]

18. Approle vs Userpass Authentication
Isn't role_id just a username and secret_id a password?
Differences between approle and userpass:
▪ approle can have multiple secret_ids for each role
– give each app a role, each app instance a secret_id
▪ secret_ids can be bound to specific CIDRs
▪ secret_ids can have TTLs and limited uses

19. Approle workflow example

20. Getting Vault Secrets into
Application Memory

21. ▪ Unrealistic to require every secrets-using app speak
directly to Vault
▪ Another option: use a helper like Vault Agent, consul-
template, envconsul
Onboarding
applications
Retrofit or helper?

22. Helper supervisors
envconsul, consul-template
Two supervisor-style tools to retrofit Vault integration into your apps:
envconsul: Query Vault, put secret in env variables of your application
consul-template: Query Vault, put secret in config files of your application
Both:
▪ Require a Vault token
▪ Poll Vault, restart app when secret changes (consul-template can also signal instead of restart)

23. Vault Agent auto-auth + template
Vault agent is just a mode of regular Vault binary:
vault agent
Agent uses auto-auth to get a token, e.g. approle login using role_id+secret_id
Agent template feature writes secrets to file(s) read by your app
Configure a kill command to signal your app whenever template rendered
Note: not a supervisor like envconsul/consul-template

24. ▪ Define an approle role with appropriate privileges,
restrictions
▪ Bundle Vault Agent and role_id along with your app
▪ Deliver single-use secret_id with short TTL to your
app/Agent
▪ Agent authenticates with role_id, secret_id
▪ Agent renders secrets via template, signals your app
▪ App reads rendered template, alerts if secrets
missing/unuseable
Review
Approle

25. Resources
▪ Talk: Think Like A Vault Developer: Secure Introduction at Scale
▪ Blog: Authenticating Applications with Vault Approle
▪ Learn: AppRole With Terraform & Chef
▪ Learn: Secure Introduction of Vault Clients

26. Thank You!
26