Skip to content

executors: Secret values

Created by: eseliger

Description

At some point we need to allow a way for users to inject secrets into their SSBC executions without adding them to the batch spec inputs directly.

I think we could do something like ${{ secret.XX }} in templating and support setting those from the UI in a secrets menu.

My current plan is to

  • add a table storing executor secrets pretty generally (scope, user, org, key, value, enc_key)
  • add a batch changes UI in admin, org settings and user settings each to configure those, showing when it’s overwriting a global default (batch changes UI and not generalized, because batch changes ownership of a job works differently than code intel, but we can clone the admin page version of it for code intel easily, I still want to use a generic backend)
  • say the transformer methods would need to figure out what secrets are required (is domain logic, batch changes would require parsing the spec file, code intel might look for defaults or similar, ..) and send them however the jobs need them, and make sure they are added to redacted values
  • add 2 special docker secrets can be used to configure the docker login/pass (this would be v0.1, it won’t support multiple credentials but I think it applies broadly enough for BC and CI for now)

For the batches transformer, this would mean parsing the batch spec to find ${{ secrets. }} values and looking for docker secrets to pass along as well.

Additional plans:

  • Add audit logs when secrets are being loaded
  • UI should allow to both update the value and delete it, updating the updated_at timestamp

TBD: Should we allow to specify one-off secret values? This would make it very easy to use a secret in a batch change, but also make it impossible to ever run it again (think recurring batch changes, ..)

Impacted customers

Our use case is to update the version of a certain npm package in about 50 repositories in a single batch change. To do that, we need to be able to install private npm packages after cloning a repository (during the batch change execution).To be able to install these private npm packages, we need to add a way to authenticate against the npm registry. Currently in our CI environments we create an .npmrc file (that is used for authenticating against npm) and inject the access token into it from an environment variable These other CI environments, we are allowed to pass arbitrary environment variables after setting them in the web UI, that’s what we would like to have in batch changes 🙂 What would be even better is the ability to hide these environment variables, so after they are set they cannot be read from the Web UI anymore, only by the batch change executor(s).

The customer would like to use server side Batch Changes. However, they must use secrets to open and assign JIRA tickets to repository owners. The customer would like to store secrets to use as environment variables in batch changes. Including the credentials of the batch change executor.