Support ingress.kubernetes.io/whitelist-source-range about contour HOT 25 CLOSED

from contour.

I don't like leaving 👍 comments, for the obvious reason, but I'd love to have this feature. Assuming the ingress is used in such a way the client IP is preserved (eg, a GKE LB, nodeports) did you have in mind a place to slot this in? I don't mind opening a PR to add it.

from contour.

@jpeach I may describe my use case here if you are interested in.

I deployed several services like prometheus, grafana, alertmanager in our kubernetes cluster, and exposed them with contour ingress. Certainly they should not be available to public. The grafana was configured with an external OSS, while prometheus and alertmanger do not have any authn/ahthz functions. So I have waitted a long time for another feature request (external auth service #432). But actually I do not care about who in my group visited the prometheus. No body except my group can visit the prometheus is all I want. So "whitelist-source-range" annotaion or "networking filtering" is a better ans easier solution for me if any of them is available.

from contour.

Bumping this from 0.3, it's not directly related to SSL support

from contour.

Bumping this again to 0.4 because it's not directly related to TLS

from contour.

Bumping this again, sorry

from contour.

Bumping this again, sorry.

from contour.

May we get a timeline on when this feature will be made available?

from contour.

Hi @jcrowthe - we're in the middle of a pretty significant rework of Contour internals for 0.6. From an end-user perspective, the new IngressRoute CRD design will help unlock development of new features like this one.

We still need to prioritize which new features will also land in 0.6 and which will slip to a later release. Once I know more from a time-frame perspective, I'll get back to you

from contour.

From a dev perspective, I think the Envoy v2 RBAC API may support this feature: https://www.envoyproxy.io/docs/envoy/v1.7.0/api-v2/config/rbac/v2alpha/rbac.proto#envoy-api-msg-config-rbac-v2alpha-rbac

from contour.

The RBAC route looks like the proper implementation, but I think we need to upgrade to Envoy 1.7. Any reservations to do that @davecheney?

from contour.

from contour.

I see this has been pushed back multiple milestones. Would it be possible to reprioritize this issue?

from contour.

@rosskukulinski can you please comment

from contour.

Hi @jcrowthe. Thanks for the poke! This feature request is on my radar, but I'm currently prioritizing a few other more commonly requested features -- including some you've also asked for :).

from contour.

I know this is an important feature for people, but without a design doc or input from product I cannot commit to do it in the 0.11 milestone so removing the milestone.

from contour.

This annotation is specific to ingress-nginx, do we still want to support it?

from contour.

Other ingress controllers than nginx support this annotation. traefik supports (documented as traefik.ingress.kubernetes.io/whitelist-source-range, but believe it supports the short form as well). I believe the HAProxy controller also does.

from contour.

I think there's a second discussion around the annotations we need to add to support users running v1beta1/Ingress.

from contour.

Closing this ticket as there has not been a lot of requests for this feature and we can't prioritize it in the backlog. If a significant number of users ask for this, we can consider it again.
If you feel strongly on this ticket, please attend the Contour community meeting to discuss your scenario with our team.

from contour.

I understand why this was closed, and I like @davecheney 's suggestion above. Is there an issue I can track for "networking filtering"? I tried searching but came up empty handed.

from contour.

@cten Could you please file an issue describing your use case and the problem that network filtering would solve for you?

from contour.

Given this issue is closed and there doesn't appear to be any implementation, has it been decided that contour simply will not support an IP allowlist for ingress? This seems like a pretty core feature of a gateway service (the ability to allow/deny traffic based on source IP). We are looking to use contour for ingress in our kubernetes cluster but similar to the case laid out by @houz42 some of the services are internal only and should only be accessible from other services owned by other internal teams (which are not necessarily in kubernetes). IP whitelisting seems ideal for these.

from contour.

No, we have not ruled out doing some sort of IP allowlist (and blocklist), but we should open an issue to cover that. I'll do that now, then close this one out again and we can talk more there @houz42 and @ssa3512. Thanks for your feedback here, it's really appreciated.

from contour.

I've opened #3693 to cover the feature request, please head over there.

from contour.