Sops

Last updated: Jul 1, 2026

---

Rationale

Sops is the tool we use for managing most of our organizational secrets, like passwords, access keys, and 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:

• It is open-source.
• It is Serverless, meaning that it does not require maintaining servers, firewalls, load balancers, or any other typical infrastructure required for common Secrets Engines.
• It supports AWS KMS, which allows us 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.
• It is free. Only costs for decrypting secret files using AWS KMS are incurred.
• As secrets are written as code, it allows software versioning, as encrypted secret files can be securely pushed to git repositories.
• It allows reproducibility and auditability as secrets are versioned.
• It is DevOps-friendly, as secret management is now done through Merge Requests, allowing us to run CI/CD integrations on the secrets.
• Although secret KMS keys are very easy to rotate, Sops does not support secret-specific automatic rotations.
• It integrates with other services like PGP, Age, GCP KMS, Azure Key Vault, and Hashicorp Vault.
• It supports YAML, JSON, Env, INI and Binary formats.

This decision was revisited in 2026 (ADR #25531) against AWS Secrets Manager and Infisical Cloud, prompted by rotation friction and the growth of LLM-driven agents. A proof of concept reaffirmed Sops. Both alternatives put a live service on the secret read path, coupling application availability to it, whereas Sops resolves secrets at deploy time inside GitLab CI/CD with no runtime dependency. Their headline features did not materialize for our workloads either: most apps load all secrets at startup through third-party libraries that read environment variables at their own initialization, so per-read audit collapses to a single bulk read at boot and rotation still propagates only on redeploy. The rotation friction that motivated the revisit is better addressed within the Sops model, for example through a dedicated rotation pipeline and rotation-automation opportunities.

Alternatives

The following alternatives were considered but not chosen:

AWS Secrets Manager

• AWS Secrets Manager is not open-source.
• It is a managed AWS service, meaning that infrastructure complexity is handled by them.
• It encrypts secrets with AWS KMS customer-managed keys in our own accounts by default, the same encryption boundary as Sops today.
• Access is pure AWS IAM (secretsmanager:GetSecretValue on the secret ARN), with no second identity layer to maintain.
• Audit is unified in CloudTrail (a per-GetSecretValue event), where our other AWS audit events already live.
• It charges per secret ($0.40/secret/month plus $0.05 per 10,000 API calls), so the total depends on how entries are packaged into secrets (roughly $20 to $136/mo across our inventory).
• It is a common Secrets Engine, meaning that secrets are not stored as code, losing Git versioning. It supports its own versioning.
• It integrates natively with the AWS compute we run (AWS Batch job definitions, Lambda, and EKS via the Secrets Store CSI Driver), though this is a separate read path from cloning the repository.
• It supports automatic rotation, but our SaaS providers (e.g., Auth0) have no managed integration and would each need a custom Lambda rotation function.
• It has no built-in multi-party approval workflow or non-engineer UI for rotation; both would be real engineering work.

HashiCorp Vault

• Vault is open-source.
• It is SaaS, meaning that infrastructure complexity is handled by them.
• It supports external key management systems like AWS KMS and GCP KMS.
• It charges based on secrets.
• It is a common Secrets Engine, meaning that secrets are not stored as code, losing git versioning. It supports its own versioning.
• It should support auditability and reproducibility as it has its own versioning.
• It is a service that must be managed separately, making integration with DevOps flows harder.
• It supports automatic rotation for some services that are not relevant to us.
• It integrates with Datadog.
• It does not support any text format, but instead is configurable via the GUI.

Infisical

• Infisical is open-source, available as a managed cloud or self-hosted on our own infrastructure.
• It authenticates machine identities against AWS IAM (via STS identity verification), and its Kubernetes Operator can sync secrets into native K8s Secrets.
• Bring-your-own-key with an external KMS is gated to the Enterprise edition; on the Pro tier the encryption-at-rest key is Infisical-managed in their database, a change from the current "AWS KMS in our accounts" boundary.
• It charges per identity (humans and machines that talk to it), which scales poorly for a horizontal system like ours (roughly $720 to $1,800/mo depending on how finely we scope machine identities).
• It is a common Secrets Engine, meaning that secrets are not stored as code, losing Git versioning. It supports its own versioning.
• The managed cloud adds a third-party dependency to the production read path; self-hosting removes that but puts the service (RDS, Redis, upgrades, backups, on-call) on the team's operational portfolio.
• It has a built-in, configurable multi-party approval workflow, secret reminders, and native rotation integrations for some providers (notably Auth0).
• Its project-role layer and audit log are separate surfaces from AWS IAM and CloudTrail to keep in sync.

Torus

• Torus was used a few years ago, but it got discontinued. One year later, they relaunched their service. It is not open-source.
• It is SaaS, meaning that infrastructure complexity is handled by them.
• It does not support any external key management service.
• It does not publish its prices.
• It is a common Secrets Engine, meaning that secrets are not stored as code, losing versioning.
• It does not support auditability and reproducibility, as there is no versioning.
• It is a service that must be managed separately, making integration with DevOps flows harder.
• It does not seem to support automatic rotations.
• It does not integrate with any other services.
• It does not support any text format, but instead is configurable via the GUI.

CyberArk Secretless Broker

• CyberArk Secretless Broker is yet another solution that involves secure brokers. It is open-source.
• It forces us to maintain the entire service on our Kubernetes cluster and deploy sidecar agents to generate trust relationships.
• It does not support any external key management service.
• It is free. No costs appear to be incurred.
• It is a common Secrets Engine, meaning that secrets are not stored as code, losing versioning.
• It does not support auditability and reproducibility as there is no versioning.
• It is a service that must be managed separately, making integration with DevOps flows harder.
• It only supports automatic rotations for MySQL and PostgreSQL, meaning that manual rotation is still needed.
• It only integrates with other CyberArk services like CyberArk Conjur.
• It does not support any text format, but instead is configurable via CLI.

Usage

Used for managing most of our organizational secrets within the Universe repository.

We use GitLab CI/CD Variables over Sops for:

• Exporting Cachix authorization tokens as Nix requires them to be available prior to Sops initialization.
• Exporting environment variables required by containers that do not support Sops.