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. Infisical: It was not a distributed tool like Sops, meaning that it represented a single point of failure. It generated friction as traceability existed outside of the Git repository and forced us to duplicate our AWS authorization model for it to work. It did not support triggering CI/CD pipelines on secret rotations, potentially impacting stability. It was more expensive than Sops as it's pricing model was based on users instead of AWS KMS keys usage. It provided automatic secret rotation for a few tools at the expense of not being able to test if such rotations worked.
4. 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. Makes
4. 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.