Document handling configuration in Helm
Helm offers external cloud file bucket storage options (recommended for production use when deploying with Helm) and in-memory storage (not suitable for production use):
-
By using external cloud file bucket storage options, documents can be stored in a secure, and scalable way. Buckets are integrated per cluster to ensure proper isolation and environment-specific management. The following file bucket storage options are supported:
- Google Cloud Platform (GCP)
- AWS S3
- Azure Blob Storage (Camunda 8.9.18+)
-
In-memory storage can be used to store documents during the application's runtime. When the application is stopped, documents are lost. In-memory storage is not suitable for production use, as pods and memory are not shared across components. Files stored in memory are not persisted and will be lost on application restart.
If no storage configuration is provided, the default document storage is in-memory. However, in-memory storage is not supported in production environments, so a configuration update is required. This is because memory is not shared between pods or components, preventing services like Tasklist and Zeebe from accessing the same data. Additionally, all uploaded files are lost when the application restarts.
To change the storage to Google Cloud Platform, AWS S3, or Azure Blob Storage, update the values.yaml file with the storage configuration parameters.
Below is an example of storage configuration. While this example mixes GCP, AWS, and in-memory, this example represents part of the default Helm chart values. This example demonstrates the current default values and what they would need to change to enable the storage type of their preference.
Azure Blob Storage uses orchestration.env for provider settings in Camunda 8.9. See Azure Blob Storage configuration for the required values.
# Global configuration for variables which can be accessed by all sub charts
global:
## Document Store Configuration
documentStore:
activeStoreId: "inmemory"
type:
aws:
## @param global.documentStore.type.aws.enabled Enable AWS document store configuration.
enabled: false
## @extra global.documentStore.type.aws.irsa configuration for AWS IAM role authentication, supporting both IRSA (IAM Roles for Service Accounts) and EKS Pod Identity.
irsa:
## @param global.documentStore.type.aws.irsa.enabled if true, no static AWS credentials are injected into pods, so the AWS SDK resolves credentials through its default provider chain; this supports both IRSA and EKS Pod Identity. If false (default), credentials are required via existingSecret or accessKeyId/secretAccessKey configuration.
enabled: false
## @param global.documentStore.type.aws.storeId Custom prefix for AWS. Default will generate env vars containing 'storeId' such as DOCUMENT_STORE_AWS_CLASS.
storeId: "AWS"
## @param global.documentStore.type.aws.region AWS region for the S3 bucket. (example: us-east-1)
region: ""
## @param global.documentStore.type.aws.bucket Name of the AWS S3 bucket.
bucket: "your-aws-bucket"
## @param global.documentStore.type.aws.bucketPath [string, nullable] (Optional) Path/prefix within the S3 bucket.
bucketPath: ""
## @param global.documentStore.type.aws.bucketTtl [int, nullable] (Optional) Time-to-live for documents in the S3 bucket (number in days).
bucketTtl: 0
## @param global.documentStore.type.aws.class Fully qualified class name for the AWS document store provider.
class: "io.camunda.document.store.aws.AwsDocumentStoreProvider"
## @extra global.documentStore.type.aws.accessKeyId configuration to provide the AWS access key ID.
accessKeyId:
## @param global.documentStore.type.aws.accessKeyId.secret.existingSecret can be used to reference an existing Kubernetes Secret containing the access key ID.
## @param global.documentStore.type.aws.accessKeyId.secret.existingSecretKey defines the key within the existing secret object.
secret:
existingSecret: ""
existingSecretKey: "access-key-id"
## @extra global.documentStore.type.aws.secretAccessKey configuration to provide the AWS secret access key.
secretAccessKey:
## @param global.documentStore.type.aws.secretAccessKey.secret.existingSecret can be used to reference an existing Kubernetes Secret containing the secret access key.
## @param global.documentStore.type.aws.secretAccessKey.secret.existingSecretKey defines the key within the existing secret object.
secret:
existingSecret: ""
existingSecretKey: "secret-access-key"
gcp:
## @param global.documentStore.type.gcp.enabled Enable GCP document store configuration.
enabled: false
## @param global.documentStore.type.gcp.storeId Custom prefix for GCP. Default will generate env vars containing 'storeId' such as DOCUMENT_STORE_GCP_CLASS.
storeId: "GCP"
## @param global.documentStore.type.gcp.bucket Name of the GCP bucket.
bucket: "your-gcp-bucket"
## @param global.documentStore.type.gcp.class Fully qualified class name for the GCP document store provider.
class: "io.camunda.document.store.gcp.GcpDocumentStoreProvider"
## @param global.documentStore.type.gcp.existingSecret Reference to an existing Kubernetes secret containing GCP credentials.
existingSecret: "gcp-credentials"
## @param global.documentStore.type.gcp.credentialsKey Key in the GCP credentials secret that contains the service-account JSON.
credentialsKey: "service-account.json"
## @param global.documentStore.type.gcp.mountPath Mount path for the GCP credentials secret.
mountPath: "/var/secrets/gcp"
## @param global.documentStore.type.gcp.fileName The file name for the GCP credentials JSON.
fileName: "service-account.json"
inmemory:
## @param global.documentStore.type.inmemory.enabled Enable in-memory document store configuration.
enabled: true
## @param global.documentStore.type.inmemory.storeId Custom prefix for in-memory. Default will generate env vars containing 'storeId' such as DOCUMENT_STORE_INMEMORY_CLASS.
storeId: "INMEMORY"
## @param global.documentStore.type.inmemory.class Fully qualified class name for the in-memory document store provider.
class: "io.camunda.document.store.inmemory.InMemoryDocumentStoreProvider"
Azure Blob Storage configuration
Configure Azure Blob Storage on Camunda 8.9.18+ through environment variables on Orchestration.
Set the Azure provider class and container name in orchestration.env. For connection string authentication, supply the secret through global.documentStore.type.azure.connectionString.secret.
Configure this document store on Orchestration only. The Connectors runtime uses the Orchestration document API rather than connecting directly to the document store.
The examples use the store ID azure. For a custom ID, use letters and digits, set global.documentStore.activeStoreId to that ID, and replace AZURE in the environment-variable names with its uppercase form. Don't use underscores in the ID: the 8.9 loader uses underscores to separate the ID from the property name.
| Environment variable | Configuration |
|---|---|
DOCUMENT_DEFAULT_STORE_ID | The chart sets this from global.documentStore.activeStoreId. |
DOCUMENT_STORE_AZURE_CLASS | Required. Set to io.camunda.document.store.azure.AzureBlobDocumentStoreProvider. |
DOCUMENT_STORE_AZURE_CONTAINER | Required. The name of an existing Blob container. |
DOCUMENT_STORE_AZURE_CONNECTION_STRING | Required for connection string authentication. The chart injects this from global.documentStore.type.azure.connectionString.secret. |
DOCUMENT_STORE_AZURE_ENDPOINT | Required when you don't provide a connection string. The storage account's Blob endpoint for DefaultAzureCredential authentication. |
DOCUMENT_STORE_AZURE_CONTAINER_PATH | Optional. A prefix for document blob names within the container. |
Prerequisites
- For chart-managed connection string authentication, use a Camunda 8.9 Helm chart release containing the Azure secret-injection fix. Upgrading only the application image to Camunda 8.9.18+ does not fix secret injection in older charts.
- An Azure Storage account with a Blob container.
- For connection string authentication: The connection string from the Azure portal (Settings > Access keys).
- For Managed Identity/DefaultAzureCredential authentication: The
Storage Blob Data ContributorRBAC role assigned on the storage account.
Authentication options
Azure Blob Storage supports two authentication methods:
- Connection string: Configure
global.documentStore.type.azure.connectionString.secretto inject the connection string from a Kubernetes Secret. DefaultAzureCredential(recommended for AKS): Configure Workload Identity or Managed Identity, then setDOCUMENT_STORE_AZURE_ENDPOINTinstead of providing a connection string. Assign theStorage Blob Data ContributorRBAC role on the storage account.
Connection string authentication
This example uses a connection string stored in a Kubernetes secret.
global:
documentStore:
activeStoreId: "azure"
type:
azure:
connectionString:
secret:
existingSecret: "azure-storage-credentials"
existingSecretKey: "connection-string"
orchestration:
env:
- name: DOCUMENT_STORE_AZURE_CLASS
value: io.camunda.document.store.azure.AzureBlobDocumentStoreProvider
- name: DOCUMENT_STORE_AZURE_CONTAINER
value: my-container
Managed Identity/DefaultAzureCredential
When using AKS Workload Identity or Managed Identity, omit the connection string secret and set DOCUMENT_STORE_AZURE_ENDPOINT instead:
global:
documentStore:
activeStoreId: "azure"
orchestration:
env:
- name: DOCUMENT_STORE_AZURE_CLASS
value: io.camunda.document.store.azure.AzureBlobDocumentStoreProvider
- name: DOCUMENT_STORE_AZURE_CONTAINER
value: my-container
- name: DOCUMENT_STORE_AZURE_ENDPOINT
value: https://myaccount.blob.core.windows.net