Pomerium: authorize: Allow path-based authentication

[cjwalton]

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

I would like to be able to whitelist certain paths for a resource, or in the reverse, only protect other paths.

Examples might be:

- from: https://www.myblog.example 
   to: https://www.myblog.example
   allow_public_unauthenticated_access: true
- from: https://www.myblog.example/admin
   to: https://www.myblog.example/admin
   allowed_domains: example.com

Describe the solution you'd like

See above. There may be a better way of expressing this, but that's off the top of my head.

Describe alternatives you've considered
Using pomerium in forward-auth mode, as documented here: https://www.pomerium.io/docs/reference/reference.html#forward-auth

Explain any additional use-cases

I simply have several applications that in general need to be protected by an authenticating proxy, but also require certain URLs to be whitelisted for public access. Examples include Jira and Confluence, Kolide Fleet

[victornoel]

In the context of kubernetes and an ingress controller that is in front of pomerium, I have some idea to support this use case without touching pomerium.

I haven't yet tried it, but what I am planning to do is to have ingresses resources responsible of proxying directly to the app for the desired subpath, and to pomerium for the rest of them.

It will depend on the ingress implementation though, for example nginx can match regex so it would work: https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/

I think contour also supports them for the Ingress object only.

[xeor]

Did it work as expected @victornoel ?

[victornoel]

Did it work as expected @victornoel ?

@xeor yes! I matched the / path to the pomerium proxy service and the un-protected paths (/live in my case, for health probes) directly to the real service.

The only gotcha is that ingresses can only refer to services of the same namespace, so in my case I had to introduce an extra service in the same namespace as the ingress with an external name (https://kubernetes.io/docs/concepts/services-networking/service/#externalname) pointing to my real service in a secondary namespace:

pomerium-ns/ingress -> /      -> pomerium-ns/pomerium-proxy     -> app-ns/app-service
                    -> /live  -> pomerium-ns/fake-service       -> app-ns/app-service

Maybe there are other ways to handle that last point though...

[desimone]

Looking at adding this to next release.

[abuzhynsky]

@desimone
Thanks for the awesome project.
We're currently trying to adopt Pomerium in our company and we have a lot of applications that are exposed using the one hostname and different path prefixes (i.e. https://myhost.example/secured/app1).
Are you planning to release this feature soon (i.e. in a month)?
And could you please share the planned scope of this feature?
Some of our applications support the base path prefix and need to know about it because they generate URLs on the backend so the policy for them would look like this:

- from: https://myhost.example/secured/app1
  to: http://app1.default.svc.cluster.local/secured/app1

Other ones don't support the path prefix so we need URL rewriting:

- from: https://myhost.example/secured/app2
  to: http://app2.default.svc.cluster.local

Do you plan to support both cases? And do you plan to add support to the operator for the first case?
It would be great to know to make the right decision - if we should wait for this feature or make changes on our side using the subdomain approach.
Thanks in advance.

[desimone]

fyi @abuzhynsky see #615 this should be merged very soon.

[desimone]

Implemented in #615