Data pipelines authenticate to more external systems than most application backends. A single pipeline might connect to a source database, a destination warehouse, an S3 bucket, an API endpoint, a message queue, and a notification service. Each connection requires credentials. Where those credentials live, how they rotate, and who can access them determines whether your pipeline is secure or a breach waiting to happen.
The three tools that dominate secrets management for data infrastructure are HashiCorp Vault, AWS Secrets Manager, and SOPS (Secrets OPerationS). They solve the same problem with fundamentally different architectures, and the right choice depends on where your infrastructure runs, how your team operates, and how much secrets management complexity you can absorb.
The core architectural difference
Vault is a dedicated secrets management server. It stores secrets, generates dynamic credentials, handles encryption as a service, and enforces access policies. Vault runs as a standalone service (or cluster) that your pipelines authenticate against to retrieve secrets. It is infrastructure-agnostic: it works with any cloud, any platform, and any tool that can make an HTTP request.
AWS Secrets Manager is a managed service within AWS. It stores and retrieves secrets, rotates credentials automatically for AWS services (RDS, Redshift, DocumentDB), and integrates natively with IAM for access control. It is AWS-only by design.
SOPS takes a different approach entirely. It encrypts secret values in configuration files using cloud KMS keys (AWS KMS, GCP KMS, Azure Key Vault) or PGP, then stores the encrypted files in version control. Your secrets live in your git repository, encrypted. Developers edit secret files with sops, which decrypts, allows editing, and re-encrypts. There is no server to run and no API to call at runtime.
Vault: maximum capability, maximum complexity
Vault’s strength is its breadth of features. Dynamic secrets are Vault’s killer feature for data pipelines: instead of storing a static database password, Vault generates a unique, short-lived credential for each pipeline run. When the pipeline finishes, the credential expires. If the credential is compromised, it is already useless.
Vault also supports database credential rotation, where Vault manages the lifecycle of credentials in your database and provides fresh credentials on demand. For data pipelines that run on a schedule, this means each run gets a fresh credential that expires after the run completes. The attack surface shrinks from “all credentials ever issued” to “the single credential issued for this specific run.”
The complexity cost is real. Vault requires deployment and operation of a server (or cluster), configuration of authentication methods (AppRole for services, LDAP for humans, Kubernetes auth for K8s workloads), policy definition using HCL, unsealing procedures (Vault encrypts its storage at rest and requires an unseal key or auto-unseal configuration), and monitoring of the Vault cluster itself.
For a data team of five people running ten pipelines, Vault is overkill. For a platform team managing hundreds of pipelines across multiple environments and clouds, Vault’s capabilities justify the operational investment.
AWS Secrets Manager: the path of least resistance in AWS
If your data infrastructure lives entirely in AWS, Secrets Manager is the default choice. It integrates with IAM (access control is a policy attachment, not a separate system), with RDS and Redshift (automatic credential rotation without custom Lambda functions), with ECS and Lambda (secrets injected as environment variables or mounted as files), and with CloudFormation and Terraform (secrets defined as infrastructure-as-code).
The operational overhead is near zero. Secrets Manager is a managed service: AWS handles availability, durability, and scaling. You pay per secret per month and per API call. At typical data pipeline volumes, the cost is trivial.
The limitation is AWS lock-in and feature ceiling. Secrets Manager does not support dynamic secrets in the Vault sense. It rotates credentials on a schedule but does not generate ephemeral credentials per session. It does not support encryption as a service. It does not support multi-cloud scenarios. If your data pipeline sends data to a GCP BigQuery instance or an Azure SQL database, you need a second secrets management solution for those credentials, which defeats the purpose of centralised secrets management.
Secrets Manager also lacks fine-grained access control compared to Vault. IAM policies control who can read which secret, but there is no equivalent to Vault’s policy system that can grant time-limited, scope-limited access to specific secret paths based on complex conditions.
SOPS: secrets for teams that live in git
SOPS is built for teams that store everything in version control and want to store secrets there too. The workflow is: create a YAML, JSON, or ENV file with your secrets, encrypt it with sops using your KMS key, commit the encrypted file to git, and decrypt it at deploy time or runtime.
The advantage is simplicity and transparency. Your secrets are visible as a file in your repository (encrypted), auditable through git history (who changed what, when), and manageable through standard git workflows (pull requests for secret changes, code review for secret additions). There is no server to run, no API to call, and no separate system to learn.
For data pipelines managed through CI/CD, SOPS fits naturally. Your CI/CD system decrypts the secrets file at deploy time using a KMS key it has access to, and injects the secrets into the pipeline environment. The pipeline never calls an external secrets API. The secrets are available as environment variables or files from the moment the pipeline starts.
The limitation is that SOPS has no access control beyond KMS key policies. If someone has access to the KMS key, they can decrypt all secrets encrypted with that key. There is no per-secret access control, no audit log of secret access (beyond CloudTrail for KMS API calls), and no automatic rotation.
SOPS also does not handle runtime secret retrieval well. If your pipeline needs to refresh a credential mid-run (because the credential expired or was rotated), SOPS cannot help. The secrets were decrypted at deploy time and live in memory for the duration of the run.
Rotation and lifecycle management
Credential rotation is the feature that separates production-grade secrets management from development convenience.
Vault handles rotation natively for database credentials, with configurable rotation periods and automatic revocation of old credentials. AWS Secrets Manager handles rotation for AWS-managed databases with Lambda-based rotation functions. SOPS has no built-in rotation. You re-encrypt files with new values and commit the updated file.
For data pipelines, rotation matters most for database credentials that are long-lived. If a pipeline service account’s credentials are compromised and the password has not been rotated in 18 months, the blast radius is enormous. Vault and Secrets Manager both solve this problem. SOPS does not, and you need a separate rotation mechanism (cron job, Lambda function) to complement it.
Decision framework
Use Vault when you operate across multiple clouds, when you need dynamic per-run credentials for database connections, when you need encryption as a service for data at rest, or when your organisation has a platform team that can own Vault operations. Vault is the right choice for complex environments where secrets management is a security requirement, not just a convenience.
Use AWS Secrets Manager when your infrastructure is entirely on AWS, when you want zero operational overhead for secrets management, when you need automatic credential rotation for RDS, Redshift, or other AWS database services, or when your team is small and wants the simplest solution that meets security requirements.
Use SOPS when your team stores infrastructure configuration in git, when you want secrets to participate in code review workflows, when your secrets change infrequently, or when you need a secrets solution that works in air-gapped or offline environments. SOPS is the right choice for teams that value transparency and git-native workflows over runtime secret retrieval.
The combination worth considering: SOPS for secret storage and version control, with a runtime retrieval mechanism (Vault or Secrets Manager) for credentials that need rotation. This hybrid approach gives you git-based audit trails for secret changes and automated rotation for long-lived credentials.