SSO/OIDC integration

Read the integration and license boundary first. The chart uses the authorization-code flow and renders the primary OIDC realm on every enabled Elasticsearch node set, Kibana’s login providers, and the hooked sso-secret. ECK loads that Secret through elasticsearch.secureSettings; user secure-setting references are preserved after the SSO reference.

Configuration entry points

In umbrella v1 configuration, set enablement, primary client identity, and provider integration under packages.elasticsearchKibana.sso. The umbrella maps the global provider defaults to the chart. Package-specific overrides belong under packages.elasticsearchKibana.values.sso. For direct chart use, set sso directly.

In the package values, only primary provider host and realm are nested under sso.oidc. Primary issuer, auth_url, token_url, userinfo_url, jwkset_url, claims, and scopes are direct children of sso, not of sso.oidc. Consult package values for those Big Bang-owned inputs and Elastic OIDC guidance for protocol, claims, and underlying realm semantics.

The chart’s sso.redirect_url is a host-style value, without https://: the helper adds the scheme, callback /api/security/oidc/callback, and logout /login paths. When unset it uses the first routes.inbound.kibana.hosts entry. Keep the external route, Kibana public base URL, and provider registration consistent.

These package values show a primary Keycloak realm without the historical /auth prefix. Replace the endpoints with the realm’s discovery values; this is non-secret configuration, not a complete SSO deployment:

sso:
  enabled: true
  client_id: kibana
  redirect_url: kibana.example.com
  oidc:
    host: sso.example.com
    realm: platform
  issuer: https://sso.example.com/realms/platform
  auth_url: https://sso.example.com/realms/platform/protocol/openid-connect/auth
  token_url: https://sso.example.com/realms/platform/protocol/openid-connect/token
  userinfo_url: https://sso.example.com/realms/platform/protocol/openid-connect/userinfo
  jwkset_url: https://sso.example.com/realms/platform/protocol/openid-connect/certs
  endsession_url: https://sso.example.com/realms/platform/protocol/openid-connect/logout
  claims_principal: preferred_username
  claims_group: groups
  claims_mail: email
  requested_scopes:
    - openid
    - profile
    - email
kibanaBasicAuth:
  enabled: true

Supply sso.client_secret separately through encrypted/managed package values, and align the route with kibana.example.com. Register the exact callback https://kibana.example.com/api/security/oidc/callback and logout destination https://kibana.example.com/login. The scopes/claims must be supported and released by the provider; groups may require a provider mapper. License, trust, network access, role mappings, and validated recovery login remain prerequisites. In the umbrella, also use its package SSO enablement so generated egress and provider defaults stay aligned; a values.sso overlay alone does not do that.

Multiple providers and authorization

• sso.additional_oidc is a map keyed by unique realm name. Each entry supplies its own client identity, discovery endpoints, claims, and optional login label. Non-secret settings and encrypted client secrets can merge by realm key.
• The primary provider is first. Additional providers follow in alphabetical realm order, then basic authentication when kibanaBasicAuth.enabled is true. Additional realms must not reuse the primary realm name.
• The primary requested-scopes default is openid. Additional realms fall back to openid, profile, email, and groups if scopes are omitted. Override scopes to match what the provider actually supports and releases.
• The Secret always contains a primary client-secret entry; additional entries are emitted when a client secret is supplied. Keep every required client secret in managed/encrypted inputs; an empty chart value is not proof of a working public-client flow.
• Role mappings are not created by these templates. Configure least-privilege mappings for the intended realm and claims. Retain basic login until both SSO authorization and recovery access work. Keycloak has a provider checklist.

For example, add a second provider alongside the primary configuration using these package values. The map key is the Elasticsearch realm name, not an array index:

sso:
  additional_oidc:
    partner:
      client_id: kibana-partner
      issuer: https://sso.example.com/realms/partner
      auth_url: https://sso.example.com/realms/partner/protocol/openid-connect/auth
      token_url: https://sso.example.com/realms/partner/protocol/openid-connect/token
      userinfo_url: https://sso.example.com/realms/partner/protocol/openid-connect/userinfo
      jwkset_url: https://sso.example.com/realms/partner/protocol/openid-connect/certs
      endsession_url: https://sso.example.com/realms/partner/protocol/openid-connect/logout
      requested_scopes:
        - openid
        - profile
        - email
      claims_principal: preferred_username
      claims_group: groups
      claims_mail: email
      login_label: Partner login

Replace the endpoints/claims with verified discovery and claim-mapper settings. Supply sso.additional_oidc.partner.client_secret separately in protected values, under the same map key. This fragment does not enable primary SSO or provision the provider; it reuses the primary callback/logout destinations and still needs license, trust, network access, and realm-specific role mappings.

Network access and custom CA

Elasticsearch contacts the IdP’s token, user-info, and JWKS endpoints; the browser also needs the authorization endpoint. The umbrella maps the global sso egress definition when umbrella SSO is enabled. If enabling SSO only in package overlays or adding providers, review network policies explicitly: overlay enablement alone does not change the umbrella’s SSO egress condition.

Under a sidecar REGISTRY_ONLY policy, register external hosts using the package’s routes.outbound or custom ServiceEntries and allow the destination IPs/ports in network policies. Mesh registration and L3/L4 permission are separate controls; STRICT mTLS alone is not a generic external-HTTPS deny rule.

For a private IdP CA, provision a CA Secret in the workload namespace. Use each enabled Elasticsearch node set’s volumes and volumeMounts to mount it read-only, then point sso.cert_authorities (or the additional realm’s cert_authorities) at the mounted file. There is no elasticsearch.common.volumes entry point. Cover optional ingest, ML, and coordinating nodes as well as master/data; Kibana does not consume the Elasticsearch realm CA setting. Follow upstream OIDC TLS guidance rather than disabling certificate validation.

For the default master/data topology, these package values mount a separately managed Secret named elasticsearch-oidc-ca, containing key ca.crt, and set the realm’s trust path:

sso:
  cert_authorities:
    - /usr/share/elasticsearch/config/oidc-ca/ca.crt
elasticsearch:
  master:
    volumes:
      - name: oidc-ca
        secret:
          secretName: elasticsearch-oidc-ca
          items:
            - key: ca.crt
              path: ca.crt
    volumeMounts:
      - name: oidc-ca
        mountPath: /usr/share/elasticsearch/config/oidc-ca
        readOnly: true
  data:
    volumes:
      - name: oidc-ca
        secret:
          secretName: elasticsearch-oidc-ca
          items:
            - key: ca.crt
              path: ca.crt
    volumeMounts:
      - name: oidc-ca
        mountPath: /usr/share/elasticsearch/config/oidc-ca
        readOnly: true

Provision the Secret in logging (or the actual workload namespace) first. Merge these entries with existing volumes/mounts rather than discarding them; the lists replace user entries. Repeat the mount for every additionally enabled node set. This fragment supplements the SSO configuration; it neither enables SSO nor configures Kibana’s own CA trust. Additional realms must set their own cert_authorities to the mounted path when needed.

Configuration precedence and checks

_helpers.tpl, _kibana-config.tpl, and sso-secret.yaml define the wiring. kibana.config is deep-merged after the chart’s generated provider/base-URL/Fleet configuration, so raw user config can override it. Avoid contradictory provider definitions. See the SSO unit suite and maintenance for render versus deployed validation.