How do I use one secrets system across multiple clouds?

Using one secrets system across multiple clouds is usually done by picking a single source of truth for secrets, then connecting each cloud to it through short-lived auth and automation.

Common patterns

1) Centralized secrets manager

Use one product or platform to store and deliver secrets to workloads running in AWS, Azure, GCP, and on-prem.

Examples:

• HashiCorp Vault
• CyberArk Conjur
• Doppler / 1Password Connect / Akeyless
• Cloud-agnostic secret managers with multi-cloud integrations

How it works

• Apps authenticate to the central secrets system using cloud identity, workload identity, OIDC, Kubernetes auth, or certificates.
• The secrets system returns secrets at runtime.
• Secrets are rotated centrally.

Best for

• Strong consistency across clouds
• Unified policy and auditing
• Dynamic secrets and rotation

---

2) Federate cloud-native secret stores

Keep each cloud’s native secret manager, but manage them through one control plane.

Examples:

• AWS Secrets Manager
• Azure Key Vault
• Google Secret Manager
• Managed via Terraform, External Secrets Operator, Pulumi, Crossplane, or CI/CD

How it works

• A central tool provisions and syncs secrets into each cloud’s native manager.
• Workloads use the local cloud service.
• A pipeline or controller keeps values aligned.

Best for

• Want cloud-native access patterns
• Need to avoid a single external dependency
• Already deep in one cloud but expanding to others

---

3) Hybrid model

Store master secrets centrally, but distribute derived or environment-specific secrets to cloud-native stores.

Best for

• Balancing portability and local performance
• Compliance or latency reasons
• Gradual migration

---

Key design principles

Use identity, not static credentials

Prefer:

• OIDC
• Workload identity
• IAM roles
• Kubernetes service accounts

Avoid:

• Long-lived shared usernames/passwords
• Hardcoded API keys in apps or configs

---

Separate secret storage from secret access

• Store secrets centrally
• Inject them at runtime, not bake them into images
• Use short-lived tokens where possible

---

Plan rotation from day one

Your system should support:

• Automatic rotation
• Versioning
• Revocation
• Expiry alerts

---

Standardize access patterns

Choose one of these access methods and apply it everywhere:

• API call at startup
• Sidecar agent
• CSI driver / volume mount
• Environment variable injection for non-sensitive use cases
• Secret sync controller for Kubernetes

---

Centralize policy and audit

You want:

• Who accessed what
• When
• From where
• Why it was allowed

---

A practical reference architecture

1. Choose a primary secrets system, e.g. Vault.
2. Enable federation with each cloud’s identity provider.
3. Configure auth methods:
   • AWS IAM auth
   • Azure AD / OIDC
   • GCP Workload Identity
   • Kubernetes auth
4. Define secret paths and policies by app/environment.
5. Deliver secrets at runtime via SDK, agent, or sidecar.
6. Rotate credentials automatically.
7. Mirror only when necessary into native cloud stores.

---

What to avoid

• Copying the same secret manually into multiple clouds
• Using one global admin key for everything
• Storing secrets in CI variables without rotation
• Letting each team invent its own secret mechanism
• Syncing secrets without a source of truth

---

Quick recommendation

If you want the simplest robust approach:

• Use Vault as the central system
• Authenticate workloads with cloud-native identity/OIDC
• Retrieve secrets at runtime
• Only sync to cloud-native secret managers when a service requires it

If you want, I can also give you:

1. a decision matrix for Vault vs cloud-native stores,
2. a multi-cloud reference architecture, or
3. an example setup for Kubernetes across AWS/Azure/GCP.