Let's see how we can leverage on Vault capabilities to create a self-service system inside your company

1. Martin Conraux
Identity Management @Criteo
Twitter: @uepoch
Github: uepoch
Vault x Self-service

2. 2 •
SRE @ Identity management Team since a year and a half
Principal maintainer of the Vault infrastructure
Trying to get paid patching software and writing code
Love: writing useless prompts with ncurse
Hate: writing useful documentation
Me

3. Introduction

4. 4 •
• Team is 3 years old
• 4 engineers
• SDKs development (JWT/LDAP)
• Responsible for:
• Authentication technologies (SSO, LDAP, Kerberos,….)
• Authorization services
• Secrets (Hello Vault!)
• Users management (services, humans, groups,..)
• Handling all our infrastructure: 24/24h 7/7d on-call
• Using Vault for a year
Identity Management Team

5. 5 •
Application needs
MyApp
Kerberos
JWT
Other apps
Databases
Accounts
Regular secrets
API keys, …

6. 6 •
• Service accounts are created by a script ran by hand
• Features can take up to a few weeks to be ready
• Hadoop credentials can take up to a few weeks
• Kerberos credentials can take 1-3 days
• JWT keys are deployed fast to Mesos, but takes a few days on Windows
• Regular secrets are at the discretion of the application, stored in encrypted config blobs
Provisioning not so long ago

7. 7 •
Checkpoint 1: One password, One DB, One App
MyApp1 PasswordDB1 DB1

8. 8 •
Checkpoint 1: Bob gives the DB1 password to App2
MyApp1 PasswordDB1 DB1
MyApp2 PasswordDB1 DB1

9. 9 •
Checkpoint 1: App1 needs to access DB2
MyApp1 PasswordDB1 DB1+DB2
MyApp2 PasswordDB1 DB1+DB2

10. 10 •
650+
Engineers
3K
Different services on
Consul
> 32K
Servers
>150 PB
Hadoop cluster size
NUMBERS @ Criteo

11. 11 •
Checkpoint 1: One year later

12. 12 •
Automation

13. 13 •
Automation: Identity creation
• Humans are imported from HR databases into a LDAP
• They are grouped based on their department, role in the company, …
• Services creation request is made painless and automated via a nice GUI

14. 14 •
Automation: Resource creation
• Scan for available DBs, create:
• New ro/rw accounts on DB side, store the password in Vault
• Create groups to access the DB
• Scan all users (services + humans), create:
• Kerberos credentials
• Consul tokens
• API Keys
• Self-usage DB
• ...

15. 15 •
Automation: Authorization with Vault templated Policies
• User `myapp` automatically gets access to:
• Services/accounts/<myapp> with the password
• DB/creds/<myapp>DB with access to your application DB (microservices ftw!)
• Consul/creds/<myapp> returning you a short-lived token for service myapp
• ….
• Compute individual permissions to users to match resource access groups
• If user is part of group-DB1-RW, user gets access to DB1 creds

16. 16 •
Checkpoint 2: MyApp now is independent
MyApp1 MyApp1Passwd DB1
MyApp2 MyApp2Passwd DB2

17. 17 •
Checkpoint 2: MyApp1 still need to access DB2
MyApp1
MyDB1Passwd
MyDB2Passwd
DB1
DB2
MyApp2 MyDB2Passwd DB2
ACLs

18. 18 •
Checkpoint 2: Where are we ?
• We have automated creation of our identities
• We have our resources access automatically provisioned in Vault
• We have the basic glue between our organization and the permissions

19. Identity Backend
One backend to auth them all

20. 20 •
• Vault supports multiple authentication methods
• Identity engine internally maintains the clients who are recognized by Vault.
• It handles entities, aliases and groups
• It aggregates your independent identities into one logical set of permissions
Learning: https://learn.hashicorp.com/vault/identity-access-management/iam-identity
Great presentation: https://www.youtube.com/watch?v=qsyVIAOA8ng
What is the Identity backend

21. 21 •
• Entities are the logical representation of your users; they are composed of aliases and
members of groups.
• Aliases are the physical link between your external auth system and Vault
• User uepoch on github, uid=m.conraux inside our HR DB,….
• Groups are either pure internal or linked with their equal in a supported auth backend.
• Github's organizations, LDAP groups, ….
What is the Identity backend

22. 22 •
• Using Vault as the agnostic datastore for secrets has two major challenges:
• All applications must be able to authenticate in Vault
• You should have access to all your secrets
• Vault supports many auth methods, and plugins ! (chef, kerberos, …)
• But a JWT token doesn't contain my groups :(
• Identity backend let you share permissions between aliases, by merging them at the entity
level
• All your apps/users have their full rights, regardless of the auth method
What are the pros/cons of virtualizing authorization

23. 23 •
• Vault supports dynamic secrets: No more password leaks !
• Since each instance uses a unique set of creds, easier troubleshooting for free
• Transit backend let your users have access to a powerful static encryption tool
• Free of charge unique KV for everyone !
• It's easy to affect hierarchical permissions, letting MyApp admins use the same paths
Bonus Features in Vault

24. Thanks ! Q&A
Btw, we're hiring.