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

Support IP whitelisting #459

Open
richarddli opened this issue May 23, 2018 · 13 comments

Comments

Projects
None yet
10 participants
@richarddli
Copy link
Contributor

commented May 23, 2018

Feature request based on this comment: https://medium.com/@futuredon/hi-richard-41fd2a6d35c2

The default NGINX ingress supports IP whitelisting. See http://container-solutions.com/kubernetes-quick-tip/ for details. We could do this too.

@plombardi89

This comment has been minimized.

Copy link
Contributor

commented May 30, 2018

Quite possibly non-trivial. Nginx has support for IP black and white lists using allow and deny rules when it's configured with the http_access module which is part of the default install.

There's probably a couple paths we could take and they may involve contributing upstream to Envoy. I didn't see anything to indicate this exists already.

@richarddli

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2018

I'm rereading the Container Solutions blog post, and I wonder how the NGINX controller does this in a real-world situation where you use a LoadBalancer. The functionality seems only useful if you're deploying as a NodePort -- otherwise, you really want to do something with X-Forwarded-For (which we support via regex_header).

@plombardi89

This comment has been minimized.

Copy link
Contributor

commented May 30, 2018

Nginx has configuration directives to handle X-Forwarded-For... we used it back in the MCP days. My guess is it configures thing similarly to this (it wouldn't be that hard to find out either):

upstream backend {
  server 127.0.0.1:52689;
}

server {
  listen 80      proxy_protocol;
  listen [::]:80 proxy_protocol;

  server_name backend_proxy;

  real_ip_header   X-Forwarded-For;
  set_real_ip_from 10.0.0.0/16;

  location / {
    proxy_pass          http://backend;
    proxy_http_version  1.1;
    proxy_set_header    X-Real-IP       $proxy_protocol_addr;
    proxy_set_header    X-Forwarded-For $proxy_protocol_addr;
    #proxy_set_header    X-Real-IP $remote_addr;
    #proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    Host $http_host;
  }

  location /rtp {
    proxy_pass          http://backend;
    proxy_http_version  1.1;
    proxy_set_header    X-Real-IP       $proxy_protocol_addr;
    proxy_set_header    X-Forwarded-For $proxy_protocol_addr;
    #proxy_set_header    X-Real-IP $remote_addr;
    #proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    Host $http_host;
    proxy_set_header    Upgrade $http_upgrade;
    proxy_set_header    Connection "upgrade";
  }
}

#
# This server block is only needed if you need Proxy Protocol support and use a classic
# ELB with TCP+TLS because of web sockets. The load balancer health check mechanism does not
# actually send the requests through the load balancer in front of the service. This means the
# health check traffic that reaches the server does not adhere to the proxy protocol and when
# Nginx is configured to expect proxy protocol requests then things do not work as expected.
#
# Read more about Proxy Protocol on Amazon:
#   - http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-proxy-protocol.html
#

server {
  listen 81;
  listen [::]:81;
  server_name backend_health_proxy;

  location = /health {
    proxy_pass          http://backend;
      proxy_http_version  1.1;
    proxy_set_header    X-Real-IP $remote_addr;
    proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header    Host $http_host;
  }
}
@neurot1cal

This comment has been minimized.

Copy link

commented Jun 25, 2018

+1 on this ;)

@suulperi

This comment has been minimized.

Copy link

commented Jun 26, 2018

I would see IP whitelisting as a wonderful feature. I can see it useful for limiting APIs for certains source ip addresses. +1 for this one.

@richarddli

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2018

Example use case: Add ACL for specific subnets to a specific service. For example, only allow 10.3.5.x to access Jenkins.

@sbrichardson

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2018

I was just checking out the Envoy docs, you could potentially use the rate limit service, similar to the auth service? Or just use the auth service also, since it's really just a pass/fail check. Delegating to a service would allow you eliminate entire countries/subnets or other magic, know bad actors, 3rd party sync services etc. That's more where we are, so a bit out of scope.

I could see their being benefit to adding a basic whitelist/blacklist support built in so that you don't need to roll your own service.

@kflynn

This comment has been minimized.

Copy link
Contributor

commented Jul 6, 2018

Note that there's a V2-only RBAC filter, too (https://www.envoyproxy.io/docs/envoy/v1.7.0/configuration/http_filters/rbac_filter) that appears to be able to do this.

@mtbdeano

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2018

I would like to add the loadBalancerSourceRanges key to the LoadBalancer resource created by ambassador, this allows AWS ELB's to be much more secure. https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/#restrict-access-for-loadbalancer-service Does this fit into this issue? Or is it separate?

@plombardi89

This comment has been minimized.

Copy link
Contributor

commented Aug 30, 2018

@mtbdeano you can just use a custom Service manifest with that attribute added to route into Ambassador. This is about blocking IP's upon request by Ambassador/Envoy. That would be blocking IP's at the hardware / cloud firewall level.

@gertvdijk

This comment has been minimized.

Copy link
Contributor

commented Feb 5, 2019

Note that there's a V2-only RBAC filter, too (https://www.envoyproxy.io/docs/envoy/v1.7.0/configuration/http_filters/rbac_filter) that appears to be able to do this.

Looks like more of the API is described here config.rbac.v2alpha.Principal field source_ip.

It seems that this is more of a global-level RBAC control, not really per-route. I'm hoping that Ambassador's implementation in the future will allow me to authorize IPs per route, so that I could have the rules in the Service annotations. (Having to duplicate the URIs for the matches in RBAC rules separately as Envoy implements it would seem very tedious to me.)

@caiohasouza

This comment has been minimized.

Copy link

commented Apr 5, 2019

+1

1 similar comment
@vaibhavrtk

This comment has been minimized.

Copy link

commented May 9, 2019

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.