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
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
The text was updated successfully, but these errors were encountered:
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 ingressesin 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 is0
, 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 to2
.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 namespacea
(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
The text was updated successfully, but these errors were encountered: