Epic Goal

• Enable customers to specify an alternate cluster role for controller and server components when using Cluster scoped instances
  • Added by Jonathan:
  • By default, a cluster-scoped Argo CD instance in installed into openshift-gitops Namespace
    • Users may instead configure their own cluster-scoped Argo CD instance, by 1) creating a new Namespace, 2) referencing that Namespace in the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable of the Subscription 3) creating an ArgoCD CR within that Namespace.
    • Note: In general, Argo CD will only ever reconcile Application CRs within the same namespace as Argo CD is installed.
      • Even though ARGOCD_CLUSTER_CONFIG_NAMESPACES is defined, it does not mean that Argo CD will reconcile Applications from those Namespaces. As above, Argo CD will only reconcile Applications within its own Namespace.
      • If  you DID want to try out the feature that allows an Argo CD instance to reconcile Applications outside of the Namespace in which it is installed, see the 'apps in any namespace' feature in the docs.
      • However, I think the 'apps in any namespace' feature is out of scope for this story, and I personally don't have a ton of experience with it.
  • My expectation of this epic is that the new environment variables requested by Gerald would affect ANY cluster-scoped Argo CD installs, not just the one in openshift-gitops, and not just any other cluster-scoped instances.

• Currently the Operator supports specifying alternate cluster roles for namespace scoped instances via CONTROLLER_CLUSTER_ROLE and SERVER_CLUSTER_ROLE environment variables in the subscription. The goal of this epic is to provide the same capability for the cluster scoped instances
  • Added by Jonathan:
  • To create a namespace-scoped Argo CD instance: 1) create a Namespace 2) create an ArgoCD CR within that Namespace.
    • A namespace-scoped Argo CD CR only has the ability to deploy into its own Namespace, but you can give that instance permision to deploy to  other Namespaces via the managed-by label on the Namespace.
    • A namespace-scoped Argo CD CR will NOT have any ClusterRoles/Bindings (because, by definition, a namespace-scoped Argo CD install should only be able to view other namespace-scoped resources in a specific set of Namespaces, those with the managed-by label)
  • If you create a namespace-scoped Argo CD instance, as per the above steps, and specify a custom cluster role in the CONTROLLER_CLUSTER_ROLE and SERVER_CLUSTER_ROLE env vars of the Subscription, you should see that a ClusterRole/Binding are created targeting the namespace-scoped Argo CD instance
    • As above, this behaviour is only enabled when these env vars are set (https://argocd-operator.readthedocs.io/en/latest/usage/custom_roles/). When not set, no cluster roles for namespace-scoped instances will be defined.

Why is this important?

• Customers with strict security requirements driven by regulatory or other needs must have the capability to determine the permissions being used by OpenShift GitOps
• The introduction of the Application in Any Namespace feature (TP in 1.7.0) means it is more likely that customers will start using cluster scoped instances to support tenants. The current default role generated by the Operator includes permissions for many things which are a security concern for this use case. For example, it grants permissions to manage cluster configuration settings, machine API, etc which tenants typically should not have access to.

Scenarios

1. Customer must meet regulatory requires such as PCI, NIST, etc which require control over permissions granted to Argo CD instances
2. Customer wants to use cluster scoped instances as a tenant instance instead of namespace scoped instances.

Acceptance Criteria (Mandatory)

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• Operator must dynamically update ClusterRole and ClusterRoleBinding depending on whether this value is set. If the value is set, the operator should not create, or remove if created, the default ClusterRole and update the matching ClusterRoleBinding to point to the specified ClusterRole. If not set, the default ClusterRole should be created and used in the ClusterRoleBinding.

Dependencies (internal and external)

This should be done before Applications in Any Namespace is GA'ed.

Previous Work (Optional):

The aforementioned CONTROLLER_CLUSTER_ROLE and SERVER_CLUSTER_ROLE

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment