Managing secrets in Helm charts

This guide provides an overview for configuring and managing secrets when using the official Helm chart.

Internal secrets

These secrets are used by Camunda applications. They are created and managed by the Helm chart unless explicitly configured.

Secret	Chart values key	Purpose	Default behavior
Keycloak Admin Password	identity.keycloak.auth.existingSecret, identity.keycloak.auth.adminPassword	Admin password for Keycloak (Camunda Identity)	Generated by default if not set
Keycloak Management Password	identity.keycloak.auth.existingSecret, identity.keycloak.auth.managementPassword	Internal password for Identity service communication	Generated by default if not set
Identity First User Password	identity.firstUser.password, identity.firstUser.existingSecret	Default user password (demo/demo)	demo unless overridden
OAuth Client Secret (Operate)	global.identity.auth.operate.existingSecret.name	OAuth client secret for Operate	Generated by default if not set
OAuth Client Secret (Tasklist)	global.identity.auth.tasklist.existingSecret.name	OAuth client secret for Tasklist	Generated by default if not set
OAuth Client Secret (Optimize)	global.identity.auth.optimize.existingSecret.name	OAuth client secret for Optimize	Generated by default if not set
OAuth Client Secret (Connectors)	global.identity.auth.connectors.existingSecret.name	OAuth client secret for Connectors	Generated by default if not set
OAuth Client Secret (Zeebe)	global.identity.auth.zeebe.existingSecret.name	OAuth client secret for Zeebe	Generated by default if not set
Identity PostgreSQL Password	identityPostgresql.auth.existingSecret	Password for embedded PostgreSQL used by Identity	Generated by default if not set
Keycloak PostgreSQL Password	identityKeycloak.auth.existingSecret	Password for embedded PostgreSQL used by Keycloak	Generated by default if not set
Web Modeler PostgreSQL Password	postgresql.auth.existingSecret, postgresql.auth.secretKeys.adminPasswordKey, postgresql.auth.secretKeys.userPasswordKey	Passwords for Web Modeler's embedded PostgreSQL via Bitnami chart	Generated by default if not set
Enterprise License Key	global.license.existingSecret, global.license.existingSecretKey	Camunda Enterprise License Key	Not set unless provided

External secrets

These secrets are necessary when integrating Camunda with third-party services.

Secret	Chart values key	Purpose	Default behavior
External Database Password	webModeler.restapi.externalDatabase.existingSecret.name	Password for external PostgreSQL if using an external DB	Not set unless provided
SMTP Password	webModeler.restapi.mail.existingSecret.name	SMTP credentials for sending email notifications	Not set unless provided
Connectors Inbound Auth Password	connectors.inbound.auth.existingSecret, connectors.inbound.auth.existingSecretKey	Basic authentication password for Connectors polling Operate	Not set unless provided
External Elasticsearch Auth	global.elasticsearch.auth.existingSecret	Password for external Elasticsearch authentication (Basic authentication)	Not set unless provided
External Elasticsearch TLS Cert	global.elasticsearch.tls.existingSecret	TLS certificate for external Elasticsearch over SSL	Not set unless provided
External OpenSearch Auth	global.opensearch.auth.existingSecret	Password for external OpenSearch authentication (Basic authentication)	Not set unless provided
External OpenSearch TLS Cert	global.opensearch.tls.existingSecret	TLS certificate for external OpenSearch over SSL	Not set unless provided

Creating Kubernetes secrets

Secrets may be created manually using the kubectl CLI or defined in Kubernetes manifests.

To create a secret via kubectl::

kubectl create secret generic camunda-secret \
  --from-literal=operate-secret-key=camundapassword\
  --namespace camunda

Or using YAML:

apiVersion: v1
kind: Secret
metadata:
  name: operate-secret
  namespace: camunda
type: Opaque
stringData:
  operate-secret-key: "camundapassword"

Apply it with:

kubectl apply -f my-secret.yaml

For additional details on Identity secrets, visit the installation guide.

Referencing secrets in values.yaml

Depending on the structure of the secret key, there are two ways to reference a secret in the values.yaml file:

Option 1: Using existingSecret.name

Use this approach when the chart expects the secret to be split into a name and key.

global:
  identity:
    auth:
      operate:
        existingSecret:
          name: operate-secret
        existingSecretKey: operate-secret-key

Option 2: Using existingSecret

In some cases, the chart expects the secret name directly and a reference to the specific key as a separate field.

global:
  identity:
    keycloak:
      auth:
        existingSecret: keycloak-secret
        adminPassword: admin-password-key

TLS secrets

When Camunda services are exposed via Ingress with TLS, a Kubernetes secret containing the TLS certificate and private key is typically required. This is especially important when using tools like cert-manager or securing public-facing services.

Chart values

The TLS secret can be configured as shown below:

global:
  ingress:
    tls:
      enabled: true
      secretName: camunda-tls-secret

TLS secret example

apiVersion: v1
kind: Secret
metadata:
  name: camunda-tls-secret
  namespace: camunda
annotations:
  cert-manager.io/issuer: "letsencrypt-prod"
type: kubernetes.io/tls
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>

Ensure the secret name is configured in values.yaml under global.ingress.tls.secretName.