Closed mstruk closed 1 year ago
Does this pertain to a reported issue (since I assume the motivation is not merely hypothetical)?
It's not a hypothetical. I just realised though that fetching grants is not the only place that can experience this. There are also introspection endpoint, user endpoint, token requests for OAuth over PLAIN they can all experience these glitches, and the solution should be across the board with single config option covering it all. Thus, there should also be oauth.http.retries
setting covering all of those. The current solution only fully addresses OAuth using JWKS endpoint + KeycloakRBACAuthorizer.
Looks like the last CI fail is an intermittent failure.
More generally about this PR not addressing the whole problem of intermittent failure in communication with authorization server, I suggest we merge it, and make separate PRs for the other parts that need to be covered. The authorizer is configured differently from listeners anyway, so it has to use strimzi.authorization.*
prefix rather than oauth.*
used for sasl.jaas.conf
parameters.
But maybe we should rename the config option to strimzi.authorization.http.retries
so that it's aligned with oauth.http.retries
added later by another PR.
Introduced
strimzi.authorization.http.retries
broker option that signifies how many retries to attempt immediately in the same thread if the grants HTTP request fails. Status errors 401 and 403 don't trigger a re-attempt, all other failures do.This feature is useful in the environment where network is glitchy or a reverse proxy in front of the Keycloak server produces intermittent failures. Such an environment may be a given and the application developers may have no other option but to work within such constraints.
Signed-off-by: Marko Strukelj marko.strukelj@gmail.com