Argo CD instance

To manage cluster configurations or deploy applications, you can install and deploy a new user-defined Argo CD instance.

As a cluster administrator, when you give an Argo CD access to a namespace by using the argocd.argoproj.io/managed-by label, the Argo CD assumes namespace-admin privileges. The Red Hat OpenShift GitOps Operator then automatically creates role bindings for all managed namespaces of the following GitOps control plane components:

When you provide namespaces to non-administrator users, for example, development teams, they can use the namespace-admin privileges to modify objects such as network policies. Installing an Argo CD instance in these namespaces gives the development teams admin privileges and indirectly elevates their assigned privileges. These roles are highly privileged and can delete all resources. As a preventive action, you can define a specific set of reduced permissions to meet your security requirements by configuring common cluster roles for all managed namespaces in the role bindings that the Operator creates for the Argo CD Application Controller and Argo CD server components.

To configure common cluster roles for all managed namespaces, you can specify user-defined cluster roles for the CONTROLLER_CLUSTER_ROLE and SERVER_CLUSTER_ROLE environment variables in the Operator’s Subscription object YAML file. As a result, instead of creating the default admin role, the Operator uses the existing user-defined cluster roles and creates role bindings for all managed namespaces.

Argo CD-server and Argo CD-repo-server workloads are stateless. To better distribute your workloads among pods, you can increase the number of Argo CD-server and Argo CD-repo-server replicas. However, if a horizontal autoscaler is enabled on the Argo CD-server, it overrides the number of replicas you set.

To allow Argo CD to manage resources in other namespaces apart from where it is installed, configure the target namespace with a argocd.argoproj.io/managed-by label.

In a multi-tenant cluster, users might have to deal with multiple instances of Argo CD. For example, after installing an Argo CD instance in your namespace, you might find a different Argo CD instance attached to the Argo CD console link, instead of your own Argo CD instance, in the Console Application Launcher.

You can customize the Argo CD console link by setting the DISABLE_DEFAULT_ARGOCD_CONSOLELINK environment variable:

The GitOps Operator supports configurable imagePullPolicy settings at multiple levels, providing administrators with flexible control over how container images are pulled for Argo CD components.

The imagePullPolicy configuration follows a hierarchical precedence system, where the most specific configuration takes priority:

You can define a global image pull policy for all Argo CD instances managed by the Operator by setting the IMAGE_PULL_POLICY environment variable in the Operator’s Subscription. For example:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
spec:
  config:
    env:
      - name: IMAGE_PULL_POLICY
        value: "Always"

An instance-level configuration overrides the Operator-level policy and applies the configuration only to the specific instance defined in the CR.

The following example shows how to configure imagePullPolicy for all the components in an Argo CD instance.

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd
  namespace: argocd
spec:
  imagePullPolicy: IfNotPresent

The following example shows how to define imagePullPolicy for all the components in a GitOpsService instance.

apiVersion: pipelines.openshift.io/v1alpha1
kind: GitOpsService
metadata:
  name: gitops-service
  namespace: openshift-gitops
spec:
  imagePullPolicy: Always

The following example shows how to set imagePullPolicy for all the components in a RolloutsManager instance.

apiVersion: argoproj.io/v1alpha1
kind: RolloutManager
metadata:
  name: argo-rollout
  labels:
    example: basic
spec:
  imagePullPolicy: Always

By configuring the imagePullPolicy at an appropriate level, you can control how frequently container images are updated for your GitOps components.

The Argo CD Custom Resource consists of the following properties:

The following properties are available for configuring the repo server component:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: repo
spec:
  repo:
    systemCATrust:
      secrets:
        - name: my-local-cert-secret
          items:
            - key: key-name-in-the-secret-object
              path: desired-file-name-of-the-certificate.crt
      configMaps:
        - name: my-local-cert-cm
          items: []

Argo CD notifications allow you to send notifications to external services when events occur in your Argo CD instance. For example, you can send notifications to Slack or email when a sync operation fails. By default, notifications are disabled in Argo CD instances.

oc patch argocd openshift-gitops -n openshift-gitops --type merge --patch '{"spec": {"notifications": {"enabled": true}}}'

Argo CD provides support for Helm, Jsonnet, and Kustomize as built-in config management tools. To use a different config management tool, or to enable features not provided by the built-in config management tools, you can use the Config Management Plugin (CMP).

