Configure Auto DevOps app secrets outside the repo
Problem to solve
Currently, there is no way to make secrets available to an auto devops application running in a k8s cluster.
For example I may need to configure my rails application to have some secret API token for a 3rd party email sending service. I would prefer not to commit this secret to the repo as this violates 12 factor principles as well as probably violates some security best practices.
Maybe phrased as a user user story:
As an operator I'd like to be able to configure a deployed application with secret variables without this being visible to developers that write the code.
Possibly we need a new interface for this or maybe we can leverage our CI secret variables.
Update documentation to reflect new prefixed variable option and link within the UI. Prefix with
Update descriptive text within the UI:
Variables are applied to environments via the runner. They can be protected by only exposing them to protected branches or tags. You can use variables for things like passwords, secret keys, or credentials. You may also add variables that are made available to the running application. More information
- In CI we ensure the variables with the relevant prefix name are passed to the running app as env vars with the prefix stripped off
Previous Proposal 01
Leveraging existing variables (project settings >> CI/CD >> variables) allow user to define these variables in a new section, where the variables are only to be used for app running in the cluster (the auto devops app).
We store these new variables in a new model in our backend (really simple new table)
When created we create the
We pass a new variable to CI jobs called
APP_SECRETSwhich is a comma separated list of the variables (names only) that need to be mounted in the helm chart
Only variables defined in the new section would be passed to the application running in the cluster.
Previous Proposal 02
These can then be configured for the application in a couple of ways:
What does success look like, and how can we measure that?
(If no way to measure success, link to an issue that will implement a way to measure this)
Links / references
/label feature proposal