Research task: OAuth2 with OpenFaaS Gateway

[alexellis]

Research task: OAuth2 with OpenFaaS Gateway

Task

OAuth2 is widely used for authz for microservices, and there have been several requests (although now huge demand) for this in OpenFaaS.

This task would explore what it looks like to configure OAuth2 for an OpenFaaS Gateway deployment.

We can cover authentication with something like OAuth2Proxy for on-premises or for hybrid/public cloud perhaps Auth0 or similar. Ideally any OpenID Connect back-end would be possible to use.

To cover authorization we would need to read claims and use them to decide if a "user" can do a certain operation. An initial break-down of "admin" into claims may be: read/write or read/write/list/execute. A plus-point of using "list" as a claim is that a service which only needs access to list functions doesn't automatically gain full write access.

Potential workflow

1. faas-cli login redirects to social login or corporate SSO depending on configuration in back-end
2. User authenticates to external authz server
3. Authz server issues token
4. faas-cli saves token and presents token to API Gateway upon each route which manages functions i.e. /system/
5. Token is evaluated by an in-process function or a separate HTTP address - given a token and a set of claims, can user X do operation Y?
6. If 200 is replied, then allow it, if it's 401 then deny it

Impact

faas - feature flag for those who don't want OAuth2, scopes need to be implemented for each handler
faas-cli - initiate an OAuth2 flow, save token and pass along on to calls

packaging - this would need to be an opt-in part of packaging and suitable for use with other back-ends.

ui - if enabled for the UI, we may need to build a login workflow which uses a cookie to present the token received by the user.

Non-goals

Service to service communication - this would still use a service account i.e. "admin" and basic-auth.

Related

openfaas/faas-cli#629
#793
#74
#1058

[matipan]

This would be really useful. Another feature that might go well with this is enabling/disabling the authentication for each function individually. Through some form of label maybe.
I recently had a conversation with a co-worker. They were looking into serverless frameworks and deciding where to go. One thing they remarked was necessary for them was this type of plugable authentication and the possibility of making some functions accessible by anybody and others for authenticated users only.

[tmiklas]

I think it's very valuable feature, especially if we are talking about OpenFaaS in corporate environments. Where I work, any new apps deployed have to support SSO to limit and enforce who can do what... or they are out of compliance and can't move to prod, so as future- and feature-proofing this is IMvHO an excellent idea.

[alexellis]

Much of this functionality can be added for free by using an additional Authenticating API Gateway such as Kong, a plugin could be built for Kong in Lua to scan for those labels and apply authentication on each function for instance.

In my example diagram invoke is not part of the workflow, but it could be (as a separate discussion)

[alexellis]

@tmiklas I would not like to see developers deploying directly to production via their login accounts. This should be restricted to a CI/CD system. Does that change the "SSO is mandatory" requirement at all?

[LucasRoesler]

The claims part is going to be interesting, openid connect doesn't actually specify a default claim for those kind of actions https://openid.net/specs/openid-connect-core-1_0.html#Claims

Also, those types of allowed action claims are very specific to OF, so it isn't clear to me why a third party auth service would contain the information we want. We would need to add that as a stateful component to OF.

A third party OIDC would be able to authenticate the user, so we would then be able to determine who the user is, but it would not determine they are allowed to do in our system.

OIDC also does not provide any kind of group/role claim that we could attempt to piggyback on.

The basic flow of making a side-request to an authn/authz method makes a lot of sense. This is, for example, one of the ways to enable authentication in the nginx-ingress. I have also seen it used (or ate least described in blog posts) in number of other systems.

[tmiklas]

@tmiklas I would not like to see developers deploying directly to production via their login accounts. This should be restricted to a CI/CD system. Does that change the "SSO is mandatory" requirement at all?

Yes, agreed, code should be deployed ONLY through CI/CD system. Access to any console in my environment or functionality (if it can be called from the outside) still requires SSO and access rights, but that would be more of an equivalent of calling a function, rather than deploying it. Hope I explain myself better now.

[alexellis]

@LucasRoesler I had an in-person discussion with Ed and a few people in the community how their authz servers build in a custom mapping of claims to users.

@ewilde can you elaborate a bit on this when you have time?

[ewilde]

@alexellis @LucasRoesler

I had imagined an identity server or SaaS provider like auth0 managing authentication and issuing a JWT token with a standard set of pre-defined scopes:

of:read
of:write

Potentially we could explore limiting access to functions ?
of-fn-foo:read

Then OpenFaaS gateway would verify the scopes using identity server public key that signed the JWT and determine what access the user has.

Does that sound reasonable?

[LucasRoesler]

@ewilde this would make the feature highly dependent on the identity service allowing the admin to store custom scopes for us, right? We couldn't use google or github as an identity service

[ewilde]

@LucasRoesler correct, you would need an identity service that allows custom scopes, it could also support social login as well (google, github). Auth0 and a number of others provide this. The advantage is that OpenFaaS doesn't need to manage users and permissions. The disadvantage might be limiting which identity services you can use

[alexellis]

I think Ed may be talking about something like this:

• https://auth0.com/docs/tokens/add-custom-claims
• https://auth0.com/docs/api-auth/tutorials/adoption/scope-custom-claims

[alexellis]

I have an e2e workflow for the OpenFaaS UI / gateway using a Cookie and code grant

https://gist.github.com/alexellis/117301462366cc7cdb6aa7a9237d371d

And work underway for the CLI using a Bearer token and implicit flow. PKCE can be added after this for those auth providers that support it.

openfaas/faas-cli#648

We need to figure out our approach for CI / machine-tokens where a non-interactive login has to be used.

This could be a cookie / token captured by the CLI and re-used, but these tend to be short-lived and have to be refreshed. Some auth providers (but not all) support client credentials flow.

[alexellis]

In terms of authz, @LucasRoesler and I think the lowest common denominator may be a subject whitelisting approach.

The subject is generally unique and corresponds to an identifier for the user in the IDP. So in GitLab, my sub may be 2 and Lucas may be 3 with Darren being 4.

subs:
 - 2
 - 3

The above would allow myself and Lucas access and deny Darren.

[alexellis]

/lock: inactivity