proxy: Wildcard Virtual Hosts

[v4dkou]

Is your feature request related to a problem? Please describe.

I would love to be able to use wildcards in from argument to have one policy cover a bunch of internal services at once.
Going in working with Pomerium, I intuitively assumed that there should be wildcards, as wildcard certificates are mentioned, but it turned out there aren't any.

Describe the solution you'd like
Envoy's wildcard syntax looks exactly like what I was looking for. It's also pretty close to what we have in nginx/HAProxy/Caddy, so that makes it familiar.

Domain search order:

• Exact domain names: www.foo.com.
• Suffix domain wildcards: *.foo.com or *-bar.foo.com.
• Prefix domain wildcards: foo.* or foo-*.
• Special wildcard * matching any domain.

https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/route/route_components.proto#route-virtualhost

Describe alternatives you've considered, Explain any additional use-cases

My use case involves spinning up a lot of subdomains for development API and web page testing.
A similar issue is described in #659 and there was proposed a solution to use config templates.
I've tested a hacky solution based on restarting Pomerium on config changes with some success, but there are a few problems with it:

• Reliance on Docker host configuration, rather than keeping everything isolated
• Having to support a service registration flow
• Tricky security considerations

Fair warning! If you use the snippet below, make sure to sanitize your config data or better yet DON'T accept user data here.
Pomerium allows routing to external URLs, and bad things could happen here through crafty string manipulation.

#!/bin/bash

while true; do
inotifywait -e close_write -qq ./config.yaml
docker-compose restart pomerium
done

Additional context

For some reason right now policies with subdomains containing asterisks return 403 for me (not 404).
That might give an indication of what's happening inside.

[sherifkayad]

@travisgroth Wildcards in the from aren't interpreted by Pomerium as of today, is that correct? .. If so, will there be any plans to work on that as a future enhancement?

[spenceradolph]

I currently have a use-case for this. Want to experiment with using pomerium as an identity aware network access tool. User would hit pomerium at the front, authenticate / authorize, and then be allowed to multiple (changing) subdomains. Without wildcards I may have to find another solution that fits well but I can understand from a zero-trust perspective how wildcards aren't exactly the best approach.

I was previously using NginxProxyManager to control those changing subdomains / services and was hoping to continue using it, except with the added security provided by pomerium (in the cases that services don't provide their own auth).

[calebdoxsey]

We could support wildcards but not like some of the examples given above. We are limited to what Envoy supports:

The server name will be matched against all wildcard domains, i.e. www.example.com will be first matched against www.example.com, then *.example.com, then *.com.
Note that partial wildcards are not supported, and values like *w.example.com are invalid.

[v4dkou]

@calebdoxsey The quoted part with partial wildcards is not something I made up, but rather a part of the Envoy v2 documentation.

The link to the relevant Envoy doc from the original post is dead, here's the new link for Envoy v3
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto

(see description of the domains key)

Judging by this doc, Envoy does support partial wildcards.
Could you point out the source for the part you have quoted?

[xlejo]

Any update?

[yardenshoham]

I ended up using https://oauth2-proxy.github.io/oauth2-proxy/ instead. It supports wildcards.

[mnestor]

I could see this more as a regex type thing

from: tcp=https://sub([0-9]{3}).testsystems.internal:22
to: tcp://10.0.0.$1:22

from: https://([^\.]*).testsystems.internal
to: http://$1.testsystems.internal

Then you could manage 2 routes with restrictions without having to add/remove as dev systems came up/down.

I'm actually looking at doing something like this for a limited access network that currently access is dynamically managed for ssh/rdp/https via custom code rewriting firewall rules. So something like this would be pretty big.

[desimone]

@mnestor / @xlejo / @v4dkou -- It's been a while but we now have support for wildcarding on v0.22 implemented by #4131

[leonardotbo]

@desimone I see that the wildcards works as expected, but does it also do regex substitution as @mnestor suggested?

I.e. can I do something like:

from: https://*.localhost
to: https://test.localhost/?q=//1

If so, what is the correct syntax?