Skip to content

10-x.md

Latest commit

 

History

History
555 lines (419 loc) · 29.2 KB

10-x.md

File metadata and controls

555 lines (419 loc) · 29.2 KB

Release 10.x.x

Version 10.x.x of the Data Space Connector contains a major change to the Keycloak deployment and to the OID4VCI realm model. They will be listed below, together with required actions for migration.

The two drivers of this release are:

  1. The Bitnami Keycloak Helm chart was withdrawn, so the umbrella now depends on the CloudPirates Keycloak chart. The CloudPirates chart targets the upstream Quarkus image (quay.io/keycloak/keycloak) and exposes a different values.yaml shape than Bitnami's, so the entire keycloak: configuration block must be rewritten.
  2. Keycloak 26.4 redesigned OID4VCI (keycloak/keycloak#39768). The realm-attribute scheme vc.<name>.* and the components.CredentialBuilder block are gone; per-credential configuration moved to ClientScope attributes on scopes with protocol: "oid4vc", and several mapper config keys were renamed or removed. The DSC chart's realm.verifiableCredentials API has been adjusted accordingly.

Keycloak chart migration: Bitnami → CloudPirates

Removed (9.x) New (10.x)
Chart oci://registry-1.docker.io/bitnamicharts/keycloak 25.2.0 Chart oci://registry-1.docker.io/cloudpirates/keycloak 0.21.4
Image bitnamilegacy/keycloak Image quay.io/keycloak/keycloak:26.6.2 (upstream Quarkus)
Realm import path /opt/bitnami/keycloak/data/import Realm import path /opt/keycloak/data/import
Bitnami helper env vars (KEYCLOAK_EXTRA_ARGS, …) Native CLI flags via keycloak.extraArgs and feature flags

⚠️ Required action:

The CloudPirates chart does not honour any Bitnami-only key. Apply the renames in the next section to your keycloak: value override and remove the keys listed afterwards.

Required values renames in keycloak:

Removed (9.x) New location (10.x)
keycloak.auth.adminUser keycloak.keycloak.adminUser
keycloak.auth.existingSecret keycloak.keycloak.existingSecret
keycloak.auth.passwordSecretKey keycloak.keycloak.secretKeys.adminPasswordKey
keycloak.proxyHeaders keycloak.keycloak.proxyHeaders
keycloak.service.ports.http keycloak.service.httpPort
keycloak.postgresql.enabled keycloak.postgres.enabled
keycloak.externalDatabase.host keycloak.database.host
keycloak.externalDatabase.database keycloak.database.name
keycloak.externalDatabase.user keycloak.database.username
keycloak.externalDatabase.existingSecret keycloak.database.existingSecret
keycloak.externalDatabase.existingSecretPasswordKey keycloak.database.secretKeys.passwordKey
keycloak.initContainers keycloak.extraInitContainers
keycloak.ingress.hostname keycloak.ingress.hosts[0].host
keycloak.ingress.extraTls merged into keycloak.ingress.tls (single list)
keycloak.ingress.pathType keycloak.ingress.hosts[0].paths[0].pathType

If your external Postgres secret carries the username under a key other than db-username (for instance the Zalando postgres-operator writes username), you also need:

keycloak:
  database:
    secretKeys:
      usernameKey: username

The following keys are no longer valid and must be removed:

keycloak.kubeVersion
keycloak.global.security.allowInsecureImages
keycloak.image.repository           # default is keycloak/keycloak; override only if you really need a custom image
keycloak.containerSecurityContext.enabled
keycloak.proxy                      # use keycloak.keycloak.proxyHeaders + TLS terminated at the ingress
keycloak.service.extraPorts         # the management/health port is exposed via metrics.enabled (see below)
keycloak.extraEnvVars:
  - KEYCLOAK_EXTRA_ARGS             # Bitnami-only; the umbrella adds --import-realm via realm.import: true
  - KC_FEATURES                     # use keycloak.features.enabled instead
  - KC_HEALTH_ENABLED               # auto-enabled by any active probe
  - KC_ADMIN_PASSWORD               # handled by keycloak.keycloak.existingSecret

Management / health port (9000)

The CloudPirates chart does not expose port 9000 on the main Service. With metrics.enabled: true (the umbrella default in 10.x) it is published on a separate Service named <release>-keycloak-metrics:9000.

⚠️ Required action:

If you maintain a wait-for-keycloak initContainer or any custom probe targeting <release>-keycloak:9000/health/ready, change the host to <release>-keycloak-metrics:9000.

Default account-console client must opt into OID4VCI

KC 26.4+ rejects calls to /protocol/oid4vc/create-credential-offer whose bearer token is issued to a client without oid4vci.enabled=true. Many wallet flows authenticate the user via the built-in account-console client; the umbrella therefore declares the attribute on that client by default:

keycloak:
  realm:
    defaultClients:
      account-console:
        attributes:
          oid4vci.enabled: "true"

If you override defaultClients, preserve this attribute.

OID4VCI realm model rewrite

The realm-attribute scheme realm.attributes vc.<name>.* and the components.CredentialBuilder block are no longer recognised by KC 26.4+. Per-credential configuration is now declared once in realm.verifiableCredentials.<name>; the DSC chart renders one ClientScope per entry with protocol: "oid4vc" and the attributes attached to the scope itself.

Before (9.x):

keycloak:
  realm:
    attributes: |
      "vc.user-credential.format": "jwt_vc",
      "vc.user-credential.scope": "UserCredential",
      "vc.user-credential.vct": "UserCredential",
      "vc.user-credential.credential_signing_alg_values_supported": "ES256"
    credentialBuilder:
      jwt-vc-builder:
        id: jwt-vc-builder
        name: jwt_vc

After (10.x):

keycloak:
  realm:
    verifiableCredentials:
      user-credential:
        attributes:
          format: "jwt_vc_json"
          verifiable_credential_type: "UserCredential"
          credential_signing_alg: "ES256"
          credential_build_config.token_jws_type: "JWT"
        protocolMappers:
          - name: context-mapper
            protocol: oid4vc
            protocolMapper: oid4vc-context-mapper
            config:
              context: https://www.w3.org/2018/credentials/v1
          - name: email-mapper
            protocol: oid4vc
            protocolMapper: oid4vc-user-attribute-mapper
            config:
              claim.name: email
              userAttribute: email

The key under verifiableCredentials (user-credential above) is the ClientScope name — i.e. the value the wallet sends as credential_configuration_id. The realm-level realm.credentialBuilder: block is removed entirely (in KC 26.4+ credential builders are loaded via SPI service-loader, not declared per realm).

Format strings rename

Format 9.x value 10.x value
SD-JWT VC vc+sd-jwt dc+sd-jwt
JWT-VC JSON jwt_vc jwt_vc_json

The source of truth is core/src/main/java/org/keycloak/VCFormat.java in the Keycloak repository. The same rename applies wherever the format string appears: verifiableCredentials.<name>.attributes.format, DCQL queries (realm.verifiableCredentials.<name>.protocolMappers configs that reference a format, and any DCQL configuration in decentralizedIam.vcAuthentication.credentials-config-service.registration.services[].oidcScopes.*.dcql.credentials[].format).

Template auto-derivations (DSC chart)

The DSC _realm.tpl template fills in two ClientScope attributes when they are not set explicitly:

  • vc.issuer_did — derived from elsi.did if elsi.enabled: true, else from keycloak.issuerDid, else ${DID}. Sets the iss claim of every issued JWT VC.
  • vc.supported_credential_types — defaults to the value of vc.verifiable_credential_type. Drives the type array of JWT-VC JSON credentials and the metadata credential_definition.type. Override it explicitly under attributes if you need a different value than the SD-JWT vct.

Mapper config renames

Mapper Old key (9.x) New key (10.x)
every mapper supportedCredentialTypes (removed; mapper membership is structural per scope)
oid4vc-user-attribute-mapper, oid4vc-target-role-mapper, oid4vc-static-claim-mapper, oid4vc-generated-id-mapper, oid4vc-issued-at-time-claim-mapper subjectProperty claim.name
oid4vc-subject-id-mapper subjectIdProperty claim.name (plus userAttribute)
oid4vc-vc-type-mapper (whole mapper) deprecated; set the scope attribute vc.verifiable_credential_type instead

A mapper that previously listed several credential types in supportedCredentialTypes must now be declared once under each VC entry it should apply to. The mapper name must be unique within a single VC's protocolMappers list — suffixing the name with the VC key (-uc, -lpc, -oc, …) makes greps easier.

⚠️ KC 26.4+ does not allow two oid4vc-target-role-mapper mappers with the same claim.name in the same scope. Pick one target per VC, or use distinct claim names — but be aware that downstream verifiers (FIWARE vcverifier, ODRL/OPA in this chart) look for credentialSubject.roles[*].target by default, so deviating from the roles claim name requires a matching policy update.

SD-JWT red list

KC 26.4+ enforces a "red list" of standard claims that must not be undisclosed in a SD-JWT VC: iss, iat, nbf, exp, cnf, vct, status (source: core/src/main/java/org/keycloak/sdjwt/DisclosureRedList.java).

If you override verifiableCredentials.<name>.attributes.credential_build_config.sd_jwt.visible_claims, include those seven names alongside your domain-specific ones, otherwise issuance fails with IllegalArgumentException: UndisclosedClaims contains red listed claim names.

keycloak:
  realm:
    verifiableCredentials:
      user-sd:
        attributes:
          format: "dc+sd-jwt"
          verifiable_credential_type: "LegalPersonCredential"
          credential_build_config.sd_jwt.visible_claims: "iss,iat,nbf,exp,cnf,vct,status,roles,email"

New feature flags

KC main has split the original experimental OID4VCI feature flag into one base flag plus two sub-features. All three must be enabled for the DSC's issuance flow to work:

keycloak:
  features:
    enabled:
      - oid4vc-vci
      - oid4vc-vci-preauth-code        # KC 26.4+: gates the pre-authorized_code grant
      - oid4vc-vci-rest-credential-offer  # KC main / SEAMWARE 26.6.2: gates /create-credential-offer

Without oid4vc-vci-rest-credential-offer, Keycloak answers any call to /protocol/oid4vc/create-credential-offer with 403 invalid_client: "REST credential offer functionality is not enabled". The flag is defined in Profile.Feature.OID4VC_VCI_REST_CREDENTIAL_OFFER and is consumed by OID4VCIssuerEndpoint.checkRestCredentialOfferEnabled. It landed in upstream main together with the OID4VCI QR-generation fix and is present in the patched quay.io/seamware/keycloak:26.6.2 image shipped by the umbrella, even though vanilla 26.6.2 does not carry it.

The umbrella ships these three defaults out of the box.

Endpoint changes for custom wallets / scripts

If you have custom code that talks to the Keycloak OID4VCI endpoints, update it as follows:

Step Old (KC 26.3) New (KC 26.4 → 26.6.2) Newer (KC main / SEAMWARE-patched 26.6.2)
Request offer URI GET /protocol/oid4vc/credential-offer-uri?credential_configuration_id=X GET /protocol/oid4vc/create-credential-offer?credential_configuration_id=X&pre_authorized=true same
Build offer URL ${issuer}${nonce} ${issuer}/${nonce} same
/credential body {"credential_identifier":"X","format":"jwt_vc"} {"credential_configuration_id":"X"} {"credential_identifier":"<id-from-token-response>"}
/credential response {"credential":"<jwt>"} {"credentials":[{"credential":"<jwt>"}]} same
credential_identifier source n/a (anything accepted) n/a must come from the authorization_details[].credential_identifiers array returned by /token after exchanging the pre-authorized code

The pre_authorized query parameter on /create-credential-offer defaults to false, so it must be set explicitly to obtain the pre-authorized_code grant. The format field of /credential is no longer accepted as input — format selection happens by picking a credential_configuration_id whose configured vc.format matches what the caller expects.

credential_identifier flow (keycloak/keycloak#47404)

The patched 26.6.2 image arrives with the upstream rule that /credential only accepts a credential_identifier, never a credential_configuration_id. The identifier is short-lived and bound to the issued access token:

  1. Wallet exchanges the pre-authorized code at /token.
  2. /token response contains: 
    "authorization_details": [{
  "type": "openid_credential",
  "credential_configuration_id": "user-credential",
  "credential_identifiers": ["user-credential_0000"]
}]
  3. Wallet POSTs /credential with {"credential_identifier": "user-credential_0000"}.

Sending the legacy {"credential_configuration_id": "..."} body against this image returns 400 invalid_credential_request: "Credential must be requested by credential identifier from authorization_details: [...]".

The IT framework's Wallet.java was updated accordingly: it reads authorization_details off the TokenResponse model and falls back to the previous credential_configuration_id-based body when the field is absent, so it still works against older Keycloak versions.

Client roles consistency

KC 26.4+ rejects user→client role assignments where the client itself does not declare the role. The realm import attempts to auto-create the missing role and, if multiple users assign it in the same batch, fails with duplicate key violates unique constraint.

⚠️ Required action:

For every clientRoles.<clientId>: [...] you set on a user, declare the same role under realm.clientRoles.<clientId>. The consumer.yaml and provider.yaml example overlays in this repository show the consistent shape (REPRESENTATIVE declared on did:web:mp-operations.org, seller/admin declared on did:web:fancy-marketplace.biz).

Per-user verifiableCredentials assignment

KC main (carried by the SEAMWARE-patched 26.6.2 image — see keycloak/keycloak@6ef5a79) ties /create-credential-offer to a per-user verifiableCredentials list. A user that has not been explicitly granted a credential gets:

400 invalid_credential_offer_request
"User 'X' does not have verifiable credential 'Y'."

even with a valid token and a properly configured ClientScope.

In the realm import JSON the list lives on each user entry:

{
  "username": "employee",
  "verifiableCredentials": [
    { "credentialScopeName": "user-credential" },
    { "credentialScopeName": "operator-credential" }
  ]
}

⚠️ Required action:

Either set this list per user, or set the chart flag below to have the umbrella auto-assign every VC declared in the realm to every user that has not provided its own verifiableCredentials:

keycloak:
  realm:
    wallets:
      issueCredentialsToUsers: true

wallets.enabled does not need to be true for this to work — the two flags are independent. The local k3s overlays (k3s/consumer.yaml, k3s/provider.yaml) ship with issueCredentialsToUsers: true so the example deployment works out of the box; in production you usually want to declare the per-user lists explicitly instead.

OID4VCI draft compliance

Keycloak 26.6.2 implements OID4VCI Draft 15. The 26.4 redesign (keycloak/keycloak#39768) explicitly aligned the credential issuance flow with Draft 15: CredentialSubject was removed from CredentialDefinition, the format field was dropped from CredentialRequest, the metadata endpoint claims structure was rewritten and the cwt proof type was removed.

Practical implications already covered above (see Endpoint changes for custom wallets / scripts, OID4VCI realm model rewrite and Format strings rename):

  • /credential request: send credential_configuration_id (no format); response is {"credentials":[…]}.
  • /credential-offer-uri is replaced by /create-credential-offer?pre_authorized=true.
  • Format strings updated: jwt_vc → jwt_vc_json, vc+sd-jwt → dc+sd-jwt.

If you maintain a custom wallet or test harness, target Draft 15 endpoints and payloads.

Wallet compatibility

The chart includes an opinionated wallet preset (off by default) that registers the OIDC clients required by the wallets validated against this release. The preset only configures clients — it does not declare any credential type; that remains the deployer's job under keycloak.realm.verifiableCredentials.

Wallet Platform Tested version Default clientId OIDC requirements Recommended for
Lissi ID Wallet iOS 3.1.3 9c481dc3-2ad0-4fe0-881d-c32ad02fe0fc PKCE S256 Production
Lissi ID Wallet Android 3.1.1 9c481dc3-2ad0-4fe0-881d-c32ad02fe0fc PKCE S256 Production
EUDI Reference Wallet (forked .DEV build — app + lib) iOS — wallet-dev PAR + DPoP + PKCE S256 Development / local testing

Lissi is the recommended wallet for production deployments.

EUDI Reference Wallet — fork required. The upstream EUDI iOS app/lib does not yet implement the OID4VCI Draft 15 model that Keycloak 26.6.2 ships, so it cannot complete an issuance flow against the DSC's Keycloak out of the box. The forks linked above carry two changes that make them usable for local DSC development:

  1. The credential issuance flow is updated to the Draft 15 endpoints/payloads documented in Endpoint changes for custom wallets / scripts above.
  2. They accept self-signed TLS certificates, which is what makes them usable against a k3s cluster with cert-manager issuing self-signed certs.

Do not use the forked EUDI build in production — its self-signed-cert handling defeats the trust model. It is intended exclusively as a developer-side tool for local data space testing.

The clientId values match what each wallet looks for in the realm — override only if the wallet vendor rotates them. The defaults are defined at charts/data-space-connector/values.yaml under keycloak.realm.wallets.lissi and keycloak.realm.wallets.eudi.

Enabling the preset:

keycloak:
  realm:
    wallets:
      enabled: true
      # Optional: auto-assign every realm-declared verifiableCredentials entry to every
      # user that does not declare its own list. Useful for smoke tests, off by default.
      issueCredentialsToUsers: false

Override any leaf without redefining the whole client, for example:

keycloak:
  realm:
    wallets:
      enabled: true
      lissi:
        clientId: <your-rotated-lissi-id>

Wallets that are not in this list are not blocked — any wallet that speaks OID4VCI Draft 15 and either PKCE S256 or PAR+DPoP+PKCE S256 can be wired up by declaring the corresponding OIDC client manually in keycloak.realm.clients.

Migration checklist

  1. Apply the value renames in the table above to your keycloak: block; remove the listed obsolete keys.
  2. Rewrite each entry under keycloak.realm.attributes of the form vc.<name>.* as a keycloak.realm.verifiableCredentials.<name> block with attributes and protocolMappers. Drop the keycloak.realm.credentialBuilder: block entirely.
  3. Update format strings: vc+sd-jwt → dc+sd-jwt, jwt_vc → jwt_vc_json, both in the realm config and in any DCQL queries you maintain.
  4. If you override keycloak.realm.defaultClients, preserve account-console.attributes.oid4vci.enabled: "true".
  5. Add oid4vc-vci-preauth-code to keycloak.features.enabled.
  6. Update any custom wait-for-keycloak probe to target <release>-keycloak-metrics:9000.
  7. Validate locally with helm template charts/data-space-connector -f your-values.yaml and a one-off kc.sh import --dir=/opt/keycloak/data/import against a 26.6.2 pod before redeploying.
  8. Rerun your integration tests; confirm both consumer and provider Keycloaks reach Listening on http://0.0.0.0:8080 and that VC issuance flows complete.

For a worked end-to-end example, see the migrated k3s/consumer.yaml and k3s/provider.yaml overlays shipped with this release; the oid4vc-protocol-mappers.md reference now documents the 26.6.2 mapper API.

Grafana Tempo Integration (10.2.0)

10.2.0 adds optional in-cluster Grafana Tempo trace storage and Grafana dashboard support, building on the OpenTelemetry tracing infrastructure introduced in 10.1.0. The integration is fully opt-in — no existing values are modified or removed.

New optional subchart dependencies

Subchart Chart Version Repository
tempo grafana/tempo 1.24.4 https://grafana.github.io/helm-charts
grafana grafana/grafana 10.5.15 https://grafana.github.io/helm-charts

Both are disabled by default and gated by tempo.enabled / grafana.enabled.

Auto-wired Collector → Tempo pipeline

When tracing.enabled=true and tempo.enabled=true, the chart renders a custom OTEL Collector ConfigMap (otel-collector-config-cm.yaml) that automatically injects an otlp/tempo exporter targeting the in-cluster Tempo gRPC endpoint. No manual Collector configuration is required — the existing opentelemetry-collector.config values are used as a base and the Tempo exporter is appended at render time.

When tempo.enabled=false, the ConfigMap renders the Collector configuration as-is (identical behaviour to 10.1.0).

Auto-provisioned Grafana datasource

When both grafana.enabled=true and tempo.enabled=true, the chart renders a datasource ConfigMap (grafana-tempo-datasource-cm.yaml) labelled grafana_datasource: "1". The Grafana sidecar picks it up automatically and registers Tempo as the default datasource. Operators can browse traces in the Grafana Explore view immediately after deployment.

Enabling the full stack

tracing:
  enabled: true
tempo:
  enabled: true
grafana:
  enabled: true

This deploys: workloads with OTEL instrumentation → OTEL Collector → Grafana Tempo → Grafana dashboard. No additional configuration is needed for a working development/test setup.

New values keys

Key Type Default Description
tempo.enabled bool false Toggle the bundled Grafana Tempo subchart
tempo.tempo.retention string "48h" Trace retention period
tempo.tempo.receivers.otlp.protocols.grpc.endpoint string "0.0.0.0:4317" OTLP gRPC listen address
tempo.tempo.receivers.otlp.protocols.http.endpoint string "0.0.0.0:4318" OTLP HTTP listen address
tempo.tempo.storage.trace.backend string "local" Storage backend (local, s3, gcs, azure)
tempo.resources map cpu: 100m–500m, mem: 256Mi–1Gi Tempo pod resources
grafana.enabled bool false Toggle the bundled Grafana subchart
grafana.adminPassword string "admin" Grafana admin password (override in production)
grafana.sidecar.datasources.enabled bool true Enable sidecar for auto-provisioning datasources
grafana.sidecar.datasources.label string "grafana_datasource" Label the sidecar watches on ConfigMaps
grafana.persistence.enabled bool false Enable persistent storage for Grafana
grafana.resources map cpu: 100m–500m, mem: 128Mi–512Mi Grafana pod resources

New template files

File Purpose
templates/otel-collector-config-cm.yaml Custom Collector ConfigMap with auto-injected Tempo exporter
templates/grafana-tempo-datasource-cm.yaml Grafana datasource ConfigMap for Tempo

New test file

File Purpose
tests/tempo_test.yaml Helm-unittest suite covering Collector ConfigMap and Grafana datasource rendering

New helpers in _helpers.tpl

Helper Returns
dsc.tempo.endpoint http://<release>-tempo:4317 (Tempo OTLP gRPC endpoint for the Collector)
dsc.tempo.queryEndpoint http://<release>-tempo:3200 (Tempo HTTP API endpoint for Grafana)

Documentation

Full documentation including architecture diagrams, quick-start guide, external Tempo usage, production considerations, and troubleshooting is available at Distributed Tracing with OpenTelemetry.

No breaking changes

This release is fully additive. All new subcharts default to enabled: false. Existing tracing behaviour from 10.1.0 is unchanged when Tempo and Grafana are not enabled.

OpenTelemetry Distributed Tracing (10.1.0)

10.1.0 adds optional end-to-end distributed tracing across the FIWARE Data Space Connector using OpenTelemetry. All first-party workloads (IdentityHub, fdsc-edc) and third-party subcharts that support native OTEL configuration (Keycloak, Scorpio, tm-forum-api, contract-management, marketplace) can export traces through the OTLP protocol to any compatible backend (Jaeger, Grafana Tempo, Honeycomb, etc.).

An optional OpenTelemetry Collector subchart is included for in-cluster trace aggregation and routing.

Enabling tracing

Set tracing.enabled: true to inject OTEL_* environment variables into all supported workloads and enable the OpenTelemetry Java agent for IdentityHub:

tracing:
  enabled: true
  exporter:
    otlp:
      endpoint: ""          # defaults to the bundled collector
      protocol: "grpc"      # or "http/protobuf"
      insecure: true
  sampler: "parentbased_traceidratio"
  samplerArg: "1.0"
  propagators: "tracecontext,baggage"
  resourceAttributes: {}

opentelemetry-collector:
  enabled: true

Per-component tracing

Each component can override the global tracing toggle independently via its own tracing.enabled key:

identityhub:
  tracing:
    enabled: true           # override global toggle
    serviceName: "my-identityhub"
    javaagent:
      enabled: true         # attach the OTEL Java agent via init container

fdsc-edc:
  tracing:
    serviceName: "my-fdsc-edc"

scorpio:
  tracing:
    serviceName: "scorpio"

keycloak:
  tracing:
    serviceName: "keycloak"

Components wired for tracing:

Component Mechanism Default service name
IdentityHub OTEL Java agent (init container) + OTEL_* env vars identityhub
fdsc-edc OTEL_* env vars via values.yaml fdsc-edc
Keycloak OTEL_* env vars via subchart extraEnvVars keycloak
Scorpio QUARKUS_OTEL_* env vars via subchart extraEnvVars scorpio
tm-forum-api OTEL_* env vars via subchart additionalEnvVars tm-forum-api
contract-management OTEL_* env vars via subchart deployment.additionalEnvVars contract-management
marketplace OTEL_* env vars via subchart (logic-proxy) extraEnvVars marketplace
decentralizedIam Forward-compatible passthrough (no runtime effect yet) —

New values keys

The following top-level values.yaml keys are introduced:

Key Type Default Description
tracing.enabled bool false Global on/off switch for OTEL tracing
tracing.exporter.otlp.endpoint string "" OTLP endpoint (defaults to bundled collector)
tracing.exporter.otlp.protocol string "grpc" OTLP protocol (grpc or http/protobuf)
tracing.exporter.otlp.insecure bool true Disable TLS on the OTLP exporter
tracing.sampler string "parentbased_traceidratio" Trace sampler name
tracing.samplerArg string "1.0" Sampler argument (probability for ratio samplers)
tracing.resourceAttributes map {} Extra resource attributes for all workloads
tracing.propagators string "tracecontext,baggage" Propagators to use
opentelemetry-collector.enabled bool false Toggle the bundled OTEL Collector subchart
identityhub.tracing.enabled bool — Per-component tracing override
identityhub.tracing.serviceName string "identityhub" OTEL service name for IdentityHub
identityhub.tracing.javaagent.enabled bool true Attach the OTEL Java agent via init container

No existing values keys are modified or removed. Tracing is fully additive and opt-in.

Documentation

Full documentation including architecture diagrams, backend integration examples, and troubleshooting is available at Distributed Tracing with OpenTelemetry.