Pomerium: Proxy: Support for unauthenticated routes

[nareddyt]

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

Routes from pomerium to different backend services can be configured with the pomerium policy file. These routes can be configured with whitelisted users, groups, and domains.

However, the documentation describes no way to configure a public route. I understand that the point of Pomerium is to serve as a IAP, but some services behind the IAP may not require authentication.

Describe the solution you'd like

I'd like a way to create unauthenticated routes in the policy file. Something like:

- from: hello.corp.beyondperimeter.com
  to: http://hello:8080
  allowed_public: true

Then any requests to https://hello.corp.beyondpermimeter.com would be proxied directly to http://hello:8080 without needing to authenticate with an identity provider.

Describe alternatives you've considered

A work-around would be configure a reverse proxy (like nginx) in front of pomerium. This reverse proxy would proxy all public traffic and only send authenticated routes to pomerium.

This workaround increases the complexity of the architecture because 2 reverse proxies must be managed. Additionally, it's not clear how I would setup SSL termination on the initial reverse proxy and disable it on pomerium.

Additional context

I am configuring pomerium with docker-compose.

Please let me know if I misunderstood the architecture of pomerium or if there is an easier workaround. If this is a planned feature, I'd love help and contribute to pomerium!

[desimone]

Hi @nareddyt thanks for checking out pomerium creating this issue.

I think you've pretty much nailed the alternatives; I would say that my only concern (and is not what you are suggesting) is that pomerium's scope doesn't start creep too much into a full feature load balancer.

Supporting non-authenticated routes is definitely a planned feature and I would very much welcome your contribution. 👍

[nareddyt]

Sounds good! I can start looking into the codebase.

Do you have any recommendations on where to start? Are there any specific packages where the code flow would be changed completely?

I'm assuming that authentication occurs before authorization currently (I haven't looked into this yet). If this is the case, would we need to flip the order to prevent authentication on public resources?

[nareddyt]

Took a look at the codebase. It looks like the proxy is already structured to support this feature!

I imagine the main change would be another condition in this function.

Other than that, I would need to:

• Define the new option in the policy schema
• Add code to handle the new option in the policy
• Add unit tests
• Update the documentation

It might take me a few days to do all of this. Let me know if there is an alternative way of implementing this feature!

[desimone]

@nareddyt

Sorry I haven't had a chance to answer your questions yet but you are definitely on the right track.

Just a heads up, I'm refactoring a bit of this code right now which I should be able to make a PR later tonight. It shouldn't change much of your plan but since I'm shifting the code around a bit I wanted to make you aware just to avoid any merge conflicts.

[desimone]

@nareddyt thanks for your patience.

>

- from: hello.corp.beyondperimeter.com
  to: http://hello:8080
  allowed_public: true

The format looks good to me but maybe instead of allowed_public, we should go with something more explicitly dangerous sounding? disable_all_access_control? I'm sure you can do better as I'm terrible with names 😄 .

I imagine the main change would be another condition in this function.

Sounds reasonable to me. The function shouldSkipAuthentication is a bit of a misnomer because (as you've pointed out) it skips all access control including both authentication and authorization.

Other than that, I would need to:

• Define the new option in the policy schema
• Add code to handle the new option in the policy
• Add unit tests
• Update the documentation

💯

It might take me a few days to do all of this. Let me know if there is an alternative way of implementing this feature!

No worries & I think you are on the right track. If you hit any issues feel free to ping me here or [email protected] and we can find a more synchronous method to chat.

[yegle]

Just to add another usecase that I intend to use Pomerium as front-end to setup DNS-over-HTTPS server (with maybe dnscrypt-proxy as back end). Since Pomerium already occupied port 443, allowing unauthenticated access on Pomerium would greatly simplify my setup.

Any alternative would require me to maintain two layers of reverse proxies, or use a different public IP.

[nareddyt]

@desimone Thanks for the feedback and looking over the implementation plan! For now, I have named it allow_public_unauthenticated_access. It's a little long but I think it describes the consequences better. If we come up with a different name, I can change it during the PR process 👍 I haven't had too many issues so far and I'm working on the unit tests today, but I'll let you know if I run into any blockers.

@yegle Glad to see interest, that's another valid use case for this feature!