Skip to content

gitops-cluster-scoped-instance.adoc

Latest commit

 

History

History
35 lines (24 loc) · 2.26 KB

gitops-cluster-scoped-instance.adoc

File metadata and controls

35 lines (24 loc) · 2.26 KB

Cluster-scoped instance

A cluster-scoped instance is intended to deploy and manage resources across a cluster.

Note

If you intend to use the Applications in any namespace feature, choose the mode of the Argo CD instance scope as cluster-scoped instance.

Cluster-scoped instances have access to cluster-level resources and thus are typically, but not always, used for cluster configuration. You can choose to elevate certain namespace-scoped Argo CD instances to become cluster-scoped. To elevate the instances, you must change the Subscription resource of the {gitops-shortname} Operator.

Important

  • Ensure you give careful consideration while elevating instances.

  • Do not elevate instances that are self-managed by application delivery teams. Elevating such instances would be a severe security risk to the cluster because this action makes users of self-managed instances cluster administrators, and gives them full control over the permissions.

Much care must be taken when setting up multitenancy in Argo CD. For example, if cluster administrators manage a shared Argo CD instance for many application teams, a custom cluster-scoped instance might be appropriate.

How does this method work?

To prevent users from deploying Argo CD instances with cluster-admin privileges, you must identify the namespaces with cluster privileges by using the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable in the Subscription resource.

Because non-cluster administrators do not have access to the Subscription resource, they cannot elevate the privileges of their instance and bypass cluster security.

When an instance is designated as cluster-scoped, the Operator automatically creates cluster roles and cluster role bindings. These are created for the Argo CD Application Controller and server service accounts in that namespace.

This default role is not intended to be equal to the standard cluster-admin role. It gives a much smaller set of permissions. You can extend these permissions by creating additional cluster roles or cluster role bindings as needed.