Contour: Support ingress.kubernetes.io/whitelist-source-range
Add support for ingress.kubernetes.io/whitelist-source-range
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#whitelist-source-range
davecheney
All 25 comments
Bumping this from 0.3, it's not directly related to SSL support
davecheney
on 15 Dec 2017
Bumping this again to 0.4 because it's not directly related to TLS
davecheney
on 4 Jan 2018
Bumping this again, sorry
davecheney
on 6 Mar 2018
Bumping this again, sorry.
davecheney
on 17 Apr 2018
I don't like leaving :+1: 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.
terinjokes
on 29 Jun 2018
May we get a timeline on when this feature will be made available?
jcrowthe
on 7 Aug 2018
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
rosskukulinski
on 8 Aug 2018
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
rosskukulinski
on 8 Aug 2018
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?
stevesloka
on 8 Aug 2018
None at all, there's a card to upgrade to envoy 1.7 slated for the 0.7
milestone -- envoy 1.7 deprecates a few grpc stanza's which cause the
config contour 0.6 sends to generate warnings pretty much continually so
that'll need to be handled gently.
On 9 August 2018 at 02:41, Steve Sloka notifications@github.com wrote:
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
https://github.com/davecheney?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/heptio/contour/issues/62#issuecomment-411472608, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA-VXVuxCCv-Ghu3p6HuBc960FtItks5uOxS0gaJpZM4Qspb5
.
davecheney
on 9 Aug 2018
I see this has been pushed back multiple milestones. Would it be possible to reprioritize this issue?
jcrowthe
on 11 Feb 2019
@rosskukulinski can you please comment
davecheney
on 11 Feb 2019
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 :).
rosskukulinski
on 14 Feb 2019
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.
davecheney
on 12 Mar 2019
This annotation is specific to ingress-nginx, do we still want to support it?
jpeach
on 15 Jan 2020
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.
terinjokes
on 15 Jan 2020
If possible I’d like to close this issue, and similar ones, which I added 24 months ago when the project started as a way of identifying the feature delta between nginx and contour 0.1.
For specific things like network whitelists, I think that should be rolled up in a general feature of “networking filtering” (waves hands), rather than being tackled piecemeal.
On 15 Jan 2020, at 1:09 pm, James Peach notifications@github.com wrote:
This annotation is specific to ingress-nginx, do we still want to support it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
davecheney
on 15 Jan 2020
I think there's a second discussion around the annotations we need to add to support users running v1beta1/Ingress.
stevesloka
on 15 Jan 2020
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.
michmike
on 2 Mar 2020
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.
cten
on 7 Apr 2020
@cten Could you please file an issue describing your use case and the problem that network filtering would solve for you?
jpeach
on 8 Apr 2020
@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.
houz42
on 24 Sep 2020
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.
ssa3512
on 18 May 2021
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.
youngnick
on 19 May 2021
I've opened #3693 to cover the feature request, please head over there.
youngnick
on 19 May 2021
Related issues
jonasrosland
·
6Comments
davecheney
·
4Comments
phylake
·
4Comments
pandeykartikey
·
3Comments
jjimenezmont
·
5Comments
Most helpful comment
If possible I’d like to close this issue, and similar ones, which I added 24 months ago when the project started as a way of identifying the feature delta between nginx and contour 0.1.
For specific things like network whitelists, I think that should be rolled up in a general feature of “networking filtering” (waves hands), rather than being tackled piecemeal.