Comments (9)
@tdorsey @victornoel sorry, I missed both of your excellent follow up posts. I agree that this should be re-opened and reconsidered. Some of the recent changes in Pomerium's core should make this much more doable as well.
Please see the following proof of concept PR using Traefik : #324
Please let me know what you think, as it should be very similar to what @tdorsey described in his post. Those with experience using other proxies, does this more or less function the same way? It looks like envoy also supports full on gRPC which would be much preferable from a performance point of view; though all the old guard products seem to still use HTTP.
In addition to those listed above, I'm looking the following proxies:
See also:
\cc @fiahil @pecigonzalo
from pomerium.
Sorry #324
from pomerium.
I'd like for this issue to be reconsidered. Turning pomerium into a full fledged ingress controller seems like a crowded field -- nginx, traefik, ambassador, and contour all already exist.
desimone: As you've noted, many load balancers have some form of authentication front-end. But typically, these authentication frontends don't make any authorization decisions, instead they simply pass on the authentication details to backend services leaving the onus on the backend applications to make authorization decisions.
This exactly describes what I want pomerium to do: integrate with the forward-auth capabilities of a pre-existing ingress controller. To use pomerium today, it means dropping traefik (and their nifty ingress dashboard).
Traefik has:
- conditional load balancing
- the aforementioned stats dashboard
- automatic certificate generation
- excellent request tracing capabilities
- no authorization system worth the name
Pomerium as this hypothetical authorization provider let's me keep my authorization system separated from my routing, and this is exactly what forward-auth is intended for.
These are the only ingress annotations needed to enable forward-auth (speaking for traefik and nginx, anyway)
ingress.kubernetes.io/auth-type: forward
ingress.kubernetes.io/auth-url: "https://<pomerium-oauth-start>
ingress.kubernetes.io/auth-response-headers: "X-Forwarded-User"
ingress.kubernetes.io/auth-trust-headers: "true"
The IC forwards the request to the auth-url, pomerium does whatever it likes, and sends back a 200. If the IC receives anything other than 2xx, they're denied.
from pomerium.
I see where you are coming from. Since we are already reverse-proxying requests with some production load balancer like nginx, can we just do the authorization and authentication bits in pomerium?
Though I like the idea of separation of concerns and eliminating a hop, I don't think this would be possible given the types of access control decisions pomerium needs to make. As you've noted, many load balancers have some form of authentication front-end. But typically, these authentication frontends don't make any authorization decisions, instead they simply pass on the authentication details to backend services leaving the onus on the backend applications to make authorization decisions. This will get even trickier when support for device state and context come into the picture.
Since pomerium aims to allow for (increasingly sophisticated) access control decisions to be made universally in front of the application logic, I think that for the foreseeable future, the best way forward will be gate authorization with our own reverse proxy.
from pomerium.
@desimone indeed, I see what you mean, thanks for the explanation :)
I will close this and if someone has something to add to the discussion, it can still happen.
from pomerium.
@desimone great news!
My secret dream is to be able to use contour as a proxy and pomerium for authn/authz :)
But well, contour isn't there yet (see projectcontour/contour#432) but it's based on envoy, so I'm rooting for envoy support.
from pomerium.
Just for the record as I have been reading a bit about that, it seems that most proxy have in place mechanisms for external authentication. On top of the others cited above, we have:
- envoy with https://www.envoyproxy.io/docs/envoy/v1.10.0/configuration/http_filters/ext_authz_filter
- traefik with https://docs.traefik.io/configuration/entrypoints/#forward-authentication
Basically, the way it usually works is that the request is passed (usually only some headers) to the auth service, which decide if the access is 1) accepted 2) refused or 3) need auth. Usually it will use the return code (if using http) to specify one of the 3, for example a 301 means the auth service will take care of the rest of the workflow until it redirects to the original url.
I think this should be kept in mind for the future of pomerium, because more and more people will be expecting to use modern proxy such as envoy (which are able to handle correctly websockets, grpc and other non-L7 stuffs if I understand correctly).
I'm currently experimenting with contour (an envoy-based ingress for kubernetes) as a replacement of nginx, hence my current interest with the question :) There are some interesting discussions happening on the matter in projectcontour/contour#432, projectcontour/contour#986 and projectcontour/contour#1014.
from pomerium.
Closed by #323 . Looking forward to everyone's feedback. Cheers.
from pomerium.
@desimone #323 is currently closed in favor of this issue...
from pomerium.
Related Issues (20)
- core/session: flaky test
- core/databroker: synchronization error "proto: syntax error" HOT 1
- core/integration: tests failing due to expired certificate
- Flaky test in internal/autocert package
- Session refresh issue with Jumpcloud IdP HOT 8
- Add custom error page for unavailable upstream HOT 1
- docker: pomerium/pomerium:main does not work on apple silicon HOT 2
- Restore stateful authenticate flow when not using hosted authenticate service HOT 2
- Access tracker repeatedly tries to update deleted session HOT 1
- add `X-Real-Ip` request header HOT 1
- Identity manager expects to be able to read user ID from deleted session records HOT 2
- Redirect response_code setting does not behave as documented
- Redirect with `path` variable not working HOT 5
- Pomerium occasionally happens 500 internal error while accessing application HOT 4
- robots.txt Disallow / for public routes HOT 6
- Remove deprecated client_ca setting
- core/authorize: denied response is not an error page anymore HOT 1
- core/config: support direct response HOT 2
- cli reuse port HOT 2
- Path rewriting not working as expected HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pomerium.