More rule support for CUSTOM authorization

[andysworkshop]

(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)

Describe the feature request

Describe alternatives you've considered

Affected product area (please put an X in all that apply)

[ ] Ambient [ ] Docs [ ] Installation [ ] Networking [ ] Performance and Scalability [ ] Extensions and Telemetry [X] Security [ ] Test and Release [ ] User Experience [ ] Developer Infrastructure

Affected features (please put an X in all that apply)

[ ] Multi Cluster [ ] Virtual Machine [ ] Multi Control Plane

Looking here:

https://github.com/istio/istio/blob/990ae1d76932dafc3afb0eae50f6d40875bcb6ce/pkg/config/validation/validation.go#L1946

I see that anything involving a principal can't be used in a rule. My use case is that I have a gateway that uses a CUSTOM authorization policy routed to an oauth2-proxy. I would like to exclude requests that already have a valid bearer token in the authorization header from being sent to the oauth2-proxy. I can use a RequestAuthentication to get and validate that principal but without further support from the CUSTOM rule implementation I cannot add a from.source.notRequestPrincipals["*"] condition to pass already-valid requests through to the upstream.

[aryan16]

So your oauth2-proxy is any external authz server and it blocks the request because of some reason but you don't want to use that if you already have a valid token in your request ? Is this the usecase you're talking about ?

[andysworkshop]

So your oauth2-proxy is any external authz server and it blocks the request because of some reason but you don't want to use that if you already have a valid token in your request ? Is this the usecase you're talking about ?

No, not quite. oauth2-proxy is working just fine and blocks nothing. We are using it to protect multiple apps coming through the Istio ingress gateway; some old, some new, some vendor-supplied. The problem is that some apps (e.g. vendor-supplied) will have already done the login flow with Keycloak and we cannot stop that. By the time they come to our protected Istio gateway to make API calls they already have a valid id-token presented as a bearer token in the Authorization header and should be allowed to pass without redirection to oauth2-proxy.

With the current implementation they'll be sent off to Keycloak again via oauth2-proxy because they don't have the magic oauth2 cookie. This is a poor user-experience as well as adding un-necessary latency.

[njlaw]

I have a slightly different use case, but the same request:

1. If the request is coming from the Gateway (external to the cluster), I want it to be sent directly to the workload because user authentication is handled by the workload itself (this may change in the future, but we're still migrating). This currently works without any issue with action: 'ALLOW', ... source: { principals: ['cluster.local/ns/namespace/sa/gateway'] }.
2. If the request is coming from other services in the cluster, I want to use ext_authz, via Ory Oathkeeper to generate an appropriate JWT for the service (m2m). This does not work, because action: 'CUSTOM', provider: { name: 'oathkeeper' }, ... source: { notPrincipals: ['cluster.local/ns/namespace/sa/gateway'] } is rejected with "From.NotPrincipals is currently not supported with CUSTOM action". I tried to use a when condition with source.principal but that was rejected as well.

As a work-around I can send all requests via ext_authz, but again, that means increased latency for requests that don't need to be handled externally.

[sakirma]

Bumping this issue since I am experiencing this issue as well where I need rules for my CUSTOM authorizationpolicy.

[istio-policy-bot]

🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2023-11-08. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.

Created by the issue and PR lifecycle manager.