Why use Doppler for Kubernetes secrets?

TL;DR

Manually managing secrets in Kubernetes is risky and time-consuming. This post shows how to integrate Doppler’s Kubernetes Operator to automatically sync secure, up-to-date secrets into your cluster using native K8s Secret objects. No more stale configs, no more kubectl apply -f.

Oh, Kubernetes. The end boss for love/hate relationships of almost every DevOps engineer at least once in their career. Dealing with Kubernetes can often feel like a chore of the highest degree, and dealing with having a solid secrets management practice on top of that is even more of a mountain of tech to handle.

Having to update secrets manually manifests, ensuring consistency across multi-level environments, and trying to prevent sensitive data from leaking like a faucet are just a few of the things that keep me up at night. At least until I started integrating my Kubernetes clusters with the Doppler secrets management platform. Doppler has a really nice K8s operator that allows your secrets to be automatically synchronized directly into your cluster as a native Kubernetes secret object.

In this post, I will walk you through setting up the Doppler Kubernetes operator step-by-step. We will cover installing the operator, configuring access, and injecting secrets in your pods, turning cumbersome secrets management into a streamlined, automated process.

How does Doppler enhance secrets?

Before diving into the ⁠kubectl commands, let's quickly recap why integrating Doppler is a significant upgrade over managing Kubernetes secrets manually or with other methods.

Centralized control

Doppler becomes your single source of truth. Update a secret once in Doppler, and it propagates everywhere it's needed, including multiple Kubernetes clusters or even non-Kubernetes applications.

Automated syncing

Forget ⁠kubectl apply -f secret.yaml every time a credential changes. The Doppler Kubernetes Operator handles the synchronization automatically, reducing manual effort and the risk of stale secrets.

Enhanced security

Secrets are fetched dynamically by the operator and injected into the cluster. They don't live in your Git repositories or Docker images, significantly shrinking the potential attack surface. Plus, you get Doppler's audit logs for visibility.

Fine-grained access

Leverage Doppler's robust role-based access controls to manage who can view or modify secrets for specific projects and environments, applied consistently everywhere.

Improved developer experience (DX)

Developers can focus on building features, knowing that the correct, up-to-date secrets are securely and automatically available in their Kubernetes environments.

Doppler brings security, automation, and ease of use to Kubernetes secrets management, letting your team move faster and safer.

How to set up Doppler's Kubernetes Operator

So, how does the magic happen? At its core, the integration is the Doppler Kubernetes Operator. This is essentially a controller that runs inside your cluster.

Once installed, the Operator does a couple of key things:

1. It introduces a new Kubernetes object type called ⁠DopplerSecret using a Custom Resource Definition (CRD).
2. It continuously watches for any ⁠DopplerSecret resources you create or update.
3. For each ⁠DopplerSecret, it securely fetches the corresponding secrets from your Doppler project.
4. It then automatically creates and manages a standard Kubernetes ⁠Secret object, populating it with the data fetched from Doppler.

Your apps interact with the standard Kubernetes Secret, completely unaware of Doppler's involvement behind the scenes. You are able to define what secrets you need using the DopplerSecret CRD, and the Operators handles the how.

Let's get our hands a little dirty and set up this integration. Follow these steps to get Doppler secrets flowing into your Kubernetes cluster.

Step 1. Install the Doppler Kubernetes operator

First, you will need to install the Operator into your cluster. The easiest way to do this is using Helm, but you can apply manifests directly if so desired. For detailed, most up-to-date installation options and updates, always check the official Doppler Kubernetes Operator documentation.

Step 2. Choose your authentication method: Service token vs. service account token

The Operator needs permission to fetch secrets from your Doppler project(s). You have two main options for granting this access:

Doppler Service Token (simple, single scope)

This is the simplest method for a single application or environment. You create a Service Token directly within the specific Project/Config you want to sync (e.g., ⁠my-project/⁠dev).

• Action: Go to your Project/Config > ⁠Access > ⁠Service Tokens > ⁠Create Service Token. Give it a name (e.g., ⁠k8s-operator-my-app-dev) and copy the generated token.
• Pro: Easy to create, tightly scoped by default.
• Con: If you need to sync secrets from many different Doppler projects/configs within the same cluster, you'll need to create and manage a separate Service Token (and corresponding Kubernetes secret in Step 3) for each one.

Doppler Service Account Token (scalable, multi-scope)

If you manage multiple applications or environments in your cluster and want the Operator to sync secrets from various Doppler projects/configs, using a Service Account is often more manageable long-term. You create a Service Account, grant it specific permissions across multiple projects/configs, and then generate a scoped token from that Service Account.

• Action: Go to ⁠Team > ⁠Service Accounts > ⁠Create Service Account. Define its access permissions carefully (principle of least privilege is key!). Then, generate a token for this Service Account, potentially scoping it further if needed. Copy the generated token.
• Pro: One token (and one corresponding Kubernetes secret in Step 3) can potentially grant access to multiple projects/configs, reducing secret sprawl in Kubernetes.
• Con: Requires more careful setup of permissions on the Service Account to ensure it doesn't have too much access.

For this walkthrough

We'll proceed using a standard Service Token for simplicity. However, be aware that for larger, multi-project deployments, leveraging a Service Account Token might be a more scalable approach.

• Action (Continuing with Service Token): Navigate to your specific Doppler Project/Config > ⁠Access > ⁠Service Tokens, click ⁠Create Service Token, name it (e.g., ⁠k8s-operator-token), and copy the generated token immediately. Store it securely for the next step.

Step 3. Create a Kubernetes secret for the Service Token

Now, we need to securely provide the Doppler Service Token to the Operator running inside Kubernetes. We do this by creating a standard Kubernetes ⁠Secret.

Define the serviceToken

Apply the manifest

Step 4: Define the ⁠Doppler Secret Custom Resource

This is where you tell the Operator which Doppler project/config to sync secrets from and what to name the resulting Kubernetes ⁠Secret. The structure of this definition depends slightly on the type of token you created in Step 2.

Create a file named ⁠my-app-doppler-secret.yaml

Scenario 1: Using a Service Token (created in Step 2)

If you used a standard Service Token (which is tied to a single project/config), Doppler can infer the project and config directly from the token. Therefore, you only need to specify the token secret and the managed secret details

This tells the Operator: "Use the single-scoped token from ⁠doppler-service-token to fetch secrets, and manage a K8s secret named ⁠my-app-secrets."

Scenario 2: Using a Service Account Token (alternative to Step 2)

If you opted to use a Service Account Token (which might have access to multiple projects/configs), you must explicitly tell the Operator which project and config to use for this specific ⁠DopplerSecret resource by adding the ⁠project and ⁠config fields to the ⁠spec:

This tells the Operator: "Use the multi-scoped token from ⁠doppler-service-account-token to fetch secrets specifically from the ⁠production config of the ⁠my-other-project Doppler project, and manage a K8s secret named ⁠my-other-app-secrets."

Continuing the walkthrough

Since we used a standard Service Token in Step 2, we will use the first YAML example (without ⁠project and ⁠config) for the rest of this guide. Apply the appropriate manifest for your chosen token type.

Step 5: How to use Doppler-managed secrets in your pods

Finally, consume the Operator-managed secret (e.g., ⁠my-app-secrets) in your application pods, just like any standard Kubernetes ⁠Secret. You can mount them as environment variables—often the easiest way for applications to read configuration—or as files within a volume.

By adding ⁠secrets.doppler.com/reload: 'true' to ⁠spec.template.metadata.annotations, you instruct the Doppler Operator to perform a rolling restart of the Deployment whenever it updates the associated ⁠my-app-secrets Secret. This is crucial for applications consuming secrets via environment variables.

Choose the mounting method and decide if you need the auto-restart functionality based on how your application consumes secrets. When you apply this Deployment, your container will have access to the secrets managed by Doppler, and optionally, stay up-to-date automatically!

How to test Doppler-Kubernetes secrets sync

The real beauty of this setup is the automatic synchronization. Let's test it:

• Go back to the Doppler dashboard for the project/config you linked (e.g., ⁠my-project / ⁠dev).
• Change the value of one of the secrets that's being synced. Save the change.
• Wait a short period (the operator reconciles periodically, usually within a minute or so).
• Verify the change inside your cluster. You can re-check the managed Kubernetes ⁠Secret (⁠kubectl get secret my-app-secrets -n your-application-namespace -o yaml) or, even better, check directly within your running application pod (e.g., ⁠kubectl exec \<pod-name\> -n your-application-namespace – printenv | grep MYSECRETKEY).

The updated value should appear automatically without manual intervention!

Kubernetes secrets made simple with Doppler

Managing secrets effectively in Kubernetes doesn't have to be a complex or risky part of your workflow. By integrating Doppler using its Kubernetes Operator, you replace manual secret juggling and potential security gaps with a streamlined, automated, and secure process.

As we've walked through, setting up the Operator, configuring access via a Service Token, and defining a ⁠DopplerSecret resource gets you a robust system where secrets are managed centrally in Doppler and automatically synced to your cluster. This means less toil, tighter security, and a better overall experience for your development teams.

Ready to automate your Kubernetes secrets? Give the Doppler operator a try and bring your secrets management into the modern era, and be sure to look over our Doppler Kubernetes operator Documentation for the latest developments!

FAQs: Using Doppler with Kubernetes