1543991 - Support checking in secrets to version-control-tools

Status: RESOLVED FIXED

(Developer Services :: Mercurial: hg.mozilla.org, enhancement)

Description

[Connor Sheehan [:sheehan]]

Our current configuration of hg.mozilla.org is split between public code (checked in to version-control-tools) and private code (kept in a private IT puppet repo). As we expand hg.mo out of our on-premises hardware and into the cloud, maintaining configurations across multiple teams using different tools will become more and more difficult. I'm already running in to this issue as I attempt to point our InfluxDB monitoring data at the production instance, as we need to reference a secret username and password from within our configs.

I'd like to add the ability to commit secrets to version-control-tools with sops, using a Google Cloud cryptographic key to provide the encryption. Anyone who needs to perform deployments to hg.mozilla.org would need to be given appropriate permissions to access the key in the hgmo GCE project. They would then install the GCE SDK, and run the necessary sops setup to confirm everything works as intended. When secrets need to be checked in, they would use the sops command line to encrypt them first, and then perform the check in. We would also add a step to decrypt the files automatically as part of the deployment process, via the ./deploy script.

Comment 1

[Kim Moir [:kmoir] ET]

Connor does this need any feedback from the security team on this approach? (RRA update)

Comment 2

[Connor Sheehan [:sheehan]]

(In reply to Kim Moir [:kmoir] ET from comment #1)

Connor does this need any feedback from the security team on this approach? (RRA update)

I don't think there's any major issue here, considering sops is a Mozilla tool and the secrets I want to check in aren't that critical (although that could change down the line). But it doesn't hurt to ask!

Hal, do you see any issue with the above proposal?

Comment 3

[Connor Sheehan [:sheehan]]

Apparently Hal is on PTO.

Simon, do you have any thoughts/objections to the plans laid out in this bug?

Comment 4

[Connor Sheehan [:sheehan]]

Attachment: meta: add `.sops.yaml` and basic documentation for working with `sops` (Bug 1543991) r?lars

As described in the bug, we would like to be able to check in secrets
to version-control-tools for a variety of reasons. This commit
introduces a .sops.yaml file and a brief introduction to using
sops to encrypt configuration secrets checked in to version control.

For the moment, all secrets in this repo are encrypted with a single
GCP KMS key. The recommended practice is to also encrypt with a
backup PGP key that is kept somewhere offline (like a safe in an
office) for backup purposes. Considering the nature of the items
I want to place in the repo, I don't think we should block on doing
that for now.

Comment 5

[Connor Sheehan [:sheehan]]

Attachment: deployments: teach `./deploy` to decrypt secrets with `sops` (Bug 1543991) r?lars

Now that we can use sops to encrypt/decrypt secrets in
version-control-tools, we need to automate the process
of decrypting these secrets when we want to deploy them
to the service. This commit adds a step to the ./deploy
tool which parses the .sops.yaml file for a files key,
inside which is a list of files which need to be decrypted
in-place before running through the deployment.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/hgcustom/version-control-tools/rev/490b53dde5c0
meta: add `.sops.yaml` and basic documentation for working with `sops` r=lars
https://hg.mozilla.org/hgcustom/version-control-tools/rev/d4bea7482af0
deployments: teach `./deploy` to decrypt secrets with `sops` r=lars

Comment 7

[Connor Sheehan [:sheehan]]

Clearing ni? since I went ahead and added this capability.