You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initially raised by @sadovnikov in #2913. Spit it out since it's another issue.
The biggest inconvenience for us is the need to register in IDP additional allowed redirect URIs for every new service deployment, which can happen even from a fix/feature branch. And, of course, the cleaning up IDP upon removal of the temporary deployments.
Attaching OIDC security policies to Gateways (all HTTP Routes of the gateway) will lead to finding a way to detach them from HTTP Routes, which do not require oauth2 authentication. These are "welcome" pages with invitations to log in. Other examples are health and metrics probes, covered or not by JWT security policies.
I tried a workaround with a fallBack HTTP route on / and a fallback security policy with the identical configuration of the OIDC issuer. It failed with "too many redirects" because, I think, the two filters used different cookies and hmac secrets.
Gateway
HTTPRoute /myapp
FallBackRoute /. (using service without any endpoints)
SecurityPolicy
target: HTTPRoute
OIDC:
issuer ...
redirectURL https://www.example.com/oauth2/callback # without /myapp in the path
SecurityPolicy (fallback)
target: FallBackRoute
OIDC:
issuer ...
redirectURL https://www.example.com/oauth2/callback # without /myapp in the path
Should OIDC configuration be extracted into a separate resource? Then, security policies can reference both HTTP Route and the filter
The text was updated successfully, but these errors were encountered:
Gateway API is changing support multiple targetRefs. However, using selector on labels instead of targetRefs[] is more in Kubernetes style and would allow pre-configuring the security policy for HTTP Routes, which can be created later.
Gateway API is changing support multiple targetRefs. However, using selector on labels instead of targetRefs[] is more in Kubernetes style and would allow pre-configuring the security policy for HTTP Routes, which can be created later.
I prefer to keep it aligned with gateway API, but let's discuss it in next week's meeting.
Initially raised by @sadovnikov in #2913. Spit it out since it's another issue.
The biggest inconvenience for us is the need to register in IDP additional allowed redirect URIs for every new service deployment, which can happen even from a fix/feature branch. And, of course, the cleaning up IDP upon removal of the temporary deployments.
Attaching OIDC security policies to Gateways (all HTTP Routes of the gateway) will lead to finding a way to detach them from HTTP Routes, which do not require oauth2 authentication. These are "welcome" pages with invitations to log in. Other examples are health and metrics probes, covered or not by JWT security policies.
I tried a workaround with a fallBack HTTP route on
/
and a fallback security policy with the identical configuration of the OIDC issuer. It failed with "too many redirects" because, I think, the two filters used different cookies and hmac secrets.Should OIDC configuration be extracted into a separate resource? Then, security policies can reference both HTTP Route and the filter
The text was updated successfully, but these errors were encountered: