Every enterprise system has tons of sensitive data like database passwords or third-party API keys. Quite often people store this data openly in internal repositories, continuous integration pipeline or configuration managements systems. The bigger company the stricter security rules. It is more complex and important when you have thousands of different applications and each one has its own secrets. In this talk I am giving an overview of my personal experience on Vault technology and will show by example how you can build your own policies and move your secrets to the Vault.

1. Can you keep a secret?
Moisieienko Valerii
XP Days 2017

2. Who Is This Guy?
• Senior Application Engineer @ Oracle UGBU
• 8+ years in commercial software development
• Oracle Certified Professional
• MapR Certified HBase Developer
• Masters Degree in Information Security

3. Notification
This presentation is based on my personal experience
and does not represent official position of Oracle
company.

4. Everybody Has A Secret
• Database credentials
• Third-party API keys
• License keys
• Sensitive environment variables

5. And How Do We Usually
Keep Them ?
database:
connections:
default:
url: jdbc:mysql://my.db.server:3306/example_service
user: service_user
password: superStrongPassword
apiToken: 8d07b5e9-fbb2-4499-a3c4-053190a78827

6. Private Code Repository
Authentification

7. But No Authorisation

8. The Task
• Reliable secret storage
• Data encryption support
• Flexible user authentication backend
• Authorization
• Convenient interaction for humans and applications

9. Possible Solutions
• HSMs
• Amazon KMS
• Keywhiz
• Conjur
• HashiCorp Vault

10. HashiCorp Vault
• Secure Secret Storage
• Data Encryption
• Access Control
• Pluggable Auth & Storage Backends
• Vault Client & HTTP API

11. Getting Started
• Vault Server
• Secrets
• Policies
• Authentification
• Tokens

12. Vault Server
vault server -dev
vault server -config=
server_config.hcl
export VAULT_ADDR=
'http://127.0.0.1:8200'
storage "mysql" {
username = "vault"
password = "iamvault"
database = "vault"
}
listener "tcp" {
address = "127.0.0.1:8200"
tls_disable = 1
}

13. Secrets
vault write secret/v1/my/secrets <key1>=<value1>
<key2>=<value2> <key3>=<value3>
vault read secret/v1/my/secrets
vault delete secret/v1/my/secrets
vault path-help secret/

14. Policies
vault policy-write
myfirstpolicy policy.hcl
path "secret/*" {
capabilities = ["create"]
}
path "secret/read/only" {
capabilities = ["read"]
}
path "auth/token/lookup-
self" {
capabilities = ["read"]
}

15. Tokens
vault token-create -policy=
<policy_name>
vault auth <token>
vault token-revoke
<token>
token
d5da8c66-1b37-6916-85cc-319
2a135f9a1
token_accessor
ae97c557-e416-8d98-
b815-7394b0d7bcbb
token_duration 768h0m0s
token_renewable true
token_policies [default
myfirstpolicy]

16. Authentification
vault auth-enable github
vault write auth/github/config organization=<github_org>
vault write auth/github/map/teams/default value=default
vault auth -method=github token=<github_token>
vault auth-disable github

17. Vault Integration
• Define secrets
• Create application role
• Create policies
• Provide policy mapping
• Place secrets to Vault
• Adjust application
• Summon

18. Application Role
vault write auth/token/roles/role.service.example-service
allowed_policies="policy.service.example-service"

19. Polices
• Admin policy
• Application policy

20. Admin Policy
example-service-admin.hcl
# Admins can read/write secrets for their service
path "secret/service/example_service/v1/*" {
capabilities = ["create", "read", "update", "delete",
"list"]
}
# Admins can provision tokens for their service
path "auth/token/create/role.service.example-service" {
capabilities = ["create", "update"]
}

21. Application Policy
example-service.hcl
path "secret/service/example_service/v1/*" {
capabilities = ["read", "list"]
}

22. Writing Policies
vault policy-write policy.service.example-service.admin
example-service-admin.hcl
vault policy-write policy.service.example-service
example-service.hcl
# Specific to particular auth backend
vault write auth/github/map/teams/default
value=policy.service.example-service.admin

23. Secrets Go To Vault
vault write secret/service/example_service/v1/
db_properties jdbc.url=<jdbc_url>
jdbc.username=<username> jdbc.password=<password>

24. Application Adjustment

25. Application adjustment
secrets file
DB_URL: !var secret/service/example_service/v1/
db_properties:jdbc.url
DB_USERNAME: !var secret/service/example_service/v1/
db_properties:jdbc.username
DB_PASSWORD: !var secret/service/example_service/v1/
db_properties:jdbc.password

26. Application adjustment
properties file
database:
jdbcUrl: ENV[DB_URL]
user: ENV[DB_USERNAME]
password: ENV[DB_PASSWORD]

27. Application adjustment
Environment Variable Lookup
private static final Pattern SECRETS_PATTERN =
Pattern.compile("ENV[(.*)]");
public String resolvePropertyValue(String value) {
Matcher matcher = SECRETS_PATTERN.matcher(value);
if (matcher.find()) {
return System.getenv(matcher.group(1));
}
else {
return value;
}
}

28. Summon
• Install
brew tap conjurinc/tools
brew install summon
• Vault Provider
mv summon-vault /usr/local/lib/summon/
chmod 755 /usr/local/lib/summon/summon-vault
• Check
VAULT_TOKEN=<TOKEN> summon --provider summon-vault -f
secrets.yml ruby -e 'puts ENV["DB_URL"]'

29. Integration Demo

30. Pros And Cons
+ Easy setup
+ Master key sharing
+ Pluggable storage and auth backends
+ Straight forward policy control
+ Provides client and HTTP API
- Application integration
- Token renewal mechanism

31. Thank you!
You are welcome to write me at
valeramoiseenko@gmail.com
GitHub
https://github.com/moisieienko-valerii/vault-dropwizard