Project

General

Profile

Vault » History » Version 6

Peter Amstutz, 02/14/2018 05:20 PM

1 1 Peter Amstutz
h1. Vault
2
3 5 Peter Amstutz
Second pass at proposal on how to use Vault from an Arvados container, based on Feb 13 meeting:
4 1 Peter Amstutz
5
* Credentials are entered into Vault
6 5 Peter Amstutz
* Arvados user is granted permission to read/write certain credentials.  Need to determine how this works.
7
** Who can grant it?
8
** How is it represented?
9
** Some ideas: associated with a specific token (like "scopes"); create a new "secrets" table and use permission links
10
** Needs to be carefully engineered so that users can't manipulate policies to claim secrets they shouldn't have access to.
11
* Container, when run, logs into Vault using its container run token
12
* Vault uses Arvados plugin to associate container token with an Arvados user and determine policies
13
* Container queries vault for the credentials it needs
14
* Vault allows/denies query based on polices previously returned by Arvados plugin
15 1 Peter Amstutz
16
Notes:
17
18
* Credentials may be passed in via environment, config file or command line like any other input, so it would be nice to generalize this as a CWL feature where some inputs are simply marked "sensitive" and automatically handled by Vault.  However, while arvados-cwl-runner is responsible for constructing the container request it doesn't run on the compute node, only crunch-run, which is "dumb", so its not clear how we go about allowing for arbitrary substitution into the environment, command line, or config file on the compute node.
19
* Response wrapping is another mechanism provided by Vault for delegating access.  A wrapped response can be passed through and accessed exactly once (would imply max_container_count: 1).
20
* Another solution is to develop an AuthMethod for vault with Arvados Token proivded by the container. 
21 5 Peter Amstutz
22
h2. Vault plugins
23
24
We can implement Arvados authentication as a plugin.  A plugin is a service which is executed by Vault and communicates with Vault over RPC.  Vault provides infrastructure to do this easily in Go.
25
26
https://www.hashicorp.com/blog/building-a-vault-secure-plugin
27
28
Authentication returns a list of Vault policies to apply to the resulting login.  This means policies need to be stored in Arvados (see above discussion).
29
30
If the plugin can return arbitrary policies, this suggests that Arvados theoretically has unlimited ability to grant access to the Vault database.  We should consider how to restrict it to just those secrets / policies intended to be managed by Arvados.
31 6 Peter Amstutz
32
h2. Secrets
33
34
If we add a new "secrets" table we can manage access using our existing permission model.  This means it is managed by the owner, and we can create read/write permission links.  The secrets table would consist of 
35
36
* standard arvados fields: uuid, owner_uuid, etc
37
* the path to the secret in Vault
38
39
The Arvados vault plugin would query Arvados using the token it receives and get back a list of secrets the token is allowed to see.  Ideally we could use token scopes to restrict listing to only returns specific credentials (however, I don't think scopes can currently do this)