support specify jwt requirement

[wulianglongrd]

issue: istio/istio#43982

JwtRule add a failure_mode field to specify a Jwt requirement. This is an optional field and no breaking changes.

[istio-policy-bot]

😊 Welcome @wulianglongrd! This is either your first contribution to the Istio api repo, or it's been
awhile since you've been here.

You can learn more about the Istio working groups, code of conduct, and contributing guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[wulianglongrd]

cc @ramaraochavali

[wulianglongrd]

If this api can be merged into master, I will implement it in the istio repository.

[ramaraochavali]

@wulianglongrd Thank you . LGTM. @linsun Can you please review?

[wulianglongrd]

@howardjohn @ramaraochavali @aryan16 thanks for your review.

To be honest, I also think the naming doesn't look very good. What I want to express are three levels of tolerance for authentication(authn) results:

1. jwt must be provided and must meet the RequestAuthentication(RA) rules (for example, signature, audiences, issuer, expiration, etc... need to be verified successfully)
2. It is allowed if jwt is not provided, but if it is provided, it must meet the RA rules (this is the current behavior, and currently only supports this behavior)
3. It is allowed if jwt is not provided, and it is also allowed if it is provided and does not meet the RA rules

Would it be clearer to name it mode?

• STRICT: (1)
• PERMISSIVE: (2)
• ?: (3) what should it be named ?

What do you think?

[ramaraochavali]

Would it be clearer to name it mode?

STRICT: (1)
PERMISSIVE: (2)
?: (3) what should it be named ?

Yes. Mode/FailureMode makes sense

I like STRICT and PERMISSIVE. 3 can be IGNORE - that is ignore if jwt is missing or fails validation?

[wulianglongrd]

3 can be IGNORE - that is ignore if jwt is missing or fails validation?

Yes, and I think IGNORE is good, let's wait for what others opinion.

[costinm]

If a JWT is not provided - I don't think the authn rules should block the request. We already have a way to do this - via authz rules, no need to mix authn and authz ( authn tells how to verify credentials - authz allows or not based on presence and type of credentials ). If a JWT is provided - we should probably take 'iss' into account. The RA has an issuer field - if the JWT is from that issuer I can't see use cases to ignore it, but even if we find such a use case - it would be treated as missing JWT and again the authz rule can decide how it is handled. If the iss is not configured - there is nothing we can do and we should treat it as 'JWT not provided', again using authz to decide. So I don't think we need any of the modes - just to document proper use of authz.

…

On Tue, Apr 25, 2023 at 4:57 AM wulianglongrd ***@***.***> wrote: @howardjohn <https://github.com/howardjohn> @ramaraochavali <https://github.com/ramaraochavali> @aryan16 <https://github.com/aryan16> thanks for your review. To be honest, I also think the naming doesn't look very good. What I want to express are three levels of tolerance for authentication(authn) results: 1. jwt must be provided and must meet the RequestAuthentication(RA) rules (for example, signature, audiences, issuer, expiration, etc... need to be verified successfully) 2. It is allowed if jwt is not provided, but if it is provided, it must meet the RA rules (this is the current behavior, and currently only supports this behavior) 3. It is allowed if jwt is not provided, and it is also allowed if it is provided and does not meet the RA rules Would it be clearer to name it mode? - STRICT: (1) - PERMISSIVE: (2) - ?: (3) what should it be named ? What do you think? — Reply to this email directly, view it on GitHub <#2733 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUR2UCHTVE2DZ7SNGZMB3XC63ZHANCNFSM6AAAAAAV6X3MJY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[costinm]

BTW - the same goes for mTLS and 'PERMISSIVE' - we now use auto-mtls and hbone so mTLS is added automatically, but for regular requests without mTLS, the Authz rules will also handle blocking requests. It would be nice to treat this uniformly - TLS+JWT is equivalent with mTLS for a majority of users ( and we can still differentiate the source of auth ). Users need to get used with configuring authorization rules - and not rely on 'if it is authenticated it is implicitly authorized'.

…

On Tue, Apr 25, 2023 at 8:22 AM Costin Manolache ***@***.***> wrote: If a JWT is not provided - I don't think the authn rules should block the request. We already have a way to do this - via authz rules, no need to mix authn and authz ( authn tells how to verify credentials - authz allows or not based on presence and type of credentials ). If a JWT is provided - we should probably take 'iss' into account. The RA has an issuer field - if the JWT is from that issuer I can't see use cases to ignore it, but even if we find such a use case - it would be treated as missing JWT and again the authz rule can decide how it is handled. If the iss is not configured - there is nothing we can do and we should treat it as 'JWT not provided', again using authz to decide. So I don't think we need any of the modes - just to document proper use of authz. On Tue, Apr 25, 2023 at 4:57 AM wulianglongrd ***@***.***> wrote: > @howardjohn <https://github.com/howardjohn> @ramaraochavali > <https://github.com/ramaraochavali> @aryan16 <https://github.com/aryan16> > thanks for your review. > > To be honest, I also think the naming doesn't look very good. What I want > to express are three levels of tolerance for authentication(authn) results: > > 1. jwt must be provided and must meet the RequestAuthentication(RA) > rules (for example, signature, audiences, issuer, expiration, etc... need > to be verified successfully) > 2. It is allowed if jwt is not provided, but if it is provided, it > must meet the RA rules (this is the current behavior, and currently only > supports this behavior) > 3. It is allowed if jwt is not provided, and it is also allowed if it > is provided and does not meet the RA rules > > Would it be clearer to name it mode? > > - STRICT: (1) > - PERMISSIVE: (2) > - ?: (3) what should it be named ? > > What do you think? > > — > Reply to this email directly, view it on GitHub > <#2733 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAAUR2UCHTVE2DZ7SNGZMB3XC63ZHANCNFSM6AAAAAAV6X3MJY> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

[costinm]

If JWT verification failed for an issuer that is configured by the user - I agree, we should block. I also agree the use case of "ignore jwt validation for particular issuer" is strange. But 'allow unknown issuers' is quite valid - some applications make their own validation, or chained gateways, etc. In google cloudrun ( serverless ) has an option 'allow unauthenticated' - it will only validate the google JWTs, and let apps handle other JWTs.

…

On Tue, Apr 25, 2023 at 1:08 PM Aryan Gupta ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In security/v1/jwt.proto <#2733 (comment)>: > @@ -162,6 +171,22 @@ message JWTRule { // ``` // [Experimental] This feature is a experimental feature. repeated ClaimToHeader output_claim_to_headers = 11; // [TODO:Update the status whenever this feature is promoted.] + + // Requirement specifies a Jwt requirement. + enum Requirement { + // The requirement is satisfied if JWT is missing, but failed if JWT is presented but invalid. + // This is the default behavior. + ALLOW_MISSING = 0; + + // The requirement is always satisfied even if JWT is missing or the JWT verification fails. + ALLOW_MISSING_OR_FAILED = 1; IMO we should block the traffic if JWT verification is failed/user has applied the wrong jwt policy to make the product more secure. This case could be valid if we have jwt authentication on some routes (eg. I want to ignore jwt_authn for /health but want to keep for all the other routes). But our policy doesn't work like this. The only way this can be useful when some user wants to ignore jwt validation for some particular issuer which I don't think anyone would want. — Reply to this email directly, view it on GitHub <#2733 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAUR2TSA4PVMJTEQMAAJ7DXDAVMNANCNFSM6AAAAAAV6X3MJY> . You are receiving this because you commented.Message ID: ***@***.***>

[wulianglongrd]

Thanks for your reply, it's very helpful to me.

Our usage scenario is to use JWT for intranet service-to-service authentication (mTLS is not used for some other reasons), not for end-user authentication.

Because it is an intranet service, stability is more important to us than security. That is to say, we can tolerate the lack of security protection capabilities for a short period of time, but we cannot tolerate the interruption of production traffic due to incorrect security policies. (By the way, traffic from the external network to the internal network will pass through our gateway, and we have self-developed security components for strict security protection)

At present, our intranet services do not have standardized security protection components, and most of them use ak/sk + rbac hard-coded security protection, which brings a lot of repetitive work. Therefore, we want to borrow the security capabilities of istio to transparently replace this part of the functionality.

Because it is to add security capabilities to services running in the production environment, stability is what we are most worried about. A small mistake may cause serious online accidents. Because there are a large number of very important services with very complex dependencies, for example, a service may have more than 200+ callers (downstream service), and the number of requests per second exceeds 150,000 (150k+ QPS).

So, how to ensure the stability of introducing istio security?

dry-run, dry-run mode allows to adjust the policy and send it to the istio-proxy for execution, but when the policy is misconfigured due to a mistake, the process will not be interrupted. When we have enough confidence to determine that the security policy is correct, we turn off dry-run.

At present, authz already supports dry-run, but authn does not. This RP hopes that authn supports a capability similar to dry-run, which is also the motivation for me to submit this PR.

Do you have any suggestions? Thanks.

[hexiaodai]

Is it possible to reopen this PR?

[wulianglongrd]

cc @hanxiaop
istio/istio#43982 (comment)

[hanxiaop]

I think my case involves handling tokens from an unknown issuer under the current policy. For example, I originally required some requests to be validated by a specific issuer, but now I wish to allow requests with k8s tokens to bypass the policy, with validation occurring in the app. It is hard to write a new rule to validate that token, especially in the multicluster senario. Without an option to ignore the failure, the requests cannot pass the RA and be validated by the app.

[wulianglongrd]

I think the main purpose of this API is to provide the ability to "tolerate" authn failure. We will always need to tolerate authn failure in some cases for one reason or another.

[wulianglongrd]

I think the main purpose of this API is to provide the ability to "tolerate" authn failure. We will always need to tolerate authn failure in some cases for one reason or another.

@howardjohn @linsun @aryan16 @costinm @ramaraochavali
What do you think? If I miss any questions and haven't replied, please let me know. Thanks.

[flpanbin]

I have the same problem as @hanxiaop , we have a proxy service to forward k8s request, and this proxy service is on the backend of istio gateway. But the k8s token sent by the client cannot be authenticated by RA. There is no good solution to this problem currently. We urgently need this feature!

[istio-testing]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.