Manage secret encryption using sops

[sgibson91]

Using git-crypt would be easier for local development a la mybinder.org-deploy. Docs: https://github.com/AGWA/git-crypt

Instead of git-crypt, let's look at using sops

[sgibson91]

Pros:

• Use only one CI vendor (e.g. GitHub Actions and store git-crypt secret as a repo secret)
• Easier for local deployment (no need to fill out the template)
• Would simplify the CD pipeline - no reliance on a keyvault or sed templating

[sgibson91]

https://github.com/mozilla/sops

Pros of sops over git-crypt:

• sops is a bit more clever about encryption that git-crypt. Instead of just turning the whole file into an encrypted binary, it only encrypts the values, leaving the keys untouched (assuming the file you are encrypting is a key:value-pair type such as JSON and YAML). This leaves the file in a much more human-understandable state without leaking sensitive info.

Steps to be taken:

• Create a central place to store sops key(s)
  • Azure key vault makes most sense. I'd recommend deploying a new one that appropriate folks have access rights to.
• Generate a sops key and store it to new Azure key vault
• Create a secrets directory (.gitignore may need editing) and .sops.yaml config file in the root of the project
• Extract secrets from old Azure key vault (and then decommission it)
• Move deploy/prod-template.yaml to secrets/prod.yaml, substitute in secrets from old key vault, encrypt using sops and then commit the file change
• Update .az-pipelines/cd-pipeline.yml to use sops and updated config files, granting access to new key vault where appropriate