When activating the identity-auth profile, the health and readiness probes fail with status code 401 #18568
Labels
component/zeebe
Related to the Zeebe component/team
kind/bug
Categorizes an issue or PR as a bug
version:8.6.0-alpha2
Marks an issue as being completely or in parts released in 8.6.0-alpha2
Describe the bug
With version 8.6.0-alpha1, the readiness probe may fail with a 401. In a nutshell, the security fail chain defined for the REST API is applied when processing the readiness probe request:
https://github.com/camunda/zeebe/blob/c3110d98798853f0b471a7a6bcc22a66f70e4d71/dist/src/main/java/io/camunda/zeebe/shared/security/SecurityConfiguration.java#L42-L63
Instead, it should apply the Management security filter chain that permits all incoming requests on the management port:
https://github.com/camunda/zeebe/blob/c3110d98798853f0b471a7a6bcc22a66f70e4d71/dist/src/main/java/io/camunda/zeebe/shared/security/SecurityConfiguration.java#L84-L96
However, there might be situations where the readiness probe request does not fail with a 401, and the expected Management security filter chain is applied. Why? It depends on the order in which the beans are loaded, initiated, and registered. Sometimes, they are applied in the "right" order so that the expected security filter chain is applied on the readiness probe request.
To Reproduce
identity-auth
by adding it to theconfig/application.yaml
bin/gateway.sh
http://localhost:9600/actuator/health/readiness
Expected behavior
The readiness probe succeeds with the status code 200.
Log/Stacktrace
When the beans are loaded, initiated, and registered in the "right" order, the following is logged:
Meaning, the
ServletManagementChildContextConfiguration$ServletManagementContextSecurityConfiguration.class
loads thespringSecurityFilterChain
from the application context and registers it in its management context. Afterward, the management security filter chain is initiated and registered with theWebSecurityConfiguration
, which defines a bean calledspringSecurityFilterChain
and overrides it in the management context's registry. That way, the "correct"springSecurityFilterChain
is applied when executing the readiness probe request.If the override happens in the other order, the wrong
springSecurityFilterChain
is applied.Hints
Environment:
identity-auth
The text was updated successfully, but these errors were encountered: