design: add JWT verification design doc #4711
Conversation
Updates projectcontour#4636. Signed-off-by: Steve Kriss <[email protected]>
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #4711 +/- ##
==========================================
+ Coverage 76.08% 76.09% +0.01%
==========================================
Files 140 140
Lines 13073 13073
==========================================
+ Hits 9946 9948 +2
+ Misses 2873 2871 -2
Partials 254 254
|
tsaarni
left a comment
There was a problem hiding this comment.
Great work and glad to see this feature coming! I added few questions.
|
|
||
| ## High-Level Design | ||
| Contour's `HTTPProxy` resource will get a new optional field, `spec.virtualhost.jwtProviders`, to define the details of how to verify JWTs for requests to a given virtual host. | ||
| This field will only be supported for virtual hosts for which Envoy is terminating TLS. |
There was a problem hiding this comment.
Is this limitation because in non-TLS case the token could be eavesdropped? I guess technically the Envoy filter has no direct relation to TLS transport?
There was a problem hiding this comment.
Mostly because there is only one filter chain for all plain HTTP virtualhosts, so only one filter instance and no "straightforward" way to configure different providers for different vhosts
(if we want to offer this, maybe we could combine the providers for different vhosts all together in the same filter configuration, but make their names unique etc.)
There was a problem hiding this comment.
Yeah it's really for both of those reasons. I do think we could make it work for plain HTTP -- if we add an :authority header match for each requirement, then we should be able to scope things for the right vhosts - but we'd have to be careful to ensure no pollution across vhosts. My preference would be to not implement it unless there's a strong use case for it.
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
Signed-off-by: Steve Kriss <[email protected]>
sunjayBhatia
left a comment
There was a problem hiding this comment.
I'm a fan of the proposed structure around inclusion since it leaves the defaulting in the hands of the owner of the root httpproxy, owners of included child httpproxies can still opt out, or be restricted by gatekeeper policies, and still offers the flexibility of allowing multiple jwt providers to be available
I think that and using route matching to configure jwt verification opt in/out work great together
anything outstanding left to sort out? i think theres coverage of validating the jwks endpoint w/ a CA etc., and the remaining discussions are around possible additional features we may add? (one small thing there is if someone were running an authorization server in-cluster they may want to use a service to generate the Envoy cluster, so that could be a note for a later feature to add)
I added some fields to JWT provider for JWKS TLS validation. Good point on the in-cluster JWKS endpoint, I think that could be a good follow-on feature to add support for. I've tried to leave room in the API for additions so that we can tackle additional features as needed, just wanted to start with the basics. |
| The structure of this field will be similar to the [Envoy filter's providers field](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/jwt_authn/v3/config.proto#envoy-v3-api-msg-extensions-filters-http-jwt-authn-v3-jwtauthentication), with some simplifications. | ||
| Specifically, a provider will define an issuer, 0+ audiences, and a JSON Web Key Set (JWKS) that can be used to verify a JWT (see [the Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/jwt_authn/v3/config.proto#envoy-v3-api-msg-extensions-filters-http-jwt-authn-v3-jwtprovider) for more information). | ||
| Any number of providers can be defined for a virtual host, to allow different routes to be verified differently. | ||
| At most one provider can be marked as the "default", meaning it will automatically be applied as a requirement to all routes unless they explicitly opt out (more below). |
There was a problem hiding this comment.
What do you think if instead of separate field default: true we would pick the default provider by name name: default. It would avoid the error case where more than one providers have default: true set. However, the provider named default then becomes "magically" applied by default, which of course could be considered as bit surprising by users? I'm unsure myself. Maybe putting a special meaning to a name is a bad idea, but I wanted to hear what you think?
There was a problem hiding this comment.
Yeah, I've definitely used that pattern before for similar situations -- it does have the advantage of not requiring a separate flag which is nice. When I used it before, it was for the names of CR's themselves, which meant that the API server would prevent multiple resources from being created with the name "default"; in this case, though, a user could name multiple JWT providers "default" so we'd still need code to check for that situation & set an error condition. I think since we'd have to do that runtime check regardless, I probably lean towards keeping the flag as I think it is a little less "magical", but open to others' thoughts here too.
|
Looks like this is ready to merge; any further feedback can always be addressed with the implementation. |
Updates #4636.
Signed-off-by: Steve Kriss [email protected]