Make the IP "whitelisting" more flexible

[iamslite]

Feature: Increase the flexibility of the whitelisting

The current whitelisting acts as a strict gate to incoming traffic. The authentication is also used as a strict gate. To gain access you have to meet both criteria and there is no mechanism to support meeting either.

Whilst it may be too late to change this naming now it would appear to the current functionality is more of a greylist than a whitelist since the requests get challenged again.

The feature behaviour would be have two groups of access lists, one that does indeed whitelist the traffic and hence allow it straight through, and a second which allows the traffic through to the next level of checking.

For the simple case of no auth the two lists would be essentially the same. And if no lists are set the auth would continue to be the decider.

There is no obvious need for the blacklist variant since this can be better achieved using a normal firewall.

What did you do?

Using the docker image traefik:1.4 enable both authentication and whitelisting for entrypoints:

[entryPoints]
    [entryPoints.http]
    address = ":80"
    whiteListSourceRange = [ "x.x.x.x" ]

    [entryPoints.http.auth.basic]
    usersFile = "/etc/htpasswd"

What did you expect to see?

Requests that failed the IP address check would trigger the basic authentication instead.

What did you see instead?

• Requests that failed the IP address check where blocked immediately.
• Requests that met the IP address check had to meet the basic authentication criteria

Output of traefik version: (What version of Traefik are you using?)

Version:      v1.4.0-rc5
Codename:     roquefort
Go version:   go1.9.1
Built:        2017-10-10_02:04:46PM
OS/Arch:      linux/amd64

Additional notes

There is a secondary part to this which is that when you are using the docker container the incoming IP address may be that of the docker host, not the original requesting host. This is certainly the case if you are working with a swarm because then the traefik container must be on an internal network. Ideally the checks would be against the originating IP address.

[RiwanBodereau]

Hello,

Any update on this ? it would be extremely useful 😄

I think that we need something similar to Apache Satisfy Any directive.

For example, if you wanted to let people on your network have unrestricted access to a portion of your website, but require that people outside of your network provide a password.

Thanks in advance

[Ppito]

Hello,

I'm also really interested by this feature.
In my case, I want to have an authentication everywhere except in my company.

Thanks,

[nemosupremo]

I'm thinking about writing a solution that adds another whitelist parameter under entryPoints.http.auth. This won't be quite as powerful as Satisfy Any, but would support this use case. Would that be acceptable?

[emilevauge]

Hi @iamslite , thanks a lot for you suggestion. We want to keep the whitelisting section as simple as possible and we think that your use case could be addressed differently. We advise you to either use a vpn, either use the authentication forward mechanism we introduced recently.
Thanks @iamslite

[iamslite]

@emilevauge, the authentication forward mechanism is an inappropriate tool for this task. I agree it is a very flexible tool, but I reviewed it before raising the issue. To use it you have to write a server process that will then look at the forwarded IPs, make a decision and then return a response, which will then be interpreted by traefik. Not only is this a waste of resources, the server process is non-trivial for general users. The solutions that grew out of this feature request are similar in nature to what is already in the traefik and I am puzzled why adding a couple of entries to the whitelisting section suddenly complicates things when it solves what appears to be a fairly common and important use case, based on the community response.

[martinhoefling]

Another use-case that requires a more flexible whitelisting is combination with client certificates. From external ips, it's required that clients authenticate via valid client certs while internal ips do not require this step. This is e.g. required to allow enrolment of client certs from within the corporate network.