support specify jwt requirement #2733
Conversation
|
😊 Welcome @wulianglongrd! This is either your first contribution to the Istio api repo, or it's been You can learn more about the Istio working groups, code of conduct, and contributing guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
istio-testing
added
the
size/M
wulianglongrd
changed the title
wulianglongrd
force-pushed
the
JwtRule-allow
branch
from
93f0ade
to
f4e15d8
Compare
wulianglongrd
changed the title
istio-testing
added
size/L
wulianglongrd
changed the title
|
If this api can be merged into master, I will implement it in the istio repository. |
|
@wulianglongrd Thank you . LGTM. @linsun Can you please review? |
|
@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:
Would it be clearer to name it
What do you think? |
STRICT: (1) Yes. Mode/FailureMode makes sense I like STRICT and PERMISSIVE. 3 can be IGNORE - that is ignore if jwt is missing or fails validation? |
Yes, and I think |
|
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: ***@***.***>
|
|
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: ***@***.***>
>
|
|
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:
***@***.***>
|
|
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. |
istio-testing
added
the
needs-rebase
istio-policy-bot
added
the
lifecycle/automatically-closed
|
Is it possible to reopen this PR? |
wulianglongrd
added
the
do-not-merge/work-in-progress
wulianglongrd
force-pushed
the
JwtRule-allow
branch
from
94de488
to
0ad71b5
Compare
istio-testing
added
size/M
wulianglongrd
removed
do-not-merge/work-in-progress
|
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. |
|
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 |
|
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
added
the
needs-rebase
|
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. |
|
Any update on when/if this would be considered and merged? |
Sorry, I didn't push this PR because I don't have an urgent need for it right now (I implemented it in my company's private branch a long time ago), if you want to get this feature, please convince TOC to accept it. If you have any suggestions for improvements to this PR, feel free to comment, I'll be happy to improve it. |
issue: istio/istio#43982
JwtRule add a
failure_modefield to specify a Jwt requirement. This is an optional field and no breaking changes.