Role-based Access Controls for SSO

[alexec]

Summary

Currently any user that logs in using SSO escalates to the argo-server service account. We would like other options.

Motivation

TBD

Proposal

Either:

• Casbin style similar to Argo CD.
• Client mode style i.e. map groups to a service account.

See:

• Argo Workflow UI - Authentication and Authorization Feature #1813

---

Message from the maintainers:

If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

[alexec]

We need some requirements for this issue. How do you want RBAC to work and be configured? Please be specific!

[alexec]

We need something beyond 👍 for this issue to be worked on. Please can you add some information about how you expect RBAC to work?

[kabilan6]

Just a thought to start with - Read only user ( can only view workflow, all submit button should be disabled) and admin user with all privileges

[alexec]

One cheap solution to RBAC is to base it on the URL of each request to the server using Casbin.

Operators must configure a model.conf and policy.csv and add them as files to the argo-server container (I would use a config-map volume for this):

So...

• sub - the OAuth2 subject.
• obj - the URL
• act - the HTTP method: GET/PUT/POST/DELETE etc

Casbin model:

model.conf

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && keyMatch(r.obj, p.obj) && (r.act == p.act || p.act == "*") 

Casbin policy (you would configure this):

policy.csv

g, alexec, admin
g, kablin6, readonly
p, admin, /*, *
p, readonly, /*, GET

Some examples of the URLs:

• /api/v1/info
• /api/v1/version
• /api/v1/userinfo
• /api/v1/workflow/{namespace}
• /api/v1/workflow/{namespace}/{name}
• /api/v1/workflow/{namespace}/{name}/retry
• /api/v1/workflow-templates/{namespace}/{name}
• /api/v1/archived-workflows/{uid}
• /artifacts/{namespace}/{name}/{nodeId}{artifactName}
• /artifacts-by-uid/{uid}/{nodeId}{artifactName}
• /oauth2/redirect
• /oauth2/callback
• /index.html
• /main.js

Many users want to use namespace for data segregation, but this would not work for artifacts archived workflows (we could fix that).

[alexec]

I'd like to hear more uses cases please.

[sudarshntn]

@alexec The SSO enablement in ArgoWorkflow is not seem less like we have in ArgoCD where we allow existing OIDC provider also. We would like to have a simplified SSO functionality along with RBAC enabled.

[vladlosev]

The casbin based policy is quite a bit more complex than simply mapping a group returned by OIDC to a k8s service account. This is mostly due to the burden of having to write and maintain a policy covering constantly expanding and changing set of URLs.

[alexec]

The casbin based policy is quite a bit more complex than simply mapping a group returned by OIDC to a k8s service account. This is mostly due to the burden of having to write and maintain a policy covering constantly expanding and changing set of URLs.

I think you're probably correct about that.

[alexec]

We still don't have enough use cases to be confident we can implement the right solution for this issue.

I've added as a topic to the next community meeting:

http:https://bit.ly/argo-wf-cmty-mtng

[alexec]

I think the community meeting gave a couple of key use cases

• Anonymous read-only access.
• Authenticated read-only access.
• Authenticated access by mapping OIDC groups to service accounts.

[alexec]

RBAC configuration proposal:

kind: ConfigMap
metadata:
  name: workflow-controller-configmap
data:
  rbac: 
    # to configure the default account to use:
    defaultServiceAccount: my-sa
    # use the first matching rule
    rules:
    - groups: 
        anyOf:
        - my-oidc-group
       serviceAccount:
         name: my-sa

[alexec]

We have a number of question on this feature and have put them into a proposal:

https://docs.google.com/document/d/1OTVPpWCKM_oO4Z2_pMN1LTyTjWbPv4G9SDmTIpGnIQo/edit?usp=sharing

[alexec]

Please comment.

[alexec]

Bump! Please comment on the proposal! https://docs.google.com/document/d/1OTVPpWCKM_oO4Z2_pMN1LTyTjWbPv4G9SDmTIpGnIQo/edit?usp=sharing

[alexec]

Note to self - investigate Kubeflow multi-tentancy:

https://www.kubeflow.org/docs/components/multi-tenancy/
https://static.sched.com/hosted_files/kccnceu20/57/%5Bkubecon-amsterdam%5D%20Enabling%20Multi-user%20Machine%20Learning%20Workflows%20for%20Kubeflow%20Pipelines.pdf

[alexec]

I've created a developer build for your testing: argoproj/argocli:rbac

To test this, you need the following extra configuration:

• workflow-controller-configmap.yaml
• argo-server-sa.yaml

Please test and tell me if it meets your needs.

[alexec]

@danxmoran, @clelange, @ephemeral, @kabilan6, @vladlosev, @lukasmrtvy, @gordonbondon, @dcd000, @rgoldfinger-quizlet, @SM616, and 23 people who reacted with thumbs up emoji.

Your feedback is key to ensuring that this feature gets merged. I'd love to get it into the v2.12 release next month, but I really need more feedback from the community. Ideally I'm looking for people to take a deep dive and test it, but reviewing the YAML configuration and reasoning about it would be very valuable too.

To test this, you only need to upgrade the Argo Server.

@vladlosev thank you for your feedback!

Alex

[ephemeral]

Hey @alexec, our use case is quite simple atm. We are heavy users of ArgoCD, and we use Okta + Dex for auth. We would like to use something similar for Argo Workflows. (Casbin style)

Happy to join the next community meeting to discuss further.

Thanks,
Pierre

[alexec]

Don't forget to try out argoproj/argocli:rbac to see it works for you.

[vladlosev]

@alexec I tried installing this image in our cluster but have no success making it work. I noticed in the server's logs that it was not outputting the rbac field as coded on line 130 in server/auth/sso/sso.go in the PR. Can it be that the image has been built of some earlier code revision, not reflecting the latest changes in the PR?

[alexec]

@alexec I tried installing this image in our cluster but have no success making it work. I noticed in the server's logs that it was not outputting the rbac field as coded on line 130 in server/auth/sso/sso.go in the PR. Can it be that the image has been built of some earlier code revision, not reflecting the latest changes in the PR?

Thank you. I'll investigate.

[alexec]

Try this:

docker run argoproj/argocli:rbac version
argo: v2.3.0-rc3
  BuildDate: 2020-09-15T21:56:10Z
  GitCommit: dd5aad87e4cd64c126b3fa2209903c566bbaee86 # <-- check this is same
  GitTreeState: clean
  GitTag: v2.3.0-rc3 # <-- ignore this :)
  GoVersion: go1.13.4
  Compiler: gc
  Platform: linux/amd64

[vladlosev]

@alexec it works like a charm with the updated image! The operation is very transparent when permissions are sufficient and the error messages are quite conspicuous when the user lacks the permissions. I could go and use it right now.

Sorry you didn't get to ship it in 2.11.

[alexec]

[bnbrijesh]

Doesnt this support email scope ? Azure doesnt seem to support groups scope, I mean for RBAC mapping. in rbac-rule