-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Return 500 when xPolicy translation fails #3873
Comments
im a +1 to return 500 if a CTP, BTP or EETP policy tied to a route cannot be translated . This would match the behavior of filters https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io%2fv1.HTTPRouteFilter
|
+1 on this |
+1 |
+1 |
Should we also consider BackendTLSPolicy here? I suppose that if a backend requires TLS and we fail to translate BTLSP, the upstream connection would just fail. Maybe if/when gateway-level backend TLS configuration is supported, we will see a behavior of fallback to wrong gateway-level defaults that reduce security (e.g. use a system trust store instead of a specific trusted CA). |
While not directly related, I think Extension Server should have a similar "fail close" option. I'm using the Extension Server to automatically add a default Authz filter to all Listeners. If the Extension Server fails in some way (isn't available, fails during the processing), then the current behavior means that the Listener will be active without the filter (and without the security properties). With an option to "block" the Listener if the Extension Server fails, than the security boundary provided would be maintained. |
Hi @logan-hcg , |
hi @alexwo , unfortunately that control knob is for Extension Polices, not Extension Manager / Extension Server (seems to be referred to interchangeably) |
@logan-hcg could you open a separate issue for the Extension Server |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. |
Description:
The current behaviors when xPolicies translation fails:
Options that we have:
For SecurityPolicy, it's reasonable to default to fail close as fail open poses a security risk. A configuration knob can be added to each SecurityPolicy, allowing users to customize this behavior if needed.
For BackendTrafficPolicy and EnvoyExtensionPolicy, there are two strategies:
We may also need to decide the default behavior for the ClientTrafficPolicy and EnvoyPatchPolicy failure, should we fail the targeted Gateways/Listeners?
Return 500 when BackendTrafficPolicy translation fails #4061
Return 500 when EnvoyExtensionTrafficPolicy translation fails #4062
Return 500 when BackendTLSPolicy translation fails #4087
Return 500 when ClientTrafficPolicy translation fails #4153
[optional Relevant Links:]
The text was updated successfully, but these errors were encountered: