Is to: route setting needed if using forwardauth?

mnaletov · April 21, 2022, 12:33pm

What happened?

I’m setting up nginx-ingress with pomerium. I’d like to use forwardauth, set nginx annotations:

    nginx.ingress.kubernetes.io/auth-url: https://forwardauth.dev.example.com/verify?uri=$scheme://$host$request_uri
    nginx.ingress.kubernetes.io/auth-signin: "https://forwardauth.dev.example.com/?uri=$scheme://$host$request_uri"

What did you expect to happen?

I expect that to: key in route settings is not needed cause pomerium knows nothing about upstream

How’d it happen?

Currently I can set any value in to: key, it seems it affects nothing.

What’s your environment like?

Pomerium version (retrieve with pomerium --version): v0.17.1
Server Operating System/Architecture/Cloud: GKE v1.21.9-gke.1002

What’s your config.yaml?

autocert: false
dns_lookup_family: V4_ONLY
address: :443
grpc_address: :443
certificate_authority_file: "/pomerium/ca/ca.crt"
certificates:
authenticate_service_url: https://authenticate.dev.example.com
authorize_service_url: https://pomerium-authorize.pomerium.svc.cluster.local
databroker_service_url: https://pomerium-databroker.pomerium.svc.cluster.local
idp_provider: okta
idp_scopes:
idp_provider_url: https://example.okta.com
forward_auth_url: https://forwardauth.dev.example.com
idp_client_id: redacted
idp_client_secret: redacted
idp_service_account: redacted
databroker_storage_tls_skip_verify: false
routes:
  - from: https://test.dev.example.com
    path: /test-pomerium-deny-group
    policy:
    - allow:
        and:
        - domain:
            is: example.com
    - deny:
        and:
        - groups:
            has: Deny all
    to: http://stub
  - from: https://test.dev.example.com
    policy:
    - allow:
        and:
        - domain:
            is: example.com
    - deny:
        and:
        - email:
            is: deny@example.com
    to: http://stub
  - from: https://authenticate.dev.example.com
    to: https://pomerium-authenticate.pomerium.svc.cluster.local
    allow_public_unauthenticated_access: true

What did you see in the logs?

# Paste your logs here.
# Be sure to scrub any sensitive values

Additional context

Add any other context about the problem here.

bobby · April 22, 2022, 12:49am

Hey @mnaletov ,

Thanks for your post. In your configuration (forward-auth) you are correct that the to affects nothing.

We’ve had this issue come up in the past (authorize does not check 'to' field in policy configuration · Issue #291 · pomerium/pomerium · GitHub) but haven’t done anything about it for two reasons:

The most common & preferred way to deploy Pomerium is to directly proxy requests. In those configurations, a to address is a requirement.
The additional logic to maintain config checking logic for all the different forward-auth configurations seemed not worth it unless there was a security concern.

For what it’s worth, Pomerium can be used to proxy that traffic directly and we have an ingress controller too which might be a good fit depending on your use-case. There are some shortcomings to not using Pomerium as the proxy (e.g. we cannot strip the user’s session token before it hits the upstream, which is generally considered a best security practice) in forward-auth modes.

If you don’t mind sharing, any particular reason you are using nginx?

mnaletov · April 22, 2022, 7:25am

Thank you for you answer! Shouldn’t this info about to: key in forward-auth mode added to the docs? I’m quite sure that would be helpful.