Project

General

Profile

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.)