fix: only allow istio gateways to set x509 client certificate header #572
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
We terminate TLS at the Istio ingress gateway, and then we In the Keycloak VirtualService, we securely extract the client certificate, urlencode it, and copy it to the
istio-mtls-client-certificate
header. Keycloak then uses this as the x509 client identity.uds-core/src/keycloak/chart/templates/uds-package.yaml
Lines 87 to 92 in e505dc9
When Istio sets the header, we also delete any existing
istio-mtls-client-certificate
header. This ensures that all users through the ingress gateway cannot forge aistio-mtls-client-certificate
when they do not use TLS client authentication.However... we only do this at the gateway and we allow in-cluster mesh communication to Keycloak to non-admin URLs.
This PR adds a DENY AuthorizationPolicy rule to the Keycloak Istio sidecar, to deny any incoming requests with a
istio-mtls-client-certificate
header not originating from the admin or tenant gateway.Credit to @rjferguson21 for asking great questions and catching this.
Type of change
Checklist before merging