Argo CD supports managing resources on remote clusters
The GitOps Operator also supports that pattern,
permission management on remote clusters is fully manual currently and this is an area
Argo CD uses a dedicated ServiceAccount on the remote cluster to manage resources.
This ServiceAccount has to be created manually on the remote cluster
It needs an appropriate Role or ClusterRole bound to it.
hen, the remote cluster’s credentials have to be configured to be used by Argo CD.
Each ArgoCD instanced managed by GitOps Operator should be configured to use a dedicated ServiceAccount on the remote cluster. Depending on the scope of the ArgoCD instance, either a Role (for namespace scoped instances) or a ClusterRole (for cluster scoped instances) should be bound to that ServiceAccount.
Creating the service account on the remote cluster
First, you will need either to create a ServiceAccount on the remote cluster or choose an existing one. We will set up a dedicated ServiceAccount for this purpose:
After the ServiceAccount has been set up, we need to get (and memorize) its credentials:
Creating the permissions on the remote cluster
Now that we have created the ServiceAccount, we need to set-up proper permissions for it so Argo CD can use the ServiceAccount to connect to the remote cluster and manage the resources there. This will require either Role and RoleBinding or ClusterRole and ClusterRoleBinding on the remote cluster, bound to the ServiceAccount we just created.
Configuring Argo CD instance to connect to remote cluster
The final step is to configure Argo CD to use the newly set up credentials to connect to the remote cluster. This is done by creating a new Secret resource in the namespace of your Argo CD installation that follows some convention for its data and metadata.
ACM docu: https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/applications/managing-applications#gitops-config
From ArgoCD:
Permissions on remote clusters
Argo CD supports managing resources on remote clusters The GitOps Operator also supports that pattern, permission management on remote clusters is fully manual currently and this is an area
Argo CD uses a dedicated ServiceAccount on the remote cluster to manage resources. This ServiceAccount has to be created manually on the remote cluster It needs an appropriate Role or ClusterRole bound to it. hen, the remote cluster’s credentials have to be configured to be used by Argo CD.
Each ArgoCD instanced managed by GitOps Operator should be configured to use a dedicated ServiceAccount on the remote cluster. Depending on the scope of the ArgoCD instance, either a Role (for namespace scoped instances) or a ClusterRole (for cluster scoped instances) should be bound to that ServiceAccount. Creating the service account on the remote cluster First, you will need either to create a ServiceAccount on the remote cluster or choose an existing one. We will set up a dedicated ServiceAccount for this purpose:
After the ServiceAccount has been set up, we need to get (and memorize) its credentials:
Creating the permissions on the remote cluster
Now that we have created the ServiceAccount, we need to set-up proper permissions for it so Argo CD can use the ServiceAccount to connect to the remote cluster and manage the resources there. This will require either Role and RoleBinding or ClusterRole and ClusterRoleBinding on the remote cluster, bound to the ServiceAccount we just created. Configuring Argo CD instance to connect to remote cluster The final step is to configure Argo CD to use the newly set up credentials to connect to the remote cluster. This is done by creating a new Secret resource in the namespace of your Argo CD installation that follows some convention for its data and metadata.