matrixAuthenticationService.additional.* values are ignored for MAS ConfigMap (no user-config.yaml rendered)

[d-ryabov]

Describe the bug
When using the matrix-stack-26.3.2 chart, matrixAuthenticationService.additional.* values are accepted by Helm (visible in helm get values), but they are not rendered into the ess-matrix-authentication-service ConfigMap. As a result, it is not possible to extend the Matrix Authentication Service configuration via additional files, even though this mechanism works for Synapse.

Environment

• Chart: matrix-stack-26.3.2
• App: matrix-authentication-service 1.14.0
• Deployed via: helm upgrade using the OCI chart from ghcr.io/element-hq/ess-helm/matrix-stack
• Namespace: ess

To Reproduce
Steps to reproduce the behavior:

1. Install or upgrade the chart:

   helm upgrade --namespace ess ess \
     oci://ghcr.io/element-hq/ess-helm/matrix-stack \
     -f auth.yaml \
     --wait --debug --timeout 5m

   where auth.yaml contains the matrixAuthenticationService.additional.user-config.yaml.config block as shown above.

2. Verify that values are present:

   helm get values ess -n ess

   Check that matrixAuthenticationService.additional.user-config.yaml.config is listed.

3. Inspect the rendered manifest:

   helm get manifest ess -n ess | sed -n '/name: ess-matrix-authentication-service/,/---/p'

4. Observe that the ConfigMap only contains mas-config-overrides.yaml and mas-config-underrides.yaml, with no key created from matrixAuthenticationService.additional.user-config.yaml.

Observed behavior

• The rendered manifest for ess-matrix-authentication-service (via helm get manifest ess -n ess) contains only two keys in the ConfigMap data section:

  mas-config-underrides.yaml: |
    policy:
      
        admin_clients: []
        admin_users: []
        client_registration:
          allow_host_mismatch: false
          allow_insecure_uris: false

  mas-config-overrides.yaml: |
    http:
      public_base: "https://account.matrix.domain"
      listeners:
        ...
    database:
      ...
    telemetry:
      ...
    matrix:
      ...
    secrets:
      ...

• No additional key like user-config.yaml (or any other file derived from matrixAuthenticationService.additional.*) is present in this ConfigMap.
• For Synapse, additional.user-config.yaml is rendered as separate keys (e.g. 05-main.yaml, log_config.yaml), so the additional mechanism clearly works there but not for MAS.

Expected behavior

• The matrixAuthenticationService.additional.* values should be rendered into the ess-matrix-authentication-service ConfigMap as additional keys, similar to how additional is handled for Synapse.
• For the example above, there should be a user-config.yaml (or equivalent) entry under `` so that MAS can consume this config (typically mounted into /config.d/).

Screenshots
Not applicable.

Desktop (please complete the following information):
Not applicable.

Smartphone (please complete the following information):
Not applicable.

Additional context
There is currently no documented way (in this chart version) to extend MAS configuration via additional files, which prevents configuring features like captcha, http.trusted_proxies, token TTLs, etc., in the same way as described in the ESS documentation.

[benbz]

For both Synapse and Matrix Authentication Service, additional config that is provided inline in the Helm values is rendered into a Secret as they could contain credentials. 05-main.yaml and log_config.yaml that you see in the Synapse ConfigMap are chart managed config, not additional config.

Additional configuration is supported and working with MAS AFAICT based on the below:

$ cat charts/matrix-stack/user_values/additional-mas.yaml
matrixAuthenticationService:
  extraEnv:
  - name: "DEBUG_RENDERING"
    value: "1"
  additional:
    test.yaml:
      config: | 
        experimental:
          access_token_ttl: 300000
          compat_token_ttl: 300000
          inactive_session_expiration:
            ttl: 32400
            expire_compat_sessions: true
            expire_oauth_sessions: true
            expire_user_sessions: true

$ helm upgrade -i -n ess ess charts/matrix-stack -f charts/matrix-stack/ci/example-default-enabled-components-values.yaml -f charts/matrix-stack/ci/test-cluster-mixin.yaml -f charts/matrix-stack/user_values/additional-mas.yaml
Release "ess" has been upgraded. Happy Helming!
NAME: ess
LAST DEPLOYED: Tue Apr  7 16:04:13 2026
NAMESPACE: ess
STATUS: deployed
REVISION: 2
DESCRIPTION: Upgrade complete
TEST SUITE: None
NOTES:
ESS Community 26.3.3-dev
....


$ kubectl -n ess get secret ess-matrix-authentication-service -o jsonpath='{.data.user-test\.yaml}' | base64 -d
experimental:
  access_token_ttl: 300000
  compat_token_ttl: 300000
  inactive_session_expiration:
    ttl: 32400
    expire_compat_sessions: true
    expire_oauth_sessions: true
    expire_user_sessions: true

$ kubectl -n ess logs deployments/ess-matrix-authentication-service render-config
Rendering config to file: /conf/mas-config.yaml
database:
    uri: postgresql://matrixauthenticationservice_user:XXXX@ess-postgres.ess.svc.cluster.local.:5432/matrixauthenticationservice?sslmode=prefer&application_name=matrix-authentication-service
experimental:
    access_token_ttl: 300000
    compat_token_ttl: 300000
    inactive_session_expiration:
        expire_compat_sessions: true
        expire_oauth_sessions: true
        expire_user_sessions: true
        ttl: 32400
...

[d-ryabov]

I can see my user-user-config.yaml correctly in the ess-matrix-authentication-service Secret, but Cloudflare Turnstile is not visible on the login UI and there are no log messages mentioning captcha.

Since the MAS container image does not contain a shell (no sh in PATH), what is the recommended way to inspect the final /conf/mas-config.yaml rendered by the render-config init container?

Is there a way to enable more verbose logging for the render-config job (e.g. dumping the merged config), or another method you suggest to verify that the captcha block from user-user-config.yaml is actually merged into the final configuration?

[benbz]

matrixAuthenticationService:
  extraEnv:
  - name: "DEBUG_RENDERING"
    value: "1"

Is the way to make the render-config init-container log the merged config.