Multiple named AuthServices

[alexgervais]

Support multiple named AuthServices and enable them on a per route mapping configuration.
Would also unlock related issue: #174

For example, configuring multiple AuthServices:

apiVersion: ambassador/v0
kind: AuthService
name: simple-auth
auth_service: "example-auth:3000"
---
apiVersion: ambassador/v0
kind: AuthService
name: other-auth-strategy
auth_service: "external-auth:8080"

And configuring routes:

apiVersion: ambassador/v0
kind:  Mapping
name:  qotm_cloud_mapping
prefix: /qotm/
rewrite: /qotm/
service: demo.getambassador.io
authentication: simple-auth
headers:
  x-demo-mode: cloud
---
apiVersion: ambassador/v0
kind:  Mapping
name:  qotm_local_mapping
prefix: /qotm/
rewrite: /
service: qotm
authentication: other-auth-strategy
headers:
  x-demo-mode: local
---
apiVersion: ambassador/v0
kind:  Mapping
name:  qotm_host_mapping
prefix: /qotm/
rewrite: /
service: httpbin.org:80
headers:
  x-demo-mode: host
host: httpbin.org
host_rewrite: httpbin.org
# No authentication strategy

Therefore, not all request methods will be proxied to an auth service, and we can select which auth service to use for dynamic routes.

[gillesdemey]

This would be a great addition, that way we won't have to add the path configuration for authentication to the auth service.

[owais]

This is what I was expecting Ambassador to have after experiencing the "self service" style configuration for routing. How auth currently works goes totally against the self service ideology IMO. Right now, all teams/individuals hav to ship changes to two independent services (their service + auth service) whenever they need to change how their service is protected. Also, multiple teams will end up contributing to the same auth service and the auth service might end up being much more complex than it would make sense as business logic might creep in to the auth service handlers.

[victortv7]

For people who have clusters whose services have different authentication requirements and prefer a self-service approach: What alternatives did you find? Is using authentication in Istio a valid alternative? Or maybe not using Ambassador at all? In this case. when we talk about authentication what tool do you think is a good reference for future versions of Ambassador to look upon?
Thank you.

[draeron]

any update on this issue? this is a roadblock to our integration of ambassador

[hrobertson]

I completely agree that this sort of thing would be a good addition and agree with @owais that it's much more kube-native than having one monolithic auth service that has to handle all requests.

An alternative example:

apiVersion: ambassador/v0
kind:  Mapping
name:  basic_mapping
prefix: /
service: example
authentication: basic-auth
regex_headers:
  Authorization: "^Basic"
---
apiVersion: ambassador/v0
kind:  Mapping
name:  bearer_mapping
prefix: /
service: example
authentication: token-auth
regex_headers:
  Authorization: "^Bearer"
---
apiVersion: ambassador/v0
kind:  Mapping
name:  unauthed_mapping
prefix: /
service: example
headers:
  Authorization: false

[kflynn]

#174 is related.

[travisghansen]

Not sure it helps but I've been working on a highly dynamic external auth service. It supports several authentication plugins including ldap, jwt, htpasswd, oauth/openid, etc and allows you to put them in a 'pipeline' so you could string several plugins together and if 1 of them passes then the request is allowed (toying with the idea of forcing all of them to pass as well). I for example secure the same service with openid (for sso type stuff) and basic auth backed by ldap to support machine-to-machine style communication.

A single deployment of the service can house n configurations so you don't need to keep re-deploying over and over. Looking for some additional eyes/feedback at this point if anyone is interested, particularly ambassador users as in my setup I've been testing with traefik and nginx.

https://github.com/travisghansen/external-auth-server

[richarddli]

We support this in Ambassador Pro now, via the Filter and FilterPolicy mechanism.

[coopbri]

Awesome service, @travisghansen. Thanks for your contribution!

We support this in Ambassador Pro now, via the Filter and FilterPolicy mechanism.

Is something like this officially supported with the OSS offering (Emissary), or are we restricted to one AuthService resource? I read through https://www.getambassador.io/docs/edge-stack/latest/topics/running/services/auth-service/ and understand the round-robin & canary caveats, but am curious if there are workarounds native to Emissary itself, or if a proxying approach such as @travisghansen's or an alternative API gateway solution is necessary.

[travisghansen]

I’m putting the final touches on envoy grpc support within the project as well if that’s helpful to anyone :)