fix(documentStore): allow IRSA AWS usage

[leiicamundi]

Which problem does the PR fix?

Customer wants to use AWS Document Store with IRSA (IAM Roles for Service Accounts), but the Helm chart currently forces credential injection via secrets, which blocks IRSA from working.

Related:

• Slack thread: https://camunda.slack.com/archives/C02AWA0RF8A/p1766428122326959
• Incident: inc-support-29235-camunda-8-7-document-store-aws

Root cause: When global.documentStore.type.aws.enabled is true, the chart always injects AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. The AWS SDK credential chain prioritizes these env vars over IRSA, so even empty values prevent IRSA from being used.

What's in this PR?

Added a new configuration option global.documentStore.type.aws.useCredentialsInSecret:

• true (default): Credentials are injected via secrets (existing behavior, backward compatible)
• false: No credentials are injected, allowing IRSA to work via the AWS SDK credential chain

Usage

To use Document Store with IRSA:

global:
  documentStore:
    activeStoreId: "aws"
    type:
      aws:
        enabled: true
        useCredentialsInSecret: false  # ← Enables IRSA mode
        bucket: "my-document-bucket"
        region: "us-east-1"

# Annotate the service account with the IAM role
orchestration:
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/document-store-role

Charts modified

• camunda-platform-8.8
• camunda-platform-8.9

Files changed per chart

File	Change
values.yaml	Added global.documentStore.type.aws.useCredentialsInSecret option
templates/orchestration/statefulset.yaml	Updated condition to check useCredentialsInSecret
templates/orchestration/importer-deployment.yaml	Updated condition (8.8 only)
templates/console/deployment.yaml	Updated condition
templates/connectors/deployment.yaml	Updated condition
templates/identity/deployment.yaml	Updated condition
templates/optimize/deployment.yaml	Updated condition
templates/web-modeler/deployment-webapp.yaml	Updated condition
templates/web-modeler/deployment-restapi.yaml	Updated condition
test/unit/common/documentstore_irsa_test.go	Added unit tests for IRSA support

Template condition change

Before:

{{- if .Values.global.documentStore.type.aws.enabled }}
- name: AWS_ACCESS_KEY_ID
  ...
{{- end }}

After:

{{- if and .Values.global.documentStore.type.aws.enabled .Values.global.documentStore.type.aws.useCredentialsInSecret }}
- name: AWS_ACCESS_KEY_ID
  ...
{{- end }}

Backward Compatibility

✅ Fully backward compatible - The default value is true, which preserves the existing behavior. Users who don't set this option will see no change.

Checklist

Please make sure to follow our Contributing Guide.

Before opening the PR:

• In the repo's root dir, run make go.update-golden-only.
• There is no other open pull request for the same update/change.
• Tests for charts are added (if needed).
• In-repo documentation are updated (if needed).

After opening the PR:

• Did you sign our CLA (Contributor License Agreement)? It will show once you open the PR.
• Did all checks/tests pass in the PR?

[eamonnmoloney]

This looks good. Can the field be more explicit like, enableIRSA or something like that... right now its not clear what is getting disable when the flag is false

Also, will this be ported to 8.6/7 and 9?

[leiicamundi]

Also, will this be ported to 8.6/7 and 9?

Not sure it's worth for 8.6, 8.7 I can have a look

Can the field be more explicit like, enableIRSA or something like that... right now its not clear what is getting disable when the flag is false

I'll improve the documentation of it

[leiicamundi]

@eamonnmoloney For 8.6 there is no document store feature, so I implemented it to 8.7, 8.8 and 8.9 only.
Regarding the documentation, I tried to improve it

[eamonnmoloney]

These are good changes. Before merging this, make sure to test they work against the QA documentStore test runs

[leiicamundi]

QA integration will be tracked by https://github.com/camunda/product-hub/issues/3388
Can we merge it and test it later? I don't have the capacity to do it now @eamonnmoloney