Open itsmurugappan opened 5 years ago
Hi, thanks for your interest in the project.
Here are some thoughts/questions:
Adding OAuth2 is not a trivial feature and will be expensive for the community to develop and maintain.
What OAuth flows are you hoping to support and implement?
Once you have authentication, how are you going to implement authorization re: claims and permissions?
To get started we can just have proxy like keycloak gatekeeper in front of openfaas gateway and proxy all requests through it. (No change needed on the gateway)
You mentioned gatekeeper. Have you taken a look at OAuth2Proxy? Does it do what you need?
You may also want to look at OpenFaaS Cloud which includes OAuth2 and integration with GitLab self-hosted and GitHub.com.
Hi Alex,
Thanks for the reply. OAuth2Proxy does what I need. If the OAuth2Proxy protects the openfaas create, delete, list api's, I will need a way to pass the access token in the header to get authorized. That's the reason I am proposing a change in CLI, which I can contribute to.
When you have time please can you answer my other questions?
What OAuth flows are you hoping to support and implement?
I had Password grant in mind.
Once you have authentication, how are you going to implement authorization re: claims and permissions?
This can be handled in the gatekeeper or oauth2_proxy. I was planning to authorize based on issuer, audience and role claims (member of an email group)
How are you planning to relate those roles/claims to the various parts of the OpenFaaS API?
For me to entertain this suggestion further, I'd like to see a lot more from your side about how you expect it to work for both authentication and more importantly authorisation. The current API model does not map to claims or roles other than one user being the a service-account with full permissions to all APIs.
Here are some more details on what is expected from a proposal: https://github.com/openfaas/faas/blob/master/CONTRIBUTING.md#i-have-a-great-idea
I'm looking forward to hearing more.
Sure. I will give details of the proposal soon.
About the Solution
Proxy requests to Openfaas gateway through a reverse proxy (key cloak gatekeeper or oauth proxy) which integrates with an open id provider
Authentication: The user will authenticate with open id provider to get the access token. Below I have described how each flow will work.
UI: Redirect flow of the reverse proxy
API: Request the access token through api call to open id provider
Example:
curl -X POST https://keycloak/auth/realms/realmname/protocol/openid-connect/token -H "Content-Type: application/x-www-form-urlencoded" -d 'username=uname&password=pass&grant_type=password&client_id=openfaas'
There are also packages available in each programming language to achieve the same
CLI: Similar to API flow, login functionality has to be added to cli to accept user credentials, hit the open id provider and store the access token in the config file.
Authorization:
Changes required in the Openfaas-cli
Login Command:
Mock cli change:
faas-cli login -u user -p password --gateway http://127.0.0.1:8080 --auth-url=https://oidcprovider/auth/realms/realmname/protocol/openid-connect/token --client=oidcclientname
Deploy/Delete/Describe/List/Invoke Command:
Pros:
Effort Required:
Changed are required only in Faas-CLI. In FaaS-CLI following changes are needed
Migration Strategy/Backwards Compatibility:
The reverse proxy is optional component. If the user opts to use basic auth this component is not needed. From the cli perspective, additional parameters will be added to the login flow only. Since these parameters are optional it will not affect the compatibility with Open FaaS gateway without a proxy in front.
Once the user is authorized the user will have access to all openfaas gateway api’s.
I'm not sure what the benefits are of using a password-grant which means any user with a single role is a complete admin? How is that enterprise-grade security? It seems pretty much the same as basic-auth.
What I would envision for enterprise-grade OAuth2 is more like:
Thanks for the comments. I made the following changes.
The proxy with open id integration like gatekeeper gives the flexibility of authorizing at api level. For example, if we want to restrict the function deployment to developers_write role. Following would be configuration for the gatekeeper.
resources:
- uri: /system/function
methods:
- GET
roles:
- developers_read
- uri: /system/function
methods:
- POST
roles:
- developers_write
Can enforce authorization for all api's listed here .
I would be more than happy to test such feature.
Hi @CrystalMethod @itsmurugappan I would like your input on the new OIDC flow implemented for OpenFaaS.
It's being tracked by the openfaas/faas issue and the CLI issue I raised.
https://github.com/openfaas/faas-cli/issues/647 https://github.com/openfaas/faas/issues/1175
cc @prahaladdarkin
Alex
sure @alexellis . Will check out this weekend. Got some great updates from you regarding tls and oidc.
Support for OpenID based authentication
why open id ?
Openfaas currently supports basic authentication. If it has to support openid based auth either
To get started we can just have proxy like keycloak gatekeeper in front of openfaas gateway and proxy all requests through it. (No change needed on the gateway)
So what are the changes needed ?
3 ways to connect to openfaas gateway
ui - we can use redirect flow, which will redirect to openid providers ui and can login from there api - bearer token in header cli - cli is the one which needs change. Need a way to pass bearer token
my proposal
add functionality to the login, similar to openshift login (oc login)
For example
faas login -u -p --gateway=https://openfaasgateway --well-know-url=openidurl client=openidclient