DopplerSecrets for Kubernetes
Letting our k8s pods read secrets from Doppler without even knowing it.
A DopplerSecret is a Kubernetes custom resource definition (CRD) introduced by the Doppler Operator. It tells the Operator which secrets to fetch from Doppler and how to create the corresponding native Secrets objects inside our cluster.
When we apply a DopplerSecret, the Operator takes care of the syncing of these secrets automatically for us. In this flow, our pods never interact with Doppler directly; they consume standard Kubernetes secrets as they normally would.
The Doppler Operator is a controller that runs inside our cluster. Once installed, it does the following:
- Watches for DopplerSecret resources;
- For each DopplerSecret, it fetches the corresponding secrets from our Doppler project;
- It creates (and updates) a native Kubernetes secret populated with the data from Doppler.
Our application code does not need to change, since it reads from a regular Kubernetes secret, unaware that Doppler is behind it or that it even exists.
apiVersion: secrets.doppler.com/v1alpha1kind: DopplerSecretmetadata: name: my-app-doppler-secret namespace: defaultspec: tokenSecret: name: doppler-service-token key: token managedSecret: name: my-app-secrets namespace: defaultHere is what the important pieces mean:
- tokenSecret references the Kubernetes secret that holds our Doppler service token (the Operator uses this to authenticate with Doppler);
- managedSecret defines the name and namespace of the native Kubernetes secret that the Operator will create and keep up to date.
The Operator needs permission to fetch secrets from Doppler, and there are two ways to grant this access:
- Service Token: tied to a single Doppler project/config, this is the simplest option for a single application. Doppler infers the project and config from the token, so we don’t need to specify them in the manifest;
- Service Account Token: can access multiple projects/configs, better suited for clusters that manage secrets from several Doppler projects. In this case, we must explicitly specify the
projectandconfigfields in the DopplerSecret manifest.
This is a very important piece. When secrets are consumed as environment variables, they don’t update in-place inside a running container. So, to solve this, we can add the following annotation to our pod template:
annotations: secrets.doppler.com/reload: 'true'This tells the Operator to perform a rolling restart of the deployment whenever the managed secret is updated, ensuring our pods always have the latest values.