Sops

Last updated: Oct 28, 2026

---

Rationale

Fluid Attacks uses Sops to manage most of its organizational secrets, for example, passwords, access keys, and PII. With it, Fluid Attacks can keep versions of encrypted files in its Git repositories with a stateless approach.

These are the primary reasons why Fluid Attacks selected it and not other alternatives:

• It is open-source.
• It is Serverless. Thus, it is not necessary to maintain servers, firewalls, load balancers, or other usual infrastructure that common Secrets Engines must have.
• It supports AWS KMS. Thus, Fluid Attacks can encrypt files with symmetric AES256 keys that are only inside the KMS boundaries, and a key leak is almost impossible. You can easily manage the access to these keys for each user with AWS IAM.
• It is free. Fluid Attacks pays only to decrypt secret files with AWS KMS.
• Secrets are written as code. Thus, it supports software versioning, because you can safely push encrypted secret files to Git repositories.
• Because secrets have versions, it gives reproducibility and auditability.
• It is DevOps-friendly. Fluid Attacks manages secrets through Merge Requests. Thus, it can run CI/CD integrations on the secrets.
• Secret KMS keys are very easy to rotate, but Sops does not support automatic rotation for each secret.
• It integrates with other services, for example, PGP, Age, GCP KMS, Azure Key Vault, and Hashicorp Vault.
• It supports the YAML, JSON, Env, INI, and Binary formats.

In 2026, Fluid Attacks examined this decision again (ADR #25531) and compared Sops with AWS Secrets Manager and Infisical Cloud. The causes were rotation friction and the increase of LLM agents. A proof of concept confirmed Sops again. The two alternatives put a live service on the path that reads secrets. Thus, the availability of the applications depends on that service. Sops gets the secrets at deployment time inside GitLab CI/CD, without a runtime dependency. Also, the primary features of the alternatives did not help the workloads of Fluid Attacks. Most applications load all secrets when they start, through third-party libraries that read environment variables when these libraries start. Thus, the audit for each read becomes one bulk read when the application starts, and a rotation applies only after a new deployment. Fluid Attacks can decrease the rotation friction better inside the Sops model, for example, with a dedicated rotation pipeline and more rotation automation.

Alternatives

Fluid Attacks examined these alternatives, but it did not select them:

AWS Secrets Manager

• AWS Secrets Manager is not open-source.
• It is a managed AWS service. Thus, AWS manages the infrastructure complexity.
• By default, it encrypts secrets with AWS KMS customer-managed keys in the accounts of Fluid Attacks. This is the same encryption boundary that Sops uses at this time.
• Access uses only AWS IAM (secretsmanager:GetSecretValue on the secret ARN), and there is no second identity layer to maintain.
• The audit is in CloudTrail (one event for each GetSecretValue), together with the other AWS audit events of Fluid Attacks.
• It charges for each secret ($0.40 for each secret each month, and $0.05 for each 10,000 API calls). Thus, the total cost depends on how you put the entries into secrets (approximately $20 to $136 each month for the inventory of Fluid Attacks).
• It is a common Secrets Engine. Thus, the secrets are not code, and Fluid Attacks loses Git versioning. It supports its own versioning.
• It has native integration with the AWS compute of Fluid Attacks (AWS Batch job definitions, Lambda, and EKS through the Secrets Store CSI Driver). But this read path is different from the clone of the repository.
• It supports automatic rotation, but the SaaS providers of Fluid Attacks (for example, Auth0) do not have a managed integration. Each provider would have to have a custom Lambda rotation function.
• It does not have a built-in approval workflow for more than one person, or a UI for rotation for persons who are not engineers. Fluid Attacks would have to build the two features.

HashiCorp Vault

• Vault is open-source.
• It is SaaS. Thus, HashiCorp manages the infrastructure complexity.
• It supports external key management systems, for example, AWS KMS and GCP KMS.
• It charges for secrets.
• It is a common Secrets Engine. Thus, the secrets are not code, and Fluid Attacks loses Git versioning. It supports its own versioning.
• Because it has its own versioning, it is expected to support auditability and reproducibility.
• You must manage it as a different service. Thus, integration with DevOps flows is harder.
• It supports automatic rotation for some services, but these services are not important for Fluid Attacks.
• It integrates with Datadog.
• It does not support text formats. You configure it with the GUI.

Infisical

• Infisical is open-source. It is available as a managed cloud, or you can host it on your own infrastructure.
• It authenticates machine identities with AWS IAM (through STS identity verification), and its Kubernetes Operator can sync secrets into native K8s Secrets.
• Bring-your-own-key with an external KMS is only in the Enterprise edition. On the Pro tier, Infisical manages the encryption-at-rest key in its database. This is different from the current boundary ("AWS KMS in the accounts of Fluid Attacks").
• It charges for each identity (the persons and machines that connect to it). Thus, the cost increases quickly for a horizontal system like the system of Fluid Attacks (approximately $720 to $1,800 each month, which depends on how granular the machine identities are).
• It is a common Secrets Engine. Thus, the secrets are not code, and Fluid Attacks loses Git versioning. It supports its own versioning.
• The managed cloud adds a third-party dependency to the production read path. If Fluid Attacks hosts it, this dependency goes away, but the team must operate the service (RDS, Redis, upgrades, backups, on-call).
• It has a built-in, configurable approval workflow for more than one person, secret reminders, and native rotation integrations for some providers (for example, Auth0).
• Its project-role layer and audit log are different from AWS IAM and CloudTrail, and the team must keep them in sync.

Torus

• Fluid Attacks used Torus some years ago, but Torus stopped its service. One year after that, Torus started its service again. It is not open-source.
• It is SaaS. Thus, Torus manages the infrastructure complexity.
• It does not support external key management services.
• It does not publish its prices.
• It is a common Secrets Engine. Thus, the secrets are not code, and Fluid Attacks loses versioning.
• It does not support auditability and reproducibility, because it does not have versioning.
• You must manage it as a different service. Thus, integration with DevOps flows is harder.
• It does not seem to support automatic rotations.
• It does not integrate with other services.
• It does not support text formats. You configure it with the GUI.

CyberArk Secretless Broker

• CyberArk Secretless Broker is one more solution that uses secure brokers. It is open-source.
• Fluid Attacks would have to maintain all the service on its Kubernetes cluster and deploy sidecar agents to make trust relationships.
• It does not support external key management services.
• It is free. It does not seem to have costs.
• It is a common Secrets Engine. Thus, the secrets are not code, and Fluid Attacks loses versioning.
• It does not support auditability and reproducibility, because it does not have versioning.
• You must manage it as a different service. Thus, integration with DevOps flows is harder.
• It supports automatic rotations only for MySQL and PostgreSQL. Thus, manual rotation continues to be necessary.
• It integrates only with other CyberArk services, for example, CyberArk Conjur.
• It does not support text formats. You configure it with the CLI.

Usage

Fluid Attacks uses Sops to manage most of its organizational secrets in the Universe repository.

Fluid Attacks uses GitLab CI/CD Variables and not Sops for these tasks:

• To export Cachix authorization tokens, because Nix must have them before Sops starts
• To export environment variables that containers must have when these containers do not support Sops