EXPLORE: Argo RBAC

[gsampaio-rh]

Explore how to support OCP and / OR Kube esp for Argo RBAC

[tylerauerbeck]

How do we want to configure roles/permissions inside of Argo? How do we want to utilize Argo projects?

[springdo]

Should we be following some of @sabre1041's OpenShift Blog about integrating to the RBAC provided by OCP?

https://www.openshift.com/blog/openshift-authentication-integration-with-argocd

[springdo]

@oybed - FYI

[eformat]

FYI .. for now it is too open (intentionally ! so we can figure out the right model)

in the argo CR we set:

  rbac:
    defaultPolicy: role:admin

See: https://argoproj.github.io/argo-cd/operator-manual/rbac/

and the service account is bound to this cluster admin role argocd-application-controller

now, there are multiple problems to solve here:

• CRD's which may be needed (not only for argocd install), but user apps - requires cluster admin
• multiple namespaces managed by argocd
• RBAC, user's groups etc using argocd + openshift rbac model (should hopefully be as simple as mapping openshift groups to argocd, exposing in the bootstrap helm chart/argcd operator)

also linked to - #56

[oybed]

There's really 2 aspects of RBAC that needs to be considered:

1. RBAC to Argo itself (covered by @sabre1041 's blog and custom images)
2. RBAC for what Argo can deploy/manage based on the requester's permission levels.

I'd argue that #1 is a nice to have for dev env., but less important the closer to production you get (yes, some level of read-only access is nice to have). As an example - for OMP we have chosen to do everything through Argo for all environments beyond dev and hence only grant read-only for users - even to the OpenShift clusters.
Item #2 is the feature that Argo currently lacks (from what I know) and hence needs to run with cluster-admin rights to be able to handle everything for the users. This means the content Argo handles needs to be sanitized externally and a good process needs to be in place for how to accept/sanitize/test/track changes.

[eformat]

hi @oybed, just to add to add to this discussion, for (2)

https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/rbac.md

so, you can create and map arbitrary roles/users/groups/system users - in the argocd configmap to openshift

argocd service accounts only need cluster read at minimum, not write (in this UJ repo we explicitly set this role as too open, but it needs refining or a mechanism to refine in bootstrap for different environments)

• fine tune/restricting the cluster service accounts
  https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/security.md#cluster-rbac

• If you want to deny ArgoCD access to a kind of resource then add it as an excluded resource
  https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/declarative-setup.md#resource-exclusioninclusion

We could also consider adding this to the _templated() argo project function, to restrict what argocd projects can do:

• at the argocd project level, we can restrict cluster-scoped resources from being created - see clusterResourceWhitelist
  https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/declarative-setup.md#projects

[oybed]

@eformat thx for sharing and certainly some good stuff to dig in on. Thanks for the links - I'll take a closer look as time allows.

However, at first glance it looks to be quite a bit of plumbing and structure needed to avoid for it to go sideways - a.k.a.: not as simple as for example the openshift-applier whereas it runs with the permissions you as a user have, or said differently running as oc --as=<user>.

Anyway - good stuff to explore and see what can be iterated on.

[eformat]

yeah 4 sure ... i also was just chatting to @springdo about argocd managing other argocd's .. with that pattern, you may have multiple argocd's deployed within or across clusters, with varying degrees of config applied. i like that pattern ..

…

On Tue, 21 Apr 2020 at 10:17, Øystein Bedin ***@***.***> wrote: @eformat <https://github.com/eformat> thx for sharing and certainly some good stuff to dig in on. Thanks for the links - I'll take a closer look as time allows. However, at first glance it looks to be quite a bit of plumbing and structure needed to avoid for it to go sideways - a.k.a.: not as simple as for example the openshift-applier whereas it runs with the permissions you as a user have, or said differently running as oc --as=<user>. Anyway - good stuff to explore and see what can be iterated on. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFN7IEYIVIP67N3O2H75WTRNTQ2NANCNFSM4LSASZVA> .

[eformat]

also see master -> child argocd addition now

using argocd project in the master argocd .. means we can control what namespaces and cluster resources are whitelisted for that instance as a whole

we could/should also consider arocd projects in the child argocd - eventhough that is controlled by a product team .. probably good practice for namespace control ?