Global Secrets Management

[Ardiea]

Description/Context

secret-operations is a .... disaster. We need a managed space for our secrets that are shared between applications / stacks / whatever.

Plan/Design

• Create a substructure stack that makes a kv2 vault mount and populates it with various keys / data structures that will be shared between applications.
• Pick a few small apps / stacks and migrate them
  • That means tracking down the existing values in secret-operations and ensuring they get populated into the new mount via pulumi code.
  • Update the application stacks to retrieve secrets from the new mount and not the old mount.
  • Make sure to update the .hcl files for the stacks so they have permission to access the new mount.

Questions

• What, if anything should be exported from the substructure stack? Maybe paths to the root keys / groups
• Root keys / groups. Come up with a sane orgnaizsation system for the root keys /objects /paths in the new vault mount and make sure it is sane with the rest of the team.

[shaidar]

Went through the secret-operations mount and below are my findings:

• secrets that a bunch of apps needs access to
• secrets that specific apps need access to - edxapp, heroku apps
• apps that don't have their own mount - vector - creds specified in sops

I suggest we create a new v2 mount with the following structure: secrets-global

• odl_wildcard_cert
• mailgun-api-key
• mit-smtp
• edxapp
  • github-enterprise-ssh
• heroku
  • mitx-devops-api-key
  • odl-devops-api-key

And then move the other secrets to their own mounts, ex: OVS

• cloudfront-private-key

Dagster

• institutional-research-bigquery-service-account

[shaidar]

@blarghmatey Now that the mount and a sample app (bootcamps) is complete, should we go ahead and close this issue and open separate issue to update pillar for the individual apps?

[blarghmatey]

Yes, I think it makes sense to have an issue per app so that we can pick it off opportunistically.