Credential storage » History » Version 1
Peter Amstutz, 06/14/2024 06:55 PM
1 | 1 | Peter Amstutz | h1. Credential storage |
---|---|---|---|
2 | |||
3 | h2. Background |
||
4 | |||
5 | In order to implement [[Objects as pseudo-blocks in Keep]], we need a way to store credentials so that Arvados can authenticate to other systems, e.g. AWS S3. |
||
6 | |||
7 | The current system for managing secrets is specific to workflows and deletes the secret as soon as the workflow is finished. However, we require a credential storage system that can be accessed by keepstore. |
||
8 | |||
9 | User perspective: |
||
10 | |||
11 | Want to be able to manage credentials in workbench, and then Arvados services that need it can look it them up. The motivating use case is AWS credentials that have a key id/key secret pair (much like arvados API key uuid / secret) so that we can easily access objects in external S3 buckets. |
||
12 | |||
13 | h2. Requirements |
||
14 | |||
15 | * Secrets should have an id for what type of thing they are, e.g. AWS credentials |
||
16 | * Secrets should have an optional scope. E.g. want to be able to provide different credentials for different resources, buckets, etc. |
||
17 | * Should the secret material itself be simple text column or a JSON object? For example AWS secret id/secret is a pair |
||
18 | * Different users should have different views of what secrets are available based on Arvados permissions. User should be able to share secrets at different levels of access, e.g. |
||
19 | ** can_read -- system services can fetch the credential on behalf of the user, but they cannot fetch it directly through the API |
||
20 | ** can_write -- user can update the credential, but still not read it back |
||
21 | ** can_manage -- user can grant permissions to the credential, but still not read it back |
||
22 | * Secrets should be write-only as much as possible, system services can retrieve secrets, but users cannot except in special circumstances (but want a way to use secrets in workflows, which means they can be exposed if developers are careless, this is true of our current secrets support as well.) |