Problem

Currently users have to store the secrets in the NFS home directory, making it easy to leak (just forget to chmod) and hard to track. This also binds our users to NFS (instead of being agnostic from the implementation).

We want a way for users to create the secrets and not have to care where are they stored, if they set the right permissions and abstracted enough for us to be able to change the implementation with minimal impact on the users.

Original task: T334578: [toolforge] Create a secrets management offering to avoid storing on NFS

Constraints and risks

• If it's too complicated users might have a hard time using it
• If we leak implementation details, we might lose the ability to change the implementation

Decision record

https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T335979_Decision_request_-_Toolforge_envvars/secrets_service

Options

Option 1

Have a secrets cli (and API) that allows setting secrets as environment variables and files mounted in the filesystem the app runs on (similar to what k8s secrets offers).

Pros:

• Things like certificates are easier to think about (file vs reading it from an env var)

Cons:

• A bit more complex to implement (two features)
• Risk of having users uploading non-secret files as secrets (ex. settings.py)
• No explicit envvars offering (a bit out of scope, but a nice plus)
• If users get used to using secrets for envvars, might difficult implementing envvars in a different way in the future (as users will have to explicitly

Option 2

Have an envvar cli (and API) that allows setting environment variables for the app environment, that would be a superset as env vars would be secrets and not secrets (no specific cli for secrets).

Pros:

• Promotes having only secret things as env vars have size limits
• Simpler implementation

Cons:

• A bit confusing if it is secret or not
• Makes managing things like certificates a bit harder (as there's no file support)
• If users get used to using envvar for secrets, might difficult implementing secrets in a different way (as users will have to explicitly migrate)

Option 3

Have a secrets cli and an envvar cli that allow setting environment variables for the app envirnoment, for starters one being just an alias of the other.

Pros:

• Promotes having only secret things as env vars have size limits
• Simpler implementation
• Though they are the same, it makes clear that secrets are supported, and envvars are supported, without mixing them (from the user's point of view)
• Easy to evolve each offering, allowing splitting the implementation with little user work

Cons:

• Makes managing things like certificates a bit harder (as there's no file support)

Option 4

Please add anything else you deem relevant!