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

Allow negative or duplicate group ordering #4067

Open
nabadger opened this issue Feb 24, 2025 · 0 comments
Open

Allow negative or duplicate group ordering #4067

nabadger opened this issue Feb 24, 2025 · 0 comments

Comments

@nabadger
Copy link

nabadger commented Feb 24, 2025

Describe the feature you are requesting

Currently you can configure the order of rules on the ALB using alb.ingress.kubernetes.io/group.order

If you want to introduce a rule that is always evaluated first, it suggests you have to set the group.order on ALL ingresses
in that group.

That's not possible to achieve for us (ingresses are created across different teams/apps). We also want to keep the number of groups to a minimum.

Motivation

A fairly common requirement is to introduce a default high priority rule that denies access to /metrics and common health endpoints. This is our main use-case.

Describe the proposed solution you'd like

Either allowing negative group-orders, or duplicate group orders would help us.

Option 1. Negative ordering. This means we could set the deny-rule for metrics to -1. The current default is 0, at which point we don't have to modify any other existing ingress here.

Option 2. Duplicate group-ordering. This means we could set the deny-rule for metrics to 1, and set the existing metrics to 2.

Describe alternatives you've considered

I think we were wrongly relying on the lexical ordering of ingresses. I believe it takes into account the namespace as well, so an ingress named 1-deny-monitoring-endpoints is not enough for us. It wouldn't be ideal for us to introduce a namespace a (for example) just to hold this ingress.

Contribution Intention (Optional)

-[ ] Yes, I am willing to contribute a PR to implement this feature
-[x] No, I cannot work on a PR at this time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant