Doppler Kubernetes Operator OIDC Setup

The Doppler Kubernetes Operator supports OIDC authentication, allowing your cluster to authenticate with Doppler using short-lived tokens instead of static API tokens. This provides enhanced security through automatic token rotation and eliminates the need to manage long-lived credentials.

Prerequisites

• Doppler Kubernetes Operator v1.7.0 or later
• Kubernetes cluster with publicly accessible OIDC discovery URL
• Team or Enterprise Doppler plan
• doppler-operator-system namespace with the operator installed

Supported Kubernetes Platforms

Amazon EKS

EKS clusters have OIDC discovery enabled by default with publicly accessible issuer URLs.

Google GKE

GKE clusters support OIDC discovery through Workload Identity. The OIDC issuer URL can be retrieved using the gcloud CLI.

Azure AKS

AKS clusters running Kubernetes 1.35+ have the OIDC issuer enabled by default. For earlier versions, it must be enabled with the --enable-oidc-issuer flag during cluster creation or update.

Self-Managed Clusters

Requires the API server's --service-account-issuer flag to be set to a publicly accessible URL that serves OIDC discovery documents. This flag is required but not set by default on self-managed clusters.

Required configuration:

• --service-account-issuer: Must be an HTTPS URL accessible by Doppler's servers
• --service-account-key-file: Path to the public key for verifying ServiceAccount tokens
• --service-account-signing-key-file: Path to the private key for signing ServiceAccount tokens

Setting Up OIDC Authentication

Step 1: Retrieve Your Cluster's OIDC Configuration

First, verify your cluster supports ServiceAccount OIDC discovery and identify the issuer URL:

# Check if OIDC discovery is available
kubectl get --raw /.well-known/openid-configuration | jq -r .issuer

# If the above fails, your cluster may not have service account issuer discovery configured.
# For self-managed clusters, check the API server configuration:
kubectl get pods -n kube-system -l component=kube-apiserver -o jsonpath='{.items[0].spec.containers[0].command}' | grep service-account-issuer

# For EKS specifically
aws eks describe-cluster --name YOUR_CLUSTER_NAME --query "cluster.identity.oidc.issuer" --output text

# For GKE
gcloud container clusters describe YOUR_CLUSTER_NAME --region=YOUR_REGION --format="value(workloadIdentityConfig.issuerUri)"

Step 2: Create a Doppler Service Account Identity

1. Visit your Doppler Service Account settings
2. Click "Add Identity" and select "Custom" as the provider
3. Configure the identity with these settings:

Discovery URL: Your cluster's OIDC issuer URL from Step 1

Audience:

dopplerTokenSecret:{dopplerTokenSecretNamespace}:{dopplerTokenSecretName}

Subject:

system:serviceaccount:doppler-operator-system:doppler-operator-controller-manager

Step 3: Create the OIDC Configuration Secret

Create a Kubernetes secret containing your Doppler identity ID:

kubectl create secret generic doppler-token-secret \
  -n doppler-operator-system \
  --from-literal=identity=YOUR_IDENTITY_ID

Step 4: Create a DopplerSecret Resource

Create a DopplerSecret that uses OIDC authentication:

apiVersion: secrets.doppler.com/v1alpha1
kind: DopplerSecret
metadata:
  name: app-secrets
  namespace: doppler-operator-system
spec:
  tokenSecret:
    name: doppler-token-secret # References the OIDC config secret
  project: example-project
  config: prd
  managedSecret:
    name: app-secrets
    namespace: default # Where your application runs

Apply the configuration:

kubectl apply -f dopplersecret.yaml

Migrating from Service Tokens

To migrate existing DopplerSecrets from service tokens to OIDC:

1. Create the OIDC identity (Step 2 above)
2. Update your existing token secret to include the identity field:

kubectl patch secret doppler-token-secret \
  -n doppler-operator-system \
  --type='json' \
  -p='[{"op": "remove", "path": "/data/serviceToken"},
       {"op": "add", "path": "/data/identity", "value": "'$(echo -n YOUR_IDENTITY_ID | base64)'"}]'

The operator will automatically switch to OIDC authentication on the next reconciliation.