Default ClusterRole/Binding for argocd-application-controller does not include CRs about gitops-operator HOT 6 CLOSED

@iam-veeramalla I think it can be closed

from gitops-operator.

+1 This one is really important to get in place, or else the applicable use of argo is really limited.
We use a lot of CRs and usually create a clusterrole for each such onboarding, labelling them with bac.authorization.k8s.io/aggregate-to-admin: "true" in order to hand them out by scale.

I wish the role which each argo binds to can either be influenced by the CR creating argo-instances (gives better control), or that the instances bind to a common cluster-role, which can be aggregated to as described above.

from gitops-operator.

Hmm, this does no longer seem to be a problem as of v1.2.1 of the operator? The role argocd-argocd-application-controller seems to include most/all CRs, but I cannot find anything in the changelog (or update of this issue), among them:

k get role argocd-argocd-application-controller  -o yaml|grep -i sealedse
  - sealedsecrets

from gitops-operator.

Hi @rgordill @davidkarlsen , There are a couple of ways in which you can extend the permissions of Argo CD application controller.

1. By creating a new cluster role/ cluster role binding.
   https://github.com/redhat-developer/gitops-operator/blob/master/docs/OpenShift%20GitOps%20Usage%20Guide.md#additional-permissions

2. Using custom cluster roles(if are talking about managing other namespaces)
   https://github.com/redhat-developer/gitops-operator/blob/master/docs/OpenShift%20GitOps%20Usage%20Guide.md#deploy-resources-to-a-different-namespace-with-custom-role

from gitops-operator.

Please let me know if this can be closed.

from gitops-operator.

Dunno. After almost a year, maybe the documents are updated and there is no need for anything else. Maybe it is better to give full access to the whole cluster to the service account. Yes, you can close this issue, as I cannot tell if it is relevant with latests releases.

from gitops-operator.