It should go without saying that secrets, such as passwords and API keys, should never be committed to any repository hosting services such as Github or GitLab in plaintext.

But how to share secrets with your team and maintain version control?

The old classic: Vault

One solution is to provision a Vault server, which has built-in access control and secrets management.

You can then write scripts to automatically fetch a project's secrets according to the current environment using Vault's API and know that a lot of the work to secure access to those secrets is being done for you.

 Potential drawbacks

However, the drawbacks to this approach are the additional overhead and cost to maintain Vault on a server (most likely on a Kubernetes cluster in the cloud).

For small organisations without a dedicated DevOps team, you also need to have at least one expert on hand to maintain and debug the vault in the event it goes down, or more likely is "sealed".

In fact, every time a node in the cluster is restarted by your cloud provider (which depending on your pricing options, can occur fairly regularly) it will automatically seal the vault and require someone to manually port-forward into the cluster to "unseal" it with the appropriate set of access keys.

Relying on a secrets management system that affects every project when something goes wrong is less than ideal.

SOPS for the win (with caveats 😉)

Mozilla SOPS (short for Secrets OPerationS) is a neat little tool for encrypting files in formats such as YAML, JSON and ENV.

For example, say you have a simple YAML file storing the following secret:

// values.yaml
super: secret

You can encrypt this file by running sops -e -i values.yaml, which will output something like this:

// values.yaml
super: ENC[AES256_GCM,data:PGCefhm7,iv:mjtXDC2EDTbjDurf0qAOS/OaUqgZs9RHAH6cTwjkXvc=,tag:CRtNcAZhOdv7G1tYfBIIOA==,type:str]

You can now keep values.yaml in your code repository in a much more human readable format that works will with version control (and makes git diffs much easier to handle).

In order to decrypt this file, SOPS needs the correct keys.

It pairs well with all the major cloud provider key management services so you can still reap the benefits of controlling access to the required keys to decrypt the files.

You can then rotate keys and create key groups based on which environment you'd like to decrypt the file in.

Pretty hand right?

I've read that this approach does not scale up well, which might be a major drawback for larger teams or projects.

Let me know in the comments if you've worked with SOPS and what your experience with it has been, good or bad!