Change Details

== 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. === 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 == In progress https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T302593_How_do_we_make_decisions == 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!

== 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} === 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 == In progress https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T302593_How_do_we_make_decisions == 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!

== 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} === 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 == In progress https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T302593_How_do_we_make_decisions == 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!