ComparisonError: Namespace "guestbook" for Deployment "guestbook-ui" is not managed

[cnukwas]

I am new to Argo CD and OpenShift GitOps. I have set up Argo CD instance in one of the OpenShift namespaces and trying to deploy Argo guestbook example in guestbook namespace and getting this error. I believe this is a valid error, but no clue on if it's a Argo CD or OpenShift GitOps operator issue. I am posting here in case anyone is ran into similar issue when Argo CD instance is set up at Namespace scope, rather than using default Argo CD instance created OpenShift GitOps operator(1.1.2 with Argo CD 2.0.0) installation as a cluster admin. Posting here to get community feedback, going to check with OpenShift folks as well.

ComparisonError Namespace "guestbook" for Deployment "guestbook-ui" is not managed

Created 2 namespaces myns-argo and guestbook, created an instance of Argo in the myns-argo ns, created a 'admin' rolebinding in the guestbook ns for the Argo service account(myns-argo-argocd-application-controller) as below.

Based on what I read or saw from a OpenShift video, this is supposed to work, but it's not. Either this no longer works or I am missing something here.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: guestbook-ns-allowing-myns-argo
  namespace: guestbook
subjects:
  - kind: ServiceAccount
    name: myns-argo-argocd-application-controller
    namespace: myns-argo
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin

Update:
Noticed that Argo Cluster configuration had only myns-argo namespace entry only, so added guestbook to the list and the entry now looks as below.

NAMESPACES: myns-argo, guestbook

Now getting additional errors, so it appears that Argo CD instance requires clusterrole RBAC even when it's set up at namespace scope(if that's the right terminology to use). I read about exclusion and inclusion list for the Argo instance, is that what needs to be done here to limit Argo instance access to certain resources only?

ComparisonError
failed to sync cluster https://111.11.0.1:443: failed to load initial state of resource IngressController.operator.openshift.io: ingresscontrollers.operator.openshift.io is forbidden: User "system:serviceaccount:myns-argo:myns-argo-argocd-application-controller" cannot list resource "ingresscontrollers" in API group "operator.openshift.io" in the namespace "guestbook"

ComparisonError
failed to sync cluster https://111.110.1:443: failed to load initial state of resource Prometheus.monitoring.coreos.com: prometheuses.monitoring.coreos.com is forbidden: User "system:serviceaccount:myns-argo:myns-argo-argocd-application-controller" cannot list resource "prometheuses" in API group "monitoring.coreos.com" in the namespace "guestbook"

Thanks

[jannfis]

Hi @cnukwas,

unfortunately, binding the application-controller's SA to the admin ClusterRole is not sufficient. You will need to create a role in the target namespace (e.g. guestbook) that allows reading of all resources. It seems not all namespaced APIs in OpenShift are reconciling themselves into the admin role.

So, you will need an additional Role in the guestbook namespace much like the following:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role     
metadata:
  name: argocd-application-controller
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - get
  - list
  - watch

and then bind it to your ServiceAccount used by argocd-application-controller, e.g to

subjects:
  - kind: ServiceAccount
    name: myns-argo-argocd-application-controller
    namespace: myns-argo

[cnukwas]

@jannfis, your right. Thank you very much the quick response. It was a stupid mistake on my part. I know see that guestbook namespace app is being deployed into the Argo CD instance created in myns-argo namespace.

Noticed that I get the original ComparisonError: Namespace "guestbook" for Deployment "guestbook-ui" is not managed error, if I don't add the guestbook namespace to Argo Cluster configruration namespaces field list as below. I kind of understand why it needs to be done, wish I don't have to do that if I want to the namespace scoped Argo CD instance to deploy Kubernetes resources into other namespaces created for the same team, or into a different environment namespace(s) for the same app.

NAMESPACES: ns-scope-argo-instance, guestbook

Interested to know if any of these features/fixes have already been requested or become easier to manage in the next version of GitOps Operator/Argo.

Thanks again.

[jannfis]

Hey @cnukwas, yes, it's tedious to configure the permissions right now, I do agree. However, especially in the case of the Operator (whether Argo CD Operator upstream or the GitOps Operator downstream), it is a necessary evil to prevent privilege escalation that may happen due to the Operator's ability to let users install Argo CD into any namespace.

For the Operators, we will implement a feature that will set up all required permissions and configuration by simply putting a label on the namespace you want to manage. This will come soon, and should make life of Operator users much easier.

[cnukwas]

Makes sense, thanks. Looking forward for the improvements. Coming to the OpenShift GitOps operator set up, the default Argo instance is not recommended for use by application teams though we can restrict what teams can do by adding Argo RBAC, it's supposed to be used by cluster-admin for managing cluster configurations. Based on that, it's my understanding that we should implement additional roles/rolebindings discussed in this thread, for setting up additional Argo CD instances in a generic namespace, for multi-tenant OpenShift clusters, with necessary Argo Projects RBAC, to restrict Argo CD access to a set of namespaces.

[jannfis]

IMHO, this is something we shouldn't discuss upstream, because it is very specific to OpenShift GitOps, and not Argo CD.

[cnukwas]

No worries, thanks. I will post a question to OpenShift support and go from there.