In Argo CD, the CMP is specified as a sidecar container for the Argo CD repo server container. For more information, see "Config Management Plugins".

In the Red Hat OpenShift GitOps Operator, you can configure the Config Management plugin as a sidecar container in the Argo CD custom resource (CR). When you configure the sidecar container, you either specify an off-the-shelf or a custom-built container image. If you do not specify an image, the system uses the same image as the repo server for the plugin.

To configure a sidecar container in the Red Hat OpenShift GitOps Operator, add the .spec.repo.sidecarContainers key in the Argo CD CR.

Example Config Management Plugin configuration:

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
 name: <my_argocd>
spec:
 repo:
   sidecarContainers:
     - name: <my_cmp>
       command: [/var/run/argocd/argocd-cmp-server]
       image: <my_image>
       securityContext:
         runAsNonRoot: <true>
         runAsUser: 

       volumeMounts:
         - mountPath: /var/run/argocd
           name: <var_files>
         - mountPath: /home/argocd/cmp-server/plugins
           name: plugins
         - mountPath: /tmp
           name: tmp
         - mountPath: /home/argocd/cmp-server/config/plugin.yaml
           subPath: <plugin.yaml>
           name: <cmp_plugin>

where:

The NotificationsConfiguration resource is a Kubernetes custom resource (CR) that manages notifications in a Kubernetes cluster. In Red Hat OpenShift GitOps, you can add templates, triggers, services, and subscription resources to an Argo CD Notifications config map by using the NotificationsConfiguration CR.

When you create a cluster in Red Hat OpenShift GitOps with notifications enabled, a NotificationsConfiguration CR is created by default with the name default-notifications-configuration.

Any change made in the existing configuration of the NotificationsConfiguration CR is replicated in the Argo CD Notifications config map. For example, if the user adds trigger configuration in the NotificationsConfiguration resource, this configuration is read, processed, and updated in the Argo CD Notifications config map.

The following examples define how to add templates, triggers, services, and subscription resources to the Argo CD argocd-notification-cm config map by using the default-notifications-configuration custom resource.

Example for templates:

apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
 name: default-notifications-configuration
spec:
 templates:
  template.my-custom-template: |
    message: |
     Application details: {{.context.argocdUrl}}/applications/{{.app.metadata.name}}.

where:

Example for triggers:

apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
 name: default-notifications-configuration
spec:
 triggers:
  trigger.on-sync-status-unknown: |
   - when: app.status.sync.status == 'Unknown'
   send: [my-custom-template]

where:

Example for services:

apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
 name: default-notifications-configuration
spec:
 services:
  service.slack: |
    token: $slack-token
    username: <override-username> # optional username
    icon: <override-icon> # optional icon for the message (supports both emoji and url notation)

where:

Example for subscriptions:

apiVersion: argoproj.io/v1alpha1
kind: NotificationsConfiguration
metadata:
 name: default-notifications-configuration
spec:
 subscriptions:
  subscriptions: |
    # subscription for on-sync-status-unknown trigger notifications
    - recipients:
      - slack:test2
      - email:test@gmail.com
      triggers:
      - on-sync-status-unknown
    # subscription restricted to applications with matching labels only
    - recipients:
      - slack:test3
      selector: test=true
      triggers:
      - on-sync-status-unknown

where:

You can configure the NotificationsConfiguration CR by using the OpenShift Container Platform web console or the CLI (oc).

By default, Argo CD manages notification configuration only within the control plane namespace. With Red Hat OpenShift GitOps Operator, cluster administrators can enable teams to manage notification settings for their applications from additional namespaces.

To enable this functionality, configure the target namespaces in the Argo CD custom resource (CR). The Red Hat OpenShift GitOps Operator reconciles the corresponding notification resources only for namespaces that are explicitly defined in the ArgoCD CR.

Red Hat OpenShift GitOps Operator enhances multi-instance support by improving annotation-based resource tracking in Argo CD.Multiple Argo CD instances can use annotation-based tracking by assigning each instance a unique installationID, which enables them to correctly differentiate resources with identical application names, prevent conflicts, avoid infinite sync loops, and operate safely in parallel.

You can perform the following actions by using the OpenShift Container Platform web console: