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.
Adds support for client TLS certificate validation at application layer in Authorino for connections with the protected service and Authorino raw HTTP authorization interface relying on Mutual Transport Layer Security (mTLS) for authentication.
Closes #8
Verification steps
Create a cluster, build and deploy the apps:
Create a CA certificate and store it in a secret to be discovered by Authorino:
openssl req -x509 -sha256 -days 365 -nodes -newkey rsa:2048 -subj "/CN=talker-api-ca" -keyout /tmp/ca.key -out /tmp/ca.crt kubectl create secret tls talker-api-ca --cert=/tmp/ca.crt --key=/tmp/ca.key kubectl label secret talker-api-ca authorino.kuadrant.io/managed-by=authorino app=talker-api
Redeploy Envoy acknowledging the CA cert and enabling client certificate validation:
(This steps sucks, but otherwise Envoy will not pass the client peer certificate to Authorino in the payload to external authorization. Effectively, we're adding redundant client cert validation – i.e. Envoy doing it at L4 and Authorino at L7. For a hope on finding a way to avoid this, see envoyproxy/envoy#20563 (comment).)
Create the AuthConfig:
Try the API with a TLS certificate signed by the trusted CA:
Try the API with a TLS certificate signed by the trusted CA, though missing an authorized Organization:
Try the AuthConfig via raw HTTP authorization interface:
Expose the interface:
kubectl port-forward service/authorino-authorino-authorization 5001:5001 &
Consume the raw HTTP authorization interface with a TLS certificate signed by the trusted CA:
Consume the raw HTTP authorization interface with a TLS certificate signed by a unknown authority:
Revoke an entire chain of certificates:
Even if the deleted root certificate is still cached and accepted at the gateway, Authorino will revoke access at application level immediately.
Try the API again with a previously accepted certificate to verify:
Cleanup: