Skip to content
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

Opt-out from SecurityPolicies #4892

Closed
nbrns opened this issue Dec 11, 2024 · 3 comments
Closed

Opt-out from SecurityPolicies #4892

nbrns opened this issue Dec 11, 2024 · 3 comments
Labels

Comments

@nbrns
Copy link

nbrns commented Dec 11, 2024

Description: I would like to apply a default security policy, e.g. on gateway level, and opt-out from this policy for specific routes.

Example: I have a set of HTTP routes and all of them should be secured, e.g. via basic auth. This works well by applying a security policy on gateway level. Now, for a single HTTP route, I would like to opt-out from this policy and make it available without any security policy

My current solution ideas:

  1. Create another listener on the gateway, apply the default security policy to a specific listener via sectionName -> this is not supported for security policies yet
  2. Create a separate gateway -> while this works, it has some implications, e.g. additional pods and services (LoadBalancers)
  3. Use label selectors to target only routes with specific labels -> this is an opt-in solution, but does not create a "secure-by-default" situation

Is there another way to accomplish it? Am I missing something? If not, as far as I see, either adding an exclusive or negated matchLabels on targetSelectors or adding support for sectionName in targetRefs would resolve my request.

@nbrns nbrns added the triage label Dec 11, 2024
@arkodg
Copy link
Contributor

arkodg commented Dec 11, 2024

does creating an empty SecurityPolicy and targeting that HTTPRoute work ?

@nbrns
Copy link
Author

nbrns commented Dec 11, 2024

@arkodg yes, that does indeed work! Nice catch, that helps a lot, thanks!

As this behaviour is not documented (at least I couldn't find it), can I rely on it to work in the future? Should this behaviour be added to the documentation?

@arkodg
Copy link
Contributor

arkodg commented Dec 11, 2024

great ! yeah it should continue to work, we should document this as part of #2072

@arkodg arkodg closed this as completed Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants