Sops

Rationale

Sops is the tool we use for managing most of our organizational secrets like passwords, access keys, PII, among others. It allows us to version encrypted files within our Git repositories in a stateless approach.

The main reasons why we chose it over other alternatives are:

1. It is Open source.
2. it is Serverless, meaning that it does not require maintaining servers, firewalls, load balancers, or any other typical infrastructure required for common Secrets Engines.
3. It supports AWS KMS, which allows to encrypt files using symmetric AES256 keys that only exist within the KMS boundaries, granting almost-impossible key leakage. Access to such keys can be easily managed with a user-level granularity by using AWS IAM.
4. It is free. Only costs for decrypting secret files using AWS KMS are incurred.
5. As secrets are written as code, it allows software versioning, as encrypted secret files can be securely pushed to git repositories.
6. It allows reproducibility and auditability as secrets are versioned.
7. It is DevOps friendly, as secret management is now done through Merge Requests, allowing to run CI/CD integrations on the secrets.
8. Secret's KMS keys are very easy to rotate.
9. It integrates with other services like PGP, Age, GCP KMS, Azure Key Vault, and Hashicorp Vault.
10. It supports Yaml, Json, Env, Ini and Binary formats.

Alternatives

The following alternatives were considered but not chosen for the following reasons:

1. AWS Secrets Manager: They charge on a per-secret basis. It is a common Secrets Engine, meaning that secrets are not stored as code, losing versioning, auditability, automation and reproducibility capabilities.
2. HashiCorp Vault: It did not have a SaaS solution at the time we tried it. We had to maintain the entire service on our Kubernetes cluster. It is a common Secrets Engine, meaning that secrets are not stored as code, losing versioning, auditability, automation and reproducibility capabilities.
3. Torus: We used it a few years ago but it got discontinued. One year later they relaunched their service. It is a common Secrets Engine, meaning that secrets are not stored as code, losing versioning, auditability, automation and reproducibility capabilities.

Usage

Used for managing most of our organizational secrets. Some examples are:

1. Airs.
2. Platform.
3. Docs.
4. Makes.
5. Okta.

We do not use Sops for:

1. GitLab CI/CD Variables: Although most of the secrets contained here were already migrated, there are still some that need review.
2. Automatic secret rotation: As Sops secrets are versioned, automatically rotating them would require to directly push automated commits to our main branches. We have declined to do this until today mainly due to consistency and stability concerns. Secrets that require automatic rotation are kept within our GitLab CI/CD Variables.

Guidelines

1. You can install Sops with nix-env -i sops.
2. In order to be able to decrypt a secrets file, first you must assume an IAM role with access to the KMS key that encrypted it. You can follow this guide to do so.
3. Once authenticated with a role, you can decrypt a file with sops <file>.
4. You can encrypt a plain file with sops -ei --kms <kms-arn> <file>.