Vault » History » Revision 5
Revision 4 (Nico César, 02/14/2018 03:33 PM) → Revision 5/12 (Peter Amstutz, 02/14/2018 05:09 PM)
h1. Vault Second pass at Going through the docs, a strawman proposal on how to use Vault from an Arvados container, based on Feb 13 meeting: container: * Credentials are entered into Vault * Arvados user is granted permission to read/write certain credentials. Need to determine how this works. ** Who can grant it? ** How is it represented? ** Some ideas: associated with Client (arvados-cwl-runner?) generates a specific Vault token (like "scopes"); create a new "secrets" table and use permission links with restricted policy (can only read credentials) ** Needs * Container request is expanded to be carefully engineered so that users can't manipulate policies to claim secrets they shouldn't have access to. include Vault token * Container, when run, logs into Vault using its token cannot be read back from container run token request via API * Vault uses Arvados plugin to associate Cannot have container token reuse with an Arvados user and determine policies Vault tokens * Container queries On the compute node, read the container record * The container record only includes the vault for token when queried by the credentials it needs container run token. * The container can now read the secret at the path provided in the input * When the container request is finalized, the Vault allows/denies query based on polices previously returned by Arvados plugin token is revoked. Notes: * 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. * 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). * Another solution is to develop an AuthMethod for vault with Arvados Token proivded by the container. h2. Vault plugins 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. https://www.hashicorp.com/blog/building-a-vault-secure-plugin 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). 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.