Secrets Management Architecture

Secure platforms require centralized, automated credential distribution. The secrets management architecture establishes a single authoritative source for all credentials and cryptographic keys, replacing scattered storage (CI variables, local files, inline Kubernetes Secrets) with controlled distribution.

Centralized Secrets Store

The secrets store provides encrypted, audited storage for sensitive data—database passwords, API tokens, cryptographic keys. The architecture supports any secrets backend: self-hosted implementations like HashiCorp Vault or CyberArk, or cloud-managed services like AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. This flexibility allows platforms to match the secrets backend to their deployment environment and compliance requirements.

Secrets Synchronization Operator

A synchronization operator mediates between the secrets store and application consumption, bridging the gap without requiring applications to integrate directly with the backend. The operator runs within the platform with authenticated access to the secrets store, watching continuously for declarative secret definitions expressed as custom resources. When developers declare required secrets, the operator detects these requests, authenticates to the centralized store, fetches the secret material, and creates standard Kubernetes Secret objects in the appropriate namespaces. As upstream secrets rotate in the central store, the operator maintains synchronization, updating Kubernetes Secrets automatically.

Applications consume secrets through standard Kubernetes primitives—environment variables and volume mounts—without direct secrets store integration. This indirection preserves application portability while centralizing secret management at the platform level.

GitOps Integration

Secret values cannot be committed to version control. Instead, declarative definitions specify what secret to fetch—the path, the key—without containing actual sensitive data. The reconciliation controller synchronizes these definitions to the cluster; the secrets operator hydrates them with real values at runtime. This separation maintains Git as the source of truth for infrastructure configuration while keeping sensitive material out of version history.

Synchronization Patterns

The architecture supports two distinct synchronization patterns depending on where a workload consumes its sensitive data: In-Cluster Sync (Pull) for platform components, and Cross-Cloud Sync (Push) for external infrastructure.

In-Cluster Sync (Pull)

For workloads running within the Kubernetes cluster—microservices, platform components, operators—the Pull model applies. Developers declare required secrets via custom resources, specifying the secret path in the central store, the target namespace, and the refresh interval. The secrets operator detects these declarations, authenticates to the central store using its platform identity, retrieves the secret material, and creates Kubernetes Secrets in the application’s namespace. Secret material materializes only where consumed, minimizing exposure scope.

When secrets rotate in the central store, the operator updates the corresponding Kubernetes Secret automatically. If configured, this update triggers pod restarts, allowing applications to receive new credentials without manual intervention. The Pull model keeps applications decoupled from the secrets infrastructure—they consume standard Secrets objects regardless of the underlying backend.

Cross-Cloud Sync (Push)

For external workloads—serverless functions, managed databases, third-party SaaS integrations—the Push model applies. The secrets operator retrieves values from the central store and pushes them to external providers’ native secret managers: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. This enables the Kubernetes platform to act as a control plane for cloud-specific secrets while maintaining the central store as the authoritative source. Changes propagate from the central store through the operator to cloud provider backends, ensuring consistency without manual synchronization.

Security Posture

The secrets architecture enforces security principles that prevent common credential management failures.

No Secrets in Version Control

Actual secret values never exist in Git repositories. Even bootstrap credentials—initial tokens, root passwords—are generated dynamically or injected at runtime rather than committed to source control. Declarative secret definitions contain only metadata: paths, keys, target namespaces. This prevents credential exposure through repository access and maintains clean separation between configuration and sensitive data.

Automated Rotation

The secrets operator continuously reconciles with the central store. Updating a credential in the store automatically propagates the change to all consuming applications and external systems without manual intervention or application restarts. This automation reduces the operational burden of credential rotation while ensuring that compromised credentials can be cycled rapidly across the entire platform.

Least Privilege Access

The secrets operator authenticates to the central store using scoped Kubernetes Service Accounts with minimal permissions. Only platform components access the secrets store API directly—individual developers never interact with the backend. Developers declare secret requirements through custom resources that undergo the same GitOps review process as other infrastructure changes. This separation grants teams the capability to specify what secrets they need without distributing access to the central store itself.

Implementation in Demo

The reference implementation uses:

• Secrets store: HashiCorp Vault (standalone mode)
• Synchronization operator: External Secrets Operator (ESO)
• Store backends: Kubernetes backend for Vault auto-unseal, filesystem for secret storage (demo only)

Production deployments should use:

• Vault HA cluster with Raft or Consul storage
• Cloud auto-unseal (AWS KMS, Azure Key Vault, GCP Cloud KMS) or hardware HSM
• Object storage backends (S3, GCS, Azure Blob) for durability

See Components - Vault and Components - External Secrets for details.