Sync secrets from AWS, Google and Doppler into your cluster

Edka now connects a cluster to the secret manager you already use and keeps Kubernetes Secrets in sync with it. External Secrets Operator runs in your cluster and reads the values there. Deployments read the result as environment variables or files.

What you get:

• Thirteen providers with their own form. AWS Secrets Manager, AWS Parameter Store, Google Secret Manager, Azure Key Vault, HashiCorp Vault, OpenBao, Akeyless, 1Password, Doppler, Infisical, Bitwarden Secrets Manager, Scaleway Secret Manager and GitLab CI/CD variables. Any other provider External Secrets supports works through its spec.provider block.
• Three ways to read a store. Every key of one remote secret, selected keys under names you choose, or every secret under a path or name pattern as the keys of one Secret.
• A refresh you pick. Every minute up to once a day, or once. Sync now reads the provider right away.
• Pod restarts when a value changes. Turn them on per deployment. Each restart shows in the deployment’s history.
• Values you can check. Owners and admins can show and copy a value, behind a passkey when your organization requires one.
• Notifications. A sync or a store that has failed for 10 minutes sends one, on clusters that run VictoriaMetrics.

How it works

1. Connect a store. On the cluster’s Secrets page, open Stores and click Connect store. Pick the provider and enter its credentials. The first store installs the External Secrets add-on. Credentials go into a Kubernetes Secret in the external-secrets namespace and are write-only. Edka never shows them again.
2. Sync a secret. Choose a name, a namespace, the store and what to read. The operator writes a Kubernetes Secret with that name and keeps it up to date.
3. Use it in a deployment. On the deployment’s Envs & Secrets tab, add the Secret under Secrets from the cluster. Every key becomes an environment variable. A Secret volume on the Storage tab mounts the keys as files instead.

A store is a ClusterSecretStore, and a synced secret is an ExternalSecret with the same name as its Secret. Both are standard External Secrets resources, so the operator keeps syncing them without Edka, and kubectl shows what it is doing:

kubectl get clustersecretstore
kubectl describe externalsecret api-env -n production

When a sync fails, the synced secret’s page shows the provider’s own error, such as a missing permission to list secrets. Stores created with GitOps or kubectl appear on the Stores tab, marked as created outside Edka, and synced secrets can read from them. Explorer lists every External Secrets resource on the cluster.

Restarting pods on a change

Pods read environment variables when they start, so a new value in Doppler reaches a running pod only after a restart. Each deployment has a switch, Restart pods when a Secret changes, off by default. With it on, edka-agent watches the synced secrets and Edka Secrets the deployment reads, and rolls the pods when one of them changes. It compares versions, never values, so a refresh that finds nothing new restarts nothing.

The restart is a normal rolling update. A pod that fails to start with a new value stops the rollout, and the old pods keep running. A deployment with a volume that mounts on one node at a time stops its running pod before the new one starts, and the switch says so.

Each restart appears on the deployment’s History tab as a restart named after the Secrets that changed. Clusters receive the agent version for this, edka-agent 0.0.15, automatically.

Files mounted from a Secret update in place, without a restart.

Showing values

Secret pages list every key with its value masked. Owners and admins can show one value or all of them, and copy a value without showing it. When your organization requires passkey verification, the first value asks for it. Edka reads the values from the cluster when you show them, keeps no copy, and logs who read which keys of which Secret. Developers see the key names.

Agents connected through Edka’s MCP server can list stores, create synced secrets and sync them. No MCP tool takes store credentials, so they never enter a model’s context.

What it does not do

• Static credentials only. Stores use access keys, tokens or service account keys. Cloud workload identity, such as IAM roles for service accounts, is not available on Hetzner or satellite clusters. For AWS, a role to assume keeps the stored key down to sts:AssumeRole.
• A store’s namespace list limits who syncs, not what they read. Anyone who can create a synced secret in an allowed namespace can read everything the credential can. Scope the credential on the provider side.
• No writes back to the provider. Edka reads from secret managers. It does not push Kubernetes Secrets to them.

External Secrets sync is available today on every plan. The External Secrets docs cover each provider’s credentials and permissions.