Ricerca

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 5. GitOps

download PDF

5.1. Red Hat OpenShift GitOps release notes

Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud native applications. Red Hat OpenShift GitOps ensures consistency in applications when you deploy them to different clusters in different environments, such as: development, staging, and production. Red Hat OpenShift GitOps helps you automate the following tasks:

  • Ensure that the clusters have similar states for configuration, monitoring, and storage
  • Recover or recreate clusters from a known state
  • Apply or revert configuration changes to multiple OpenShift Container Platform clusters
  • Associate templated configuration with different environments
  • Promote applications across clusters, from staging to production

For an overview of Red Hat OpenShift GitOps, see Understanding OpenShift GitOps.

5.1.1. Compatibility and support matrix

Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.

In the table, features are marked with the following statuses:

  • TP: Technology Preview
  • GA: General Availability
  • NA: Not Applicable
Important

In OpenShift Container Platform 4.13, the stable channel has been removed. Before upgrading to OpenShift Container Platform 4.13, if you are already on the stable channel, choose the appropriate channel and switch to it.

OpenShift GitOpsComponent VersionsOpenShift Versions

Version

kam

Helm

Kustomize

Argo CD

ApplicationSet

Dex

RH SSO

 

1.8.0

0.0.47 TP

3.10.0 GA

4.5.7 GA

2.6.3 GA

NA

2.35.1 GA

7.5.1 GA

4.10-4.13

1.7.0

0.0.46 TP

3.10.0 GA

4.5.7 GA

2.5.4 GA

NA

2.35.1 GA

7.5.1 GA

4.10-4.12

1.6.0

0.0.46 TP

3.8.1 GA

4.4.1 GA

2.4.5 GA

GA and included in ArgoCD component

2.30.3 GA

7.5.1 GA

4.8-4.11

1.5.0

0.0.42 TP

3.8.0 GA

4.4.1 GA

2.3.3 GA

0.4.1 TP

2.30.3 GA

7.5.1 GA

4.8-4.11

1.4.0

0.0.41 TP

3.7.1 GA

4.2.0 GA

2.2.2 GA

0.2.0 TP

2.30.0 GA

7.4.0 GA

4.7-4.10

1.3.0

0.0.40 TP

3.6.0 GA

4.2.0 GA

2.1.2 GA

0.2.0 TP

2.28.0 GA

7.4.0 GA

4.7-4.9, 4.6 with limited GA support

1.2.0

0.0.38 TP

3.5.0 GA

3.9.4 GA

2.0.5 GA

0.1.0 TP

NA

7.4.0 GA

4.8

1.1.0

0.0.32 TP

3.5.0 GA

3.9.4 GA

2.0.0 GA

NA

NA

NA

4.7

  • kam is the Red Hat OpenShift GitOps Application Manager command-line interface (CLI).
  • RH SSO is an abbreviation for Red Hat SSO.

5.1.1.1. Technology Preview features

The features mentioned in the following table are currently in Technology Preview (TP). These experimental features are not intended for production use.

Table 5.1. Technology Preview tracker
FeatureTP in Red Hat OpenShift GitOps versionsGA in Red Hat OpenShift GitOps versions

ApplicationSet Progressive Rollout Strategy

1.8.0

NA

Multiple sources for an application

1.8.0

NA

Argo CD applications in non-control plane namespaces

1.7.0

NA

Argo CD Notifications controller

1.6.0

NA

The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console 

1.1.0

NA

5.1.2. Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

5.1.3. Release notes for Red Hat OpenShift GitOps 1.8.4

Red Hat OpenShift GitOps 1.8.4 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.

5.1.3.1. New features

The current release adds the following improvements:

  • With this update, the bundled Argo CD has been updated to version 2.6.13.

5.1.3.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, Argo CD was becoming unresponsive when there was an increase in namespaces and applications. The functions competing for resources caused a deadlock. This update fixes the issue by removing the deadlock. Now, you should not experience crashes or unresponsiveness when there is an increase in namespaces or applications. GITOPS-3192
  • Before this update, the Argo CD application controller resource could suddenly stop working when resynchronizing applications. This update fixes the issue by adding logic to prevent a cluster cache deadlock. Now, applications should resynchronize successfully. GITOPS-3052
  • Before this update, there was a mismatch in the RSA key for known hosts in the argocd-ssh-known-hosts-cm config map. This update fixes the issue by matching the RSA key with the upstream project. Now, you can use the default RSA keys on default deployments. GITOPS-3144
  • Before this update, an old Redis image version was used when deploying the Red Hat OpenShift GitOps Operator, which resulted in vulnerabilities. This update fixes the vulnerabilities on Redis by upgrading it to the latest version of the registry.redhat.io/rhel-8/redis-6 image. GITOPS-3069
  • Before this update, users could not connect to Microsoft Team Foundation Server (TFS) type Git repositories through Argo CD deployed by the Operator. This update fixes the issue by updating the Git version to 2.39.3 in the Operator. Now, you can set the Force HTTP basic auth flag during repository configurations to connect with the TFS type Git repositories. GITOPS-1315

5.1.3.3. Known issues

  • Currently, Red Hat OpenShift GitOps 1.8.4 is not available in the latest channel of OpenShift Container Platform 4.10 and 4.11. The latest channel is taken by GitOps 1.9.z, which is only released on OpenShift Container Platform 4.12 and later versions.

    As a workaround, switch to the gitops-1.8 channel to get the new update. GITOPS-3158

5.1.4. Release notes for Red Hat OpenShift GitOps 1.8.3

Red Hat OpenShift GitOps 1.8.3 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.

5.1.4.1. Errata updates

5.1.4.1.1. RHBA-2023:3206 and RHSA-2023:3229 - Red Hat OpenShift GitOps 1.8.3 security update advisory

Issued: 2023-05-18

The list of security fixes that are included in this release is documented in the following advisories:

If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

5.1.4.2. Fixed issues

  • Before this update, when Autoscale was enabled and the horizontal pod autoscaler (HPA) controller tried to edit the replica settings in server deployment, the Operator overwrote it. In addition, any changes specified to the autoscaler parameters were not propagated correctly to the HPA on the cluster. This update fixes the issue. Now the Operator reconciles on replica drift only if Autoscale is disabled and the HPA parameters are updated correctly. GITOPS-2629

5.1.5. Release notes for Red Hat OpenShift GitOps 1.8.2

Red Hat OpenShift GitOps 1.8.2 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.

5.1.5.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, when you configured Dex using the .spec.dex parameter and tried to log in to the Argo CD UI by using the LOG IN VIA OPENSHIFT option, you were not able to log in. This update fixes the issue.

    Important

    The spec.dex parameter in the ArgoCD CR is deprecated. In a future release of Red Hat OpenShift GitOps v1.9, configuring Dex using the spec.dex parameter in the ArgoCD CR is planned to be removed. Consider using the .spec.sso parameter instead. See "Enabling or disabling Dex using .spec.sso". GITOPS-2761

  • Before this update, the cluster and kam CLI pods failed to start with a new installation of Red Hat OpenShift GitOps v1.8.0 on the OpenShift Container Platform 4.10 cluster. This update fixes the issue and now all pods run as expected. GITOPS-2762

5.1.6. Release notes for Red Hat OpenShift GitOps 1.8.1

Red Hat OpenShift GitOps 1.8.1 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.

5.1.6.1. Errata updates

5.1.6.1.1. RHSA-2023:1452 - Red Hat OpenShift GitOps 1.8.1 security update advisory

Issued: 2023-03-23

The list of security fixes that are included in this release is documented in the RHSA-2023:1452 advisory.

If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

5.1.7. Release notes for Red Hat OpenShift GitOps 1.8.0

Red Hat OpenShift GitOps 1.8.0 is now available on OpenShift Container Platform 4.10, 4.11, 4.12, and 4.13.

5.1.7.1. New features

The current release adds the following improvements:

  • With this update, you can add support for the ApplicationSet Progressive Rollout Strategy feature. Using this feature, you can enhance the ArgoCD ApplicationSet resource to embed a rollout strategy for a progressive application resource update after you modify the ApplicationSet spec or Application templates. When you enable this feature, applications are updated in a declarative order instead of simultaneously. GITOPS-956

    Important

    ApplicationSet Progressive Rollout Strategy is a Technology Preview feature.

  • With this update, the Application environments page in the Developer perspective of the OpenShift Container Platform web console is decoupled from the Red Hat OpenShift GitOps Application Manager command-line interface (CLI), kam. You do not have to use the kam CLI to generate Application Environment manifests for the environments to show up in the Developer perspective of the OpenShift Container Platform web console. You can use your own manifests, but the environments must still be represented by namespaces. In addition, specific labels and annotations are still needed. GITOPS-1785
  • With this update, the Red Hat OpenShift GitOps Operator and the kam CLI are now available to use on ARM architecture on OpenShift Container Platform. GITOPS-1688

    Important

    spec.sso.provider: keycloak is not yet supported on ARM.

  • With this update, you can enable workload monitoring for specific Argo CD instances by setting the .spec.monitoring.enabled flag value to true. As a result, the Operator creates a PrometheusRule object that contains alert rules for each Argo CD component. These alert rules trigger an alert when the replica count of the corresponding component has drifted from the desired state for a certain amount of time. The Operator will not overwrite the changes made to the PrometheusRule object by the users. GITOPS-2459
  • With this update, you can pass command arguments to the repo server deployment using the Argo CD CR. GITOPS-2445

    For example:

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
    spec:
      repo:
        extraRepoCommandArgs:
          - --max.combined.directory.manifests.size
          - 10M

5.1.7.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, you could set the ARGOCD_GIT_MODULES_ENABLED environment variable only on the openshift-gitops-repo-server pod and not on the ApplicationSet Controller pod. As a result, when using the Git generator, Git submodules were cloned during the generation of child applications because the variable was missing from the ApplicationSet Controller environment. In addition, if the credentials required to clone these submodules were not configured in ArgoCD, the application generation failed. This update fixes the issue; you can now add any environment variables such as ArgoCD_GIT_MODULES_ENABLED to the ApplicationSet Controller pod using the Argo CD CR. The ApplicationSet Controller pod then successfully generates child applications from the cloned repository and no submodule is cloned in the process. GITOPS-2399

    For example:

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: basic
    spec:
      applicationSet:
        env:
         - name: ARGOCD_GIT_MODULES_ENABLED
           value: "true"
  • Before this update, while installing the Red Hat OpenShift GitOps Operator v1.7.0, the default argocd-cm.yml config map file created for authenticating Dex contained the base64-encoded client secret in the format of a key:value pair. This update fixes this issue by not storing the client secret in the default argocd-cm.yml config map file. Instead, the client secret is inside an argocd-secret object now, and you can reference it inside the configuration map as a secret name. GITOPS-2570

5.1.7.3. Known issues

  • When you deploy applications using your manifests without using the kam CLI and view the applications in the Application environments page in the Developer perspective of the OpenShift Container Platform web console, the Argo CD URL to the corresponding application does not load the page as expected from the Argo CD icon in the card. GITOPS-2736

5.1.8. Release notes for Red Hat OpenShift GitOps 1.7.4

Red Hat OpenShift GitOps 1.7.4 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.

5.1.8.1. Errata updates

5.1.8.1.1. RHSA-2023:1454 - Red Hat OpenShift GitOps 1.7.4 security update advisory

Issued: 2023-03-23

The list of security fixes that are included in this release is documented in the RHSA-2023:1454 advisory.

If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

5.1.9. Release notes for Red Hat OpenShift GitOps 1.7.3

Red Hat OpenShift GitOps 1.7.3 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.

5.1.9.1. Errata updates

5.1.9.1.1. RHSA-2023:1454 - Red Hat OpenShift GitOps 1.7.3 security update advisory

Issued: 2023-03-23

The list of security fixes that are included in this release is documented in the RHSA-2023:1454 advisory.

If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

5.1.10. Release notes for Red Hat OpenShift GitOps 1.7.1

Red Hat OpenShift GitOps 1.7.1 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.

5.1.10.1. Errata updates

5.1.10.1.1. RHSA-2023:0467 - Red Hat OpenShift GitOps 1.7.1 security update advisory

Issued: 2023-01-25

The list of security fixes that are included in this release is documented in the RHSA-2023:0467 advisory.

If you have installed the Red Hat OpenShift GitOps Operator, run the following command to view the container images in this release:

$ oc describe deployment gitops-operator-controller-manager -n openshift-operators

5.1.11. Release notes for Red Hat OpenShift GitOps 1.7.0

Red Hat OpenShift GitOps 1.7.0 is now available on OpenShift Container Platform 4.10, 4.11, and 4.12.

5.1.11.1. New features

The current release adds the following improvements:

  • With this update, you can add environment variables to the Notifications controller. GITOPS-2313
  • With this update, the default nodeSelector "kubernetes.io/os": "linux" key-value pair is added to all workloads such that they only schedule on Linux nodes. In addition, any custom node selectors are added to the default and take precedence if they have the same key. GITOPS-2215
  • With this update, you can set custom node selectors in the Operator workloads by editing their GitopsService custom resource. GITOPS-2164
  • With this update, you can use the RBAC policy matcher mode to select from the following options: glob (default) and regex.GITOPS-1975
  • With this update, you can customize resource behavior using the following additional subkeys:

    SubkeyKey formMapped field in argocd-cm

    resourceHealthChecks

    resource.customizations.health.<group_kind>

    resource.customizations.health

    resourceIgnoreDifferences

    resource.customizations.ignoreDifferences.<group_kind>

    resource.customizations.ignoreDifferences

    resourceActions

    resource.customizations.actions.<group_kind>

    resource.customizations.actions

    GITOPS-1561

    Note

    In future releases, there is a possibility to deprecate the old method of customizing resource behavior by using only resourceCustomization and not subkeys.

  • With this update, to use the Environments page in the Developer perspective, you must upgrade if you are using a Red Hat OpenShift GitOps version prior to 1.7 and OpenShift Container Platform 4.15 or above. GITOPS-2415
  • With this update, you can create applications, which are managed by the same control plane Argo CD instance, in any namespace in the same cluster. As an administrator, perform the following actions to enable this update:

    • Add the namespace to the .spec.sourceNamespaces attribute for a cluster-scoped Argo CD instance that manages the application.
    • Add the namespace to the .spec.sourceNamespaces attribute in the AppProject custom resource that is associated with the application. 

      GITOPS-2341

Important

Argo CD applications in non-control plane namespaces is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

  • With this update, Argo CD supports the Server-Side Apply feature, which helps users to perform the following tasks:

    • Manage large resources which are too big for the allowed annotation size of 262144 bytes.
    • Patch an existing resource that is not managed or deployed by Argo CD.

      You can configure this feature at application or resource level. GITOPS-2340

5.1.11.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, Red Hat OpenShift GitOps releases were affected by an issue of Dex pods failing with CreateContainerConfigError error when the anyuid SCC was assigned to the Dex service account. This update fixes the issue by assigning a default user id to the Dex container. GITOPS-2235
  • Before this update, Red Hat OpenShift GitOps used the RHSSO (Keycloak) through OIDC in addition to Dex. However, with a recent security fix, the certificate of RHSSO could not be validated when configured with a certificate not signed by one of the well-known certificate authorities. This update fixes the issue; you can now provide a custom certificate to verify the KeyCloak’s TLS certificate while communicating with it. In addition, you can add rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles such changes and updates the oidc.config in argocd-cm config map with the PEM encoded root certificate. GITOPS-2214

Example Argo CD with Keycloak configuration:

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  sso:
    keycloak:
      rootCA: '<PEM encoded root certificate>'
    provider: keycloak
.......
.......
  • Before this update, the application controllers restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the statefulset application controller. GITOPS-2153

5.1.11.3. Known issues

  • Before this update, the Operator did not reconcile the mountsatoken and ServiceAccount settings for the repository server. While this has been fixed, deletion of the service account does not revert to the default. GITOPS-1873
  • Workaround: Manually set the spec.repo.serviceaccountfield to thedefault service account. GITOPS-2452

5.1.12. Release notes for Red Hat OpenShift GitOps 1.6.7

Red Hat OpenShift GitOps 1.6.7 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.12.1. Fixed issues

The following issue has been resolved in the current release:

  • Before this update, all versions of the Argo CD Operator, starting with v0.5.0 were vulnerable to an information disclosure flaw. As a result, unauthorized users could enumerate application names by inspecting API error messages and use the discovered application names as the starting point of another attack. For example, the attacker might use their knowledge of an application name to convince an administrator to grant higher privileges. This update fixes the CVE-2022-41354 error. GITOPS-2635, CVE-2022-41354

5.1.13. Release notes for Red Hat OpenShift GitOps 1.6.6

Red Hat OpenShift GitOps 1.6.6 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.13.1. Fixed issues

The following issue has been resolved in the current release:

  • Before this update, all versions of the Argo CD Operator, starting with v0.5.0 were vulnerable to an information disclosure flaw. As a result, unauthorized users could enumerate application names by inspecting API error messages and use the discovered application names as the starting point of another attack. For example, the attacker might use their knowledge of an application name to convince an administrator to grant higher privileges. This update fixes the CVE-2022-41354 error. GITOPS-2635, CVE-2022-41354

5.1.14. Release notes for Red Hat OpenShift GitOps 1.6.4

Red Hat OpenShift GitOps 1.6.4 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.14.1. Fixed issues

  • Before this update, all versions of Argo CD v1.8.2 and later were vulnerable to an improper authorization bug. As a result, Argo CD would accept tokens for audiences who might not be intended to access the cluster. This issue is now fixed. CVE-2023-22482

5.1.15. Release notes for Red Hat OpenShift GitOps 1.6.2

Red Hat OpenShift GitOps 1.6.2 is now available on OpenShift Container Platform 4.8, 4.9, 4.10 and 4.11.

5.1.15.1. New features

  • This release removes the DISABLE_DEX environment variable from the openshift-gitops-operator CSV file. As a result, this environment variable is no longer set when you perform a fresh installation of Red Hat OpenShift GitOps. GITOPS-2360

5.1.15.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, the subscription health check was marked degraded for missing InstallPlan when more than 5 Operators were installed in a project. This update fixes the issue. GITOPS-2018
  • Before this update, the Red Hat OpenShift GitOps Operator would spam the cluster with a deprecation notice warning whenever it detected that an Argo CD instance used deprecated fields. This update fixes this issue and shows only one warning event for each instance that detects a field. GITOPS-2230
  • From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2352

5.1.16. Release notes for Red Hat OpenShift GitOps 1.6.1

Red Hat OpenShift GitOps 1.6.1 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.16.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller StatefulSet object. GITOPS-2153
  • Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak’s TLS certificate when communicating with it. You can add the rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles this change and updates the oidc.config field in the argocd-cm ConfigMap with the PEM-encoded root certificate. GITOPS-2214

    Note

    Restart the Argo CD server pod after updating the .spec.keycloak.rootCA field.

    For example:

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: basic
    spec:
      sso:
        provider: keycloak
        keycloak:
         rootCA: |
           ---- BEGIN CERTIFICATE ----
           This is a dummy certificate
           Please place this section with appropriate rootCA
           ---- END CERTIFICATE ----
      server:
        route:
          enabled: true
  • Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2277
  • Before this update, the Dex pods failed to start with CreateContainerConfigError when an SCC of anyuid was assigned to the Dex ServiceAccount resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235

5.1.17. Release notes for Red Hat OpenShift GitOps 1.6.0

Red Hat OpenShift GitOps 1.6.0 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.17.1. New features

The current release adds the following improvements:

  • Previously, the Argo CD ApplicationSet controller was a technology preview (TP) feature. With this update, it is a general availability (GA) feature. GITOPS-1958
  • With this update, the latest releases of the Red Hat OpenShift GitOps are available in latest and version-based channels. To get these upgrades, update the channel parameter in the Subscription object YAML file: change its value from stable to latest or a version-based channel such as gitops-1.6. GITOPS-1791
  • With this update, the parameters of the spec.sso field that controlled the keycloak configurations are moved to .spec.sso.keycloak. The parameters of the .spec.dex field have been added to .spec.sso.dex. Start using .spec.sso.provider to enable or disable Dex. The .spec.dex parameters are deprecated and planned to be removed in version 1.9, along with the DISABLE_DEX and .spec.sso fields for keycloak configuration. GITOPS-1983
  • With this update, the Argo CD Notifications controller is available as an optional workload that can be enabled or disabled by using the .spec.notifications.enabled parameter in the Argo CD custom resource. The Argo CD Notifications controller is available as a Technical Preview feature. GITOPS-1917
Important

Argo CD Notifications controller is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

  • With this update, resource exclusions for Tekton pipeline runs and tasks runs are added by default. Argo CD, prunes these resources by default. These resource exclusions are added to the new Argo CD instances that are created from the OpenShift Container Platform. If the instances are created from the CLI, the resources are not added. GITOPS-1876
  • With this update, you can select the tracking method that by Argo CD uses by setting the resourceTrackingMethod parameter in the Operand’s specification. GITOPS-1862
  • With this update, you can add entries to the argocd-cm configMap using the extraConfig field of Red Hat OpenShift GitOps Argo CD custom resource. The entries specified are reconciled to the live config-cm configMap without validations. GITOPS-1964
  • With this update, on OpenShift Container Platform 4.11, the Red Hat OpenShift GitOps Environments page in the Developer perspective shows history of the successful deployments of the application environments, along with links to the revision for each deployment. GITOPS-1269
  • With this update, you can manage resources with Argo CD that are also being used as template resources or "source" by an Operator. GITOPS-982
  • With this update, the Operator will now configure the Argo CD workloads with the correct permissions to satisfy the Pod Security Admission that has been enabled for Kubernetes 1.24. GITOPS-2026
  • With this update, Config Management Plugins 2.0 is supported. You can use the Argo CD custom resource to specify sidebar containers for the repo server. GITOPS-776
  • With this update, all communication between the Argo CD components and the Redis cache are properly secured using modern TLS encryption. GITOPS-720
  • This release of Red Hat OpenShift GitOps adds support for IBM Z and IBM Power on OpenShift Container Platform 4.10. Currently, installations in restricted environments are not supported on IBM Z and IBM Power.

5.1.17.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, the system:serviceaccount:argocd:gitops-argocd-application-controller cannot create resource "prometheusrules" in API group monitoring.coreos.com in the namespace webapps-dev. This update fixes this issue and Red Hat OpenShift GitOps is now able to manage all resources from the monitoring.coreos.com API group. GITOPS-1638
  • Before this update, while reconciling cluster permissions, if a secret belonged to a cluster config instance it was deleted. This update fixes this issue. Now, the namespaces field from the secret is deleted instead of the secret. GITOPS-1777
  • Before this update, if you installed the HA variant of Argo CD through the Operator, the Operator created the Redis StatefulSet object with podAffinity rules instead of podAntiAffinity rules. This update fixes this issue and now the Operator creates the Redis StatefulSet with podAntiAffinity rules. GITOPS-1645
  • Before this update, Argo CD ApplicationSet had too many ssh Zombie processes. This update fixes this issue: it adds tini, a simple init daemon that spawns processes and reaps zombies, to the ApplicationSet controller. This ensures that a SIGTERM signal is properly passed to the running process, preventing it from being a zombie process. GITOPS-2108

5.1.17.3. Known issues

  • Red Hat OpenShift GitOps Operator can make use of RHSSO (KeyCloak) through OIDC in addition to Dex. However, with a recent security fix applied, the certificate of RHSSO cannot be validated in some scenarios. GITOPS-2214

    As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification.

spec:
  extraConfig:
    oidc.tls.insecure.skip.verify: "true"
...

5.1.18. Release notes for Red Hat OpenShift GitOps 1.5.9

Red Hat OpenShift GitOps 1.5.9 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.18.1. Fixed issues

  • Before this update, all versions of Argo CD v1.8.2 and later were vulnerable to an improper authorization bug. As a result, Argo CD would accept tokens for users who might not be authorized to access the cluster. This issue is now fixed. CVE-2023-22482

5.1.19. Release notes for Red Hat OpenShift GitOps 1.5.7

Red Hat OpenShift GitOps 1.5.7 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.19.1. Fixed issues

The following issues have been resolved in the current release:

  • From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2353

5.1.20. Release notes for Red Hat OpenShift GitOps 1.5.6

Red Hat OpenShift GitOps 1.5.6 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.20.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller StatefulSet object. GITOPS-2153
  • Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak’s TLS certificate when communicating with it. You can add the rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles this change and updates the oidc.config field in the argocd-cm ConfigMap with the PEM-encoded root certificate. GITOPS-2214

    Note

    Restart the Argo CD server pod after updating the .spec.keycloak.rootCA field.

    For example:

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: basic
    spec:
      sso:
        provider: keycloak
        keycloak:
         rootCA: |
           ---- BEGIN CERTIFICATE ----
           This is a dummy certificate
           Please place this section with appropriate rootCA
           ---- END CERTIFICATE ----
      server:
        route:
          enabled: true
  • Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2278
  • Before this update, the Dex pods failed to start with CreateContainerConfigError when an SCC of anyuid was assigned to the Dex ServiceAccount resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235

5.1.21. Release notes for Red Hat OpenShift GitOps 1.5.5

Red Hat OpenShift GitOps 1.5.5 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.21.1. New features

The current release adds the following improvements:

  • With this update, the bundled Argo CD has been updated to version 2.3.7.

5.1.21.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, the redis-ha-haproxy pods of an ArgoCD instance failed when more restrictive SCCs were present in the cluster. This update fixes the issue by updating the security context in workloads. GITOPS-2034

5.1.21.3. Known issues

  • Red Hat OpenShift GitOps Operator can use RHSSO (KeyCloak) with OIDC and Dex. However, with a recent security fix applied, the Operator cannot validate the RHSSO certificate in some scenarios. GITOPS-2214

    As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification.

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
    spec:
      extraConfig:
        "admin.enabled": "true"
    ...

5.1.22. Release notes for Red Hat OpenShift GitOps 1.5.4

Red Hat OpenShift GitOps 1.5.4 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.22.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, the Red Hat OpenShift GitOps was using an older version of the REDIS 5 image tag. This update fixes the issue and upgrades the rhel8/redis-5 image tag. GITOPS-2037

5.1.23. Release notes for Red Hat OpenShift GitOps 1.5.3

Red Hat OpenShift GitOps 1.5.3 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.23.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, all unpatched versions of Argo CD v1.0.0 and later were vulnerable to a cross-site scripting bug. As a result, an unauthorized user would be able to inject a javascript link in the UI. This issue is now fixed. CVE-2022-31035
  • Before this update, all versions of Argo CD v0.11.0 and later were vulnerable to multiple attacks when SSO login was initiated from the Argo CD CLI or the UI. This issue is now fixed. CVE-2022-31034
  • Before this update, all unpatched versions of Argo CD v0.7 and later were vulnerable to a memory consumption bug. As a result, an unauthorized user would be able to crash the Argo CD’s repo-server. This issue is now fixed. CVE-2022-31016
  • Before this update, all unpatched versions of Argo CD v1.3.0 and later were vulnerable to a symlink-following bug. As a result, an unauthorized user with repository write access would be able to leak sensitive YAML files from Argo CD’s repo-server. This issue is now fixed. CVE-2022-31036

5.1.24. Release notes for Red Hat OpenShift GitOps 1.5.2

Red Hat OpenShift GitOps 1.5.2 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.24.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, images referenced by the redhat-operator-index were missing. This issue is now fixed. GITOPS-2036

5.1.25. Release notes for Red Hat OpenShift GitOps 1.5.1

Red Hat OpenShift GitOps 1.5.1 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.25.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, if Argo CD’s anonymous access was enabled, an unauthenticated user was able to craft a JWT token and get full access to the Argo CD instance. This issue is fixed now. CVE-2022-29165
  • Before this update, an unauthenticated user was able to display error messages on the login screen while SSO was enabled. This issue is now fixed. CVE-2022-24905
  • Before this update, all unpatched versions of Argo CD v0.7.0 and later were vulnerable to a symlink-following bug. As a result, an unauthorized user with repository write access would be able to leak sensitive files from Argo CD’s repo-server. This issue is now fixed. CVE-2022-24904

5.1.26. Release notes for Red Hat OpenShift GitOps 1.5.0

Red Hat OpenShift GitOps 1.5.0 is now available on OpenShift Container Platform 4.8, 4.9, 4.10, and 4.11.

5.1.26.1. New features

The current release adds the following improvements:

  • This enhancement upgrades Argo CD to version 2.3.3. GITOPS-1708
  • This enhancement upgrades Dex to version 2.30.3. GITOPS-1850
  • This enhancement upgrades Helm to version 3.8.0. GITOPS-1709
  • This enhancement upgrades Kustomize to version 4.4.1. GITOPS-1710
  • This enhancement upgrades Application Set to version 0.4.1.
  • With this update, a new channel by the name latest has been added that provides the latest release of the Red Hat OpenShift GitOps. For GitOps v1.5.0, the Operator is pushed to gitops-1.5, latest channel, and the existing stable channel. From GitOps v1.6 all the latest releases will be pushed only to the latest channel and not the stable channel. GITOPS-1791
  • With this update, the new CSV adds the olm.skipRange: '>=1.0.0 <1.5.0' annotation. As a result, all the previous release versions will be skipped. The Operator upgrades to v1.5.0 directly. GITOPS-1787
  • With this update, the Operator updates the Red Hat Single Sign-On (RH-SSO) to version v7.5.1 including the following enhancements:

    • You can log in to Argo CD using the OpenShift credentials including the kube:admin credential.
    • The RH-SSO supports and configures Argo CD instances for Role-based Access Control (RBAC) using OpenShift groups.
    • The RH-SSO honors the HTTP_Proxy environment variables. You can use the RH-SSO as an SSO for Argo CD running behind a proxy.

      GITOPS-1330

  • With this update, a new .host URL field is added to the .status field of the Argo CD operand. When a route or ingress is enabled with the priority given to route, then the new URL field displays the route. If no URL is provided from the route or ingress, the .host field is not displayed.

    When the route or ingress is configured, but the corresponding controller is not set up properly and is not in the Ready state or does not propagate its URL, the value of the .status.host field in the operand indicates as Pending instead of displaying the URL. This affects the overall status of the operand by making it Pending instead of Available. GITOPS-654

5.1.26.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, RBAC rules specific to AppProjects would not allow the use of commas for the subject field of the role, thus preventing bindings to the LDAP account. This update fixes the issue and you can now specify complex role bindings in AppProject specific RBAC rules. GITOPS-1771
  • Before this update, when a DeploymentConfig resource is scaled to 0, Argo CD displayed it in a progressing state with a health status message as "replication controller is waiting for pods to run". This update fixes the edge case and the health check now reports the correct health status of the DeploymentConfig resource. GITOPS-1738
  • Before this update, the TLS certificate in the argocd-tls-certs-cm configuration map was deleted by the Red Hat OpenShift GitOps unless the certificate was configured in the ArgoCD CR specification tls.initialCerts field. This issue is fixed now. GITOPS-1725
  • Before this update, while creating a namespace with the managed-by label it created a lot of RoleBinding resources on the new namespace. This update fixes the issue and now Red Hat OpenShift GitOps removes the irrelevant Role and RoleBinding resources created by the previous versions. GITOPS-1550
  • Before this update, the TLS certificate of the route in pass-through mode did not have a CA name. As a result, Firefox 94 and later failed to connect to Argo CD UI with error code SEC_ERROR_BAD_DER. This update fixes the issue. You must delete the <openshift-gitops-ca> secrets and let it recreate. Then, you must delete the <openshift-gitops-tls> secrets. After the Red Hat OpenShift GitOps recreates it, the Argo CD UI is accessible by Firefox again. GITOPS-1548

5.1.26.3. Known issues

  • Argo CD .status.host field is not updated when an Ingress resource is in use instead of a Route resource on OpenShift clusters. GITOPS-1920

5.1.27. Release notes for Red Hat OpenShift GitOps 1.4.13

Red Hat OpenShift GitOps 1.4.13 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.27.1. Fixed issues

The following issues have been resolved in the current release:

  • From OpenShift Container Platform 4.12, it is optional to install the console. This fix updates the Red Hat OpenShift GitOps Operator to prevent errors with the Operator if the console is not installed. GITOPS-2354

5.1.28. Release notes for Red Hat OpenShift GitOps 1.4.12

Red Hat OpenShift GitOps 1.4.12 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.28.1. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, in a large set of applications the application controllers were restarted multiple times due to the unresponsiveness of liveness probes. This update fixes the issue by removing the liveness probe in the application controller StatefulSet object. GITOPS-2153
  • Before this update, the RHSSO certificate cannot be validated when it is set up with a certificate which is not signed by certificate authorities. This update fixes the issue and now you can provide a custom certificate which will be used in verifying the Keycloak’s TLS certificate when communicating with it. You can add the rootCA to the Argo CD custom resource .spec.keycloak.rootCA field. The Operator reconciles this change and updates the oidc.config field in the argocd-cm ConfigMap with the PEM-encoded root certificate. GITOPS-2214

    Note

    Restart the Argo CD server pod after updating the .spec.keycloak.rootCA field.

    For example:

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: basic
    spec:
      sso:
        provider: keycloak
        keycloak:
         rootCA: |
           ---- BEGIN CERTIFICATE ----
           This is a dummy certificate
           Please place this section with appropriate rootCA
           ---- END CERTIFICATE ----
      server:
        route:
          enabled: true
  • Before this update, a terminating namespace that was managed by Argo CD would block the creation of roles and other configuration of other managed namespaces. This update fixes this issue. GITOPS-2276
  • Before this update, the Dex pods failed to start with CreateContainerConfigError when an SCC of anyuid was assigned to the Dex ServiceAccount resource. This update fixes this issue by assigning a default user id to the Dex container. GITOPS-2235

5.1.29. Release notes for Red Hat OpenShift GitOps 1.4.11

Red Hat OpenShift GitOps 1.4.11 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.29.1. New features

The current release adds the following improvements:

  • With this update, the bundled Argo CD has been updated to version 2.2.12.

5.1.29.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, the redis-ha-haproxy pods of an ArgoCD instance failed when more restrictive SCCs were present in the cluster. This update fixes the issue by updating the security context in workloads. GITOPS-2034

5.1.29.3. Known issues

  • Red Hat OpenShift GitOps Operator can use RHSSO (KeyCloak) with OIDC and Dex. However, with a recent security fix applied, the Operator cannot validate the RHSSO certificate in some scenarios. GITOPS-2214

    As a workaround, disable TLS validation for the OIDC (Keycloak/RHSSO) endpoint in the ArgoCD specification.

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
    spec:
      extraConfig:
        "admin.enabled": "true"
    ...

5.1.30. Release notes for Red Hat OpenShift GitOps 1.4.6

Red Hat OpenShift GitOps 1.4.6 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.30.1. Fixed issues

The following issue has been resolved in the current release:

  • The base images are updated to the latest version to avoid OpenSSL flaw link: (CVE-2022-0778).
Note

To install the current release of Red Hat OpenShift GitOps 1.4 and receive further updates during its product life cycle, switch to the GitOps-1.4 channel.

5.1.31. Release notes for Red Hat OpenShift GitOps 1.4.5

Red Hat OpenShift GitOps 1.4.5 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.31.1. Fixed issues

Warning

You should directly upgrade to Red Hat OpenShift GitOps v1.4.5 from Red Hat OpenShift GitOps v1.4.3. Do not use Red Hat OpenShift GitOps v1.4.4 in a production environment. Major issues that affected Red Hat OpenShift GitOps v1.4.4 are fixed in Red Hat OpenShift GitOps 1.4.5.

The following issue has been resolved in the current release:

  • Before this update, Argo CD pods were stuck in the ErrImagePullBackOff state. The following error message was shown:
reason: ErrImagePull
          message: >-
            rpc error: code = Unknown desc = reading manifest
            sha256:ff4ad30752cf0d321cd6c2c6fd4490b716607ea2960558347440f2f370a586a8
            in registry.redhat.io/openshift-gitops-1/argocd-rhel8: StatusCode:
            404, <HTML><HEAD><TITLE>Error</TITLE></HEAD><BODY>

This issue is now fixed. GITOPS-1848

5.1.32. Release notes for Red Hat OpenShift GitOps 1.4.3

Red Hat OpenShift GitOps 1.4.3 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.32.1. Fixed issues

The following issue has been resolved in the current release:

  • Before this update, the TLS certificate in the argocd-tls-certs-cm configuration map was deleted by the Red Hat OpenShift GitOps unless the certificate was configured in the ArgoCD CR specification tls.initialCerts field. This update fixes this issue. GITOPS-1725

5.1.33. Release notes for Red Hat OpenShift GitOps 1.4.2

Red Hat OpenShift GitOps 1.4.2 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.33.1. Fixed issues

The following issue has been resolved in the current release:

  • Before this update, the Route resources got stuck in Progressing Health status if more than one Ingress were attached to the route. This update fixes the health check and reports the correct health status of the Route resources. GITOPS-1751

5.1.34. Release notes for Red Hat OpenShift GitOps 1.4.1

Red Hat OpenShift GitOps 1.4.1 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.34.1. Fixed issues

The following issue has been resolved in the current release:

  • Red Hat OpenShift GitOps Operator v1.4.0 introduced a regression which removes the description fields from spec for the following CRDs:

    • argoproj.io_applications.yaml
    • argoproj.io_appprojects.yaml
    • argoproj.io_argocds.yaml

      Before this update, when you created an AppProject resource using the oc create command, the resource failed to synchronize due to the missing description fields. This update restores the missing description fields in the preceding CRDs. GITOPS-1721

5.1.35. Release notes for Red Hat OpenShift GitOps 1.4.0

Red Hat OpenShift GitOps 1.4.0 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.10.

5.1.35.1. New features

The current release adds the following improvements.

  • This enhancement upgrades the Red Hat OpenShift GitOps Application Manager CLI (kam) to version 0.0.41. GITOPS-1669
  • This enhancement upgrades Argo CD to version 2.2.2. GITOPS-1532
  • This enhancement upgrades Helm to version 3.7.1. GITOPS-1530
  • This enhancement adds the health status of the DeploymentConfig, Route, and OLM Operator items to the Argo CD Dashboard and OpenShift Container Platform web console. This information helps you monitor the overall health status of your application. GITOPS-655, GITOPS-915, GITOPS-916, GITOPS-1110
  • With this update, you can to specify the number of desired replicas for the argocd-server and argocd-repo-server components by setting the .spec.server.replicas and .spec.repo.replicas attributes in the Argo CD custom resource, respectively. If you configure the horizontal pod autoscaler (HPA) for the argocd-server components, it takes precedence over the Argo CD custom resource attributes. GITOPS-1245
  • As an administrative user, when you give Argo CD access to a namespace by using the argocd.argoproj.io/managed-by label, it assumes namespace-admin privileges. These privileges are an issue for administrators who provide namespaces to non-administrators, such as development teams, because the privileges enable non-administrators to modify objects such as network policies.

    With this update, administrators can configure a common cluster role for all the managed namespaces. In role bindings for the Argo CD application controller, the Operator refers to the CONTROLLER_CLUSTER_ROLE environment variable. In role bindings for the Argo CD server, the Operator refers to the SERVER_CLUSTER_ROLE environment variable. If these environment variables contain custom roles, the Operator doesn’t create the default admin role. Instead, it uses the existing custom role for all managed namespaces. GITOPS-1290

  • With this update, the Environments page in the OpenShift Container Platform Developer perspective displays a broken heart icon to indicate degraded resources, excluding ones whose status is Progressing, Missing, and Unknown. The console displays a yellow yield sign icon to indicate out-of-sync resources. GITOPS-1307

5.1.35.2. Fixed issues

The following issues have been resolved in the current release:

  • Before this update, when the Route to the Red Hat OpenShift GitOps Application Manager CLI (kam) was accessed without specifying a path in the URL, a default page without any helpful information was displayed to the user. This update fixes the issue so that the default page displays download links for the kam CLI. GITOPS-923
  • Before this update, setting a resource quota in the namespace of the Argo CD custom resource might cause the setup of the Red Hat SSO (RH SSO) instance to fail. This update fixes this issue by setting a minimum resource request for the RH SSO deployment pods. GITOPS-1297
  • Before this update, if you changed the log level for the argocd-repo-server workload, the Operator didn’t reconcile this setting. The workaround was to delete the deployment resource so that the Operator recreated it with the new log level. With this update, the log level is correctly reconciled for existing argocd-repo-server workloads. GITOPS-1387
  • Before this update, if the Operator managed an Argo CD instance that lacked the .data field in the argocd-secret Secret, the Operator on that instance crashed. This update fixes the issue so that the Operator doesn’t crash when the .data field is missing. Instead, the secret regenerates and the gitops-operator-controller-manager resource is redeployed. GITOPS-1402
  • Before this update, the gitopsservice service was annotated as an internal object. This update removes the annotation so you can update or delete the default Argo CD instance and run GitOps workloads on infrastructure nodes by using the UI. GITOPS-1429

5.1.35.3. Known issues

These are the known issues in the current release:

  • If you migrate from the Dex authentication provider to the Keycloak provider, you might experience login issues with Keycloak.

    To prevent this issue, when migrating, uninstall Dex by removing the .spec.dex section from the Argo CD custom resource. Allow a few minutes for Dex to uninstall completely. Then, install Keycloak by adding .spec.sso.provider: keycloak to the Argo CD custom resource.

    As a workaround, uninstall Keycloak by removing .spec.sso.provider: keycloak. Then, re-install it. GITOPS-1450, GITOPS-1331

5.1.36. Release notes for Red Hat OpenShift GitOps 1.3.7

Red Hat OpenShift GitOps 1.3.7 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.

5.1.36.1. Fixed issues

The following issue has been resolved in the current release:

  • Before this update, a flaw was found in OpenSSL. This update fixes the issue by updating the base images to the latest version to avoid the OpenSSL flaw. (CVE-2022-0778).
Note

To install the current release of Red Hat OpenShift GitOps 1.3 and receive further updates during its product life cycle, switch to the GitOps-1.3 channel.

5.1.37. Release notes for Red Hat OpenShift GitOps 1.3.6

Red Hat OpenShift GitOps 1.3.6 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.

5.1.37.1. Fixed issues

The following issues have been resolved in the current release:

  • In Red Hat OpenShift GitOps, improper access control allows admin privilege escalation (CVE-2022-1025). This update fixes the issue.
  • A path traversal flaw allows leaking of out-of-bound files (CVE-2022-24731). This update fixes the issue.
  • A path traversal flaw and improper access control allows leaking of out-of-bound files (CVE-2022-24730). This update fixes the issue.

5.1.38. Release notes for Red Hat OpenShift GitOps 1.3.2

Red Hat OpenShift GitOps 1.3.2 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.

5.1.38.1. New features

In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.3.2:

  • Upgraded Argo CD to version 2.1.8
  • Upgraded Dex to version 2.30.0

5.1.38.2. Fixed issues

The following issues have been resolved in the current release:

  • Previously, in the OperatorHub UI under the Infrastructure Features section, when you filtered by Disconnected the Red Hat OpenShift GitOps Operator did not show in the search results, as the Operator did not have the related annotation set in its CSV file. With this update, the Disconnected Cluster annotation has been added to the Red Hat OpenShift GitOps Operator as an infrastructure feature. GITOPS-1539
  • When using an Namespace-scoped Argo CD instance, for example, an Argo CD instance that is not scoped to All Namepsaces in a cluster, Red Hat OpenShift GitOps dynamically maintains a list of managed namespaces. These namespaces include the argocd.argoproj.io/managed-by label. This list of namespaces is stored in a cache in Argo CD Settings Clusters "in-cluster" NAMESPACES. Before this update, if you deleted one of these namespaces, the Operator ignored that, and the namespace remained in the list. This behavior broke the CONNECTION STATE in that cluster configuration, and all sync attempts resulted in errors. For example:

    Argo service account does not have <random_verb> on <random_resource_type> in namespace <the_namespace_you_deleted>.

    This bug is fixed. GITOPS-1521

  • With this update, the Red Hat OpenShift GitOps Operator has been annotated with the Deep Insights capability level. GITOPS-1519
  • Previously, the Argo CD Operator managed the resource.exclusion field by itself but ignored the resource.inclusion field. This prevented the resource.inclusion field configured in the Argo CD CR to generate in the argocd-cm configuration map. This bug is fixed. GITOPS-1518

5.1.39. Release notes for Red Hat OpenShift GitOps 1.3.1

Red Hat OpenShift GitOps 1.3.1 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.

5.1.39.1. Fixed issues

  • If you upgrade to v1.3.0, the Operator does not return an ordered slice of environment variables. As a result, the reconciler fails causing the frequent recreation of Argo CD pods in OpenShift Container Platform clusters running behind a proxy. This update fixes the issue so that Argo CD pods are not recreated. GITOPS-1489

5.1.40. Release notes for Red Hat OpenShift GitOps 1.3

Red Hat OpenShift GitOps 1.3 is now available on OpenShift Container Platform 4.7, 4.8, 4.9, and 4.6 with limited GA support.

5.1.40.1. New features

In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.3.0:

  • For a fresh install of v1.3.0, Dex is automatically configured. You can log into the default Argo CD instance in the openshift-gitops namespace using the OpenShift or kubeadmin credentials. As an admin you can disable the Dex installation after the Operator is installed which will remove the Dex deployment from the openshift-gitops namespace.
  • The default Argo CD instance installed by the Operator as well as accompanying controllers can now run on the infrastructure nodes of the cluster by setting a simple configuration toggle.
  • Internal communications in Argo CD can now be secured using the TLS and the OpenShift cluster certificates. The Argo CD routes can now leverage the OpenShift cluster certificates in addition to using external certificate managers such as the cert-manager.
  • Use the improved Environments page in the Developer perspective of the console 4.9 to gain insights into the GitOps environments.
  • You can now access custom health checks in Argo CD for DeploymentConfig resources, Route resources, and Operators installed using OLM.
  • The GitOps Operator now conforms to the naming conventions recommended by the latest Operator-SDK:

    • The prefix gitops-operator- is added to all resources
    • Service account is renamed to gitops-operator-controller-manager

5.1.40.2. Fixed issues

The following issues were resolved in the current release:

  • Previously, if you set up a new namespace to be managed by a new instance of Argo CD, it would immediately be Out Of Sync due to the new roles and bindings that the Operator creates to manage that new namespace. This behavior is fixed. GITOPS-1384

5.1.40.3. Known issues

  • While migrating from the Dex authentication provider to the Keycloak provider, you may experience login issues with Keycloak. GITOPS-1450

    To prevent the above issue, when migrating, uninstall Dex by removing the .spec.dex section found in the Argo CD custom resource. Allow a few minutes for Dex to uninstall completely, and then proceed to install Keycloak by adding .spec.sso.provider: keycloak to the Argo CD custom resource.

    As a workaround, uninstall Keycloak by removing .spec.sso.provider: keycloak and then re-install.

5.1.41. Release notes for Red Hat OpenShift GitOps 1.2.2

Red Hat OpenShift GitOps 1.2.2 is now available on OpenShift Container Platform 4.8.

5.1.41.1. Fixed issues

The following issue was resolved in the current release:

  • All versions of Argo CD are vulnerable to a path traversal bug that allows to pass arbitrary values to be consumed by Helm charts. This update fixes the CVE-2022-24348 gitops error, path traversal and dereference of symlinks when passing Helm value files. GITOPS-1756

5.1.42. Release notes for Red Hat OpenShift GitOps 1.2.1

Red Hat OpenShift GitOps 1.2.1 is now available on OpenShift Container Platform 4.8.

5.1.42.1. Support matrix

Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.

Technology Preview Features Support Scope

In the table below, features are marked with the following statuses:

  • TP: Technology Preview
  • GA: General Availability

Note the following scope of support on the Red Hat Customer Portal for these features:

Table 5.2. Support matrix
FeatureRed Hat OpenShift GitOps 1.2.1

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager CLI (kam)

TP

5.1.42.2. Fixed issues

The following issues were resolved in the current release:

  • Previously, huge memory spikes were observed on the application controller on startup. The flag --kubectl-parallelism-limit for the application controller is now set to 10 by default, however this value can be overridden by specifying a number for .spec.controller.kubeParallelismLimit in the Argo CD CR specification. GITOPS-1255
  • The latest Triggers APIs caused Kubernetes build failure due to duplicate entries in the kustomization.yaml when using the kam bootstrap command. The Pipelines and Tekton triggers components have now been updated to v0.24.2 and v0.14.2, respectively, to address this issue. GITOPS-1273
  • Persisting RBAC roles and bindings are now automatically removed from the target namespace when the Argo CD instance from the source namespace is deleted. GITOPS-1228
  • Previously, when deploying an Argo CD instance into a namespace, the Argo CD instance would change the "managed-by" label to be its own namespace. This fix would make namespaces unlabelled while also making sure the required RBAC roles and bindings are created and deleted for the namespace. GITOPS-1247
  • Previously, the default resource request limits on Argo CD workloads, specifically for the repo-server and application controller, were found to be very restrictive. The existing resource quota has now been removed and the default memory limit has been increased to 1024M in the repo server. Please note that this change will only affect new installations; existing Argo CD instance workloads will not be affected. GITOPS-1274

5.1.43. Release notes for Red Hat OpenShift GitOps 1.2

Red Hat OpenShift GitOps 1.2 is now available on OpenShift Container Platform 4.8.

5.1.43.1. Support matrix

Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.

Technology Preview Features Support Scope

In the table below, features are marked with the following statuses:

  • TP: Technology Preview
  • GA: General Availability

Note the following scope of support on the Red Hat Customer Portal for these features:

Table 5.3. Support matrix
FeatureRed Hat OpenShift GitOps 1.2

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager CLI (kam)

TP

5.1.43.2. New features

In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.2:

  • If you do not have read or write access to the openshift-gitops namespace, you can now use the DISABLE_DEFAULT_ARGOCD_INSTANCE environment variable in the GitOps Operator and set the value to TRUE to prevent the default Argo CD instance from starting in the openshift-gitops namespace.
  • Resource requests and limits are now configured in Argo CD workloads. Resource quota is enabled in the openshift-gitops namespace. As a result, out-of-band workloads deployed manually in the openshift-gitops namespace must be configured with resource requests and limits and the resource quota may need to be increased.
  • Argo CD authentication is now integrated with Red Hat SSO and it is automatically configured with OpenShift 4 Identity Provider on the cluster. This feature is disabled by default. To enable Red Hat SSO, add SSO configuration in ArgoCD CR as shown below. Currently,keycloak is the only supported provider.

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: basic
    spec:
      sso:
        provider: keycloak
      server:
        route:
         enabled: true
  • You can now define hostnames using route labels to support router sharding. Support for setting labels on the server (argocd server), grafana, and prometheus routes is now available. To set labels on a route, add labels under the route configuration for a server in the ArgoCD CR.

    Example ArgoCD CR YAML to set labels on argocd server

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: basic
    spec:
      server:
        route:
         enabled: true
         labels:
           key1: value1
           key2: value2

  • The GitOps Operator now automatically grants permissions to Argo CD instances to manage resources in target namespaces by applying labels. Users can label the target namespace with the label argocd.argoproj.io/managed-by: <source-namespace>, where the source-namespace is the namespace where the argocd instance is deployed.

5.1.43.3. Fixed issues

The following issues were resolved in the current release:

  • Previously, if a user created additional instances of Argo CD managed by the default cluster instance in the openshift-gitops namespace, the application responsible for the new Argo CD instance would get stuck in an OutOfSync status. This issue has now been resolved by adding an owner reference to the cluster secret. GITOPS-1025

5.1.43.4. Known issues

These are the known issues in Red Hat OpenShift GitOps 1.2:

  • When an Argo CD instance is deleted from the source namespace, the argocd.argoproj.io/managed-by labels in the target namespaces are not removed. GITOPS-1228
  • Resource quota has been enabled in the openshift-gitops namespace in Red Hat OpenShift GitOps 1.2. This can affect out-of-band workloads deployed manually and workloads deployed by the default Argo CD instance in the openshift-gitops namespace. When you upgrade from Red Hat OpenShift GitOps v1.1.2 to v1.2 such workloads must be configured with resource requests and limits. If there are any additional workloads, the resource quota in the openshift-gitops namespace must be increased.

    Current Resource Quota for openshift-gitops namespace.

    ResourceRequestsLimits

    CPU

    6688m

    13750m

    Memory

    4544Mi

    9070Mi

    You can use the below command to update the CPU limits.

    $ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/limits.cpu", "value":"9000m"}]'

    You can use the below command to update the CPU requests.

    $ oc patch resourcequota openshift-gitops-compute-resources -n openshift-gitops --type='json' -p='[{"op": "replace", "path": "/spec/hard/cpu", "value":"7000m"}]

    You can replace the path in the above commands from cpu to memory to update the memory.

5.1.44. Release notes for Red Hat OpenShift GitOps 1.1

Red Hat OpenShift GitOps 1.1 is now available on OpenShift Container Platform 4.7.

5.1.44.1. Support matrix

Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.

Technology Preview Features Support Scope

In the table below, features are marked with the following statuses:

  • TP: Technology Preview
  • GA: General Availability

Note the following scope of support on the Red Hat Customer Portal for these features:

Table 5.4. Support matrix
FeatureRed Hat OpenShift GitOps 1.1

Argo CD

GA

Argo CD ApplicationSet

TP

Red Hat OpenShift GitOps Application Manager CLI (kam)

TP

5.1.44.2. New features

In addition to the fixes and stability improvements, the following sections highlight what is new in Red Hat OpenShift GitOps 1.1:

  • The ApplicationSet feature is now added (Technology Preview). The ApplicationSet feature enables both automation and greater flexibility when managing Argo CD applications across a large number of clusters and within monorepos. It also makes self-service usage possible on multitenant Kubernetes clusters.
  • Argo CD is now integrated with cluster logging stack and with the OpenShift Container Platform Monitoring and Alerting features.
  • Argo CD auth is now integrated with OpenShift Container Platform.
  • Argo CD applications controller now supports horizontal scaling.
  • Argo CD Redis servers now support high availability (HA).

5.1.44.3. Fixed issues

The following issues were resolved in the current release:

  • Previously, Red Hat OpenShift GitOps did not work as expected in a proxy server setup with active global proxy settings. This issue is fixed and now Argo CD is configured by the Red Hat OpenShift GitOps Operator using fully qualified domain names (FQDN) for the pods to enable communication between components. GITOPS-703
  • The Red Hat OpenShift GitOps backend relies on the ?ref= query parameter in the Red Hat OpenShift GitOps URL to make API calls. Previously, this parameter was not read from the URL, causing the backend to always consider the default reference. This issue is fixed and the Red Hat OpenShift GitOps backend now extracts the reference query parameter from the Red Hat OpenShift GitOps URL and only uses the default reference when there is no input reference provided. GITOPS-817
  • Previously, the Red Hat OpenShift GitOps backend failed to find the valid GitLab repository. This was because the Red Hat OpenShift GitOps backend checked for main as the branch reference, instead of master in the GitLab repository. This issue is fixed now. GITOPS-768
  • The Environments page in the Developer perspective of the OpenShift Container Platform web console now shows the list of applications and the number of environments. This page also displays an Argo CD link that directs you to the Argo CD Applications page that lists all the applications. The Argo CD Applications page has LABELS (for example, app.kubernetes.io/name=appName) that help you filter only the applications of your choice. GITOPS-544

5.1.44.4. Known issues

These are the known issues in Red Hat OpenShift GitOps 1.1:

  • Red Hat OpenShift GitOps does not support Helm v2 and ksonnet.
  • The Red Hat SSO (RH SSO) Operator is not supported in disconnected clusters. As a result, the Red Hat OpenShift GitOps Operator and RH SSO integration is not supported in disconnected clusters.
  • When you delete an Argo CD application from the OpenShift Container Platform web console, the Argo CD application gets deleted in the user interface, but the deployments are still present in the cluster. As a workaround, delete the Argo CD application from the Argo CD console. GITOPS-830

5.1.44.5. Breaking Change

5.1.44.5.1. Upgrading from Red Hat OpenShift GitOps v1.0.1

When you upgrade from Red Hat OpenShift GitOps v1.0.1 to v1.1, the Red Hat OpenShift GitOps Operator renames the default Argo CD instance created in the openshift-gitops namespace from argocd-cluster to openshift-gitops.

This is a breaking change and needs the following steps to be performed manually, before the upgrade:

  1. Go to the OpenShift Container Platform web console and copy the content of the argocd-cm.yml config map file in the openshift-gitops namespace to a local file. The content may look like the following example:

    Example argocd config map YAML

    kind: ConfigMap
    apiVersion: v1
    metadata:
    selfLink: /api/v1/namespaces/openshift-gitops/configmaps/argocd-cm
    resourceVersion: '112532'
    name: argocd-cm
    uid: f5226fbc-883d-47db-8b53-b5e363f007af
    creationTimestamp: '2021-04-16T19:24:08Z'
    managedFields:
    ...
    namespace: openshift-gitops
    labels:
      app.kubernetes.io/managed-by: argocd-cluster
      app.kubernetes.io/name: argocd-cm
      app.kubernetes.io/part-of: argocd
    data: "" 1
    admin.enabled: 'true'
    statusbadge.enabled: 'false'
    resource.exclusions: |
      - apiGroups:
        - tekton.dev
        clusters:
        - '*'
        kinds:
        - TaskRun
        - PipelineRun
    ga.trackingid: ''
    repositories: |
      - type: git
        url: https://github.com/user-name/argocd-example-apps
    ga.anonymizeusers: 'false'
    help.chatUrl: ''
    url: >-
      https://argocd-cluster-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com   "" 2
    help.chatText: ''
    kustomize.buildOptions: ''
    resource.inclusions: ''
    repository.credentials: ''
    users.anonymous.enabled: 'false'
    configManagementPlugins: ''
    application.instanceLabelKey: ''

    1
    Restore only the data section of the content in the argocd-cm.yml config map file manually.
    2
    Replace the URL value in the config map entry with the new instance name openshift-gitops.
  2. Delete the default argocd-cluster instance.
  3. Edit the new argocd-cm.yml config map file to restore the entire data section manually.
  4. Replace the URL value in the config map entry with the new instance name openshift-gitops. For example, in the preceding example, replace the URL value with the following URL value:

    url: >-
      https://openshift-gitops-server-openshift-gitops.apps.dev-svc-4.7-041614.devcluster.openshift.com
  5. Login to the Argo CD cluster and verify that the previous configurations are present.

5.2. Understanding OpenShift GitOps

5.2.1. About GitOps

GitOps is a declarative way to implement continuous deployment for cloud native applications. You can use GitOps to create repeatable processes for managing OpenShift Container Platform clusters and applications across multi-cluster Kubernetes environments. GitOps handles and automates complex deployments at a fast pace, saving time during deployment and release cycles.

The GitOps workflow pushes an application through development, testing, staging, and production. GitOps either deploys a new application or updates an existing one, so you only need to update the repository; GitOps automates everything else.

GitOps is a set of practices that use Git pull requests to manage infrastructure and application configurations. In GitOps, the Git repository is the only source of truth for system and application configuration. This Git repository contains a declarative description of the infrastructure you need in your specified environment and contains an automated process to make your environment match the described state. Also, it contains the entire state of the system so that the trail of changes to the system state are visible and auditable. By using GitOps, you resolve the issues of infrastructure and application configuration sprawl.

GitOps defines infrastructure and application definitions as code. Then, it uses this code to manage multiple workspaces and clusters to simplify the creation of infrastructure and application configurations. By following the principles of the code, you can store the configuration of clusters and applications in Git repositories, and then follow the Git workflow to apply these repositories to your chosen clusters. You can apply the core principles of developing and maintaining software in a Git repository to the creation and management of your cluster and application configuration files.

5.2.2. About Red Hat OpenShift GitOps

Red Hat OpenShift GitOps ensures consistency in applications when you deploy them to different clusters in different environments, such as: development, staging, and production. Red Hat OpenShift GitOps organizes the deployment process around the configuration repositories and makes them the central element. It always has at least two repositories:

  1. Application repository with the source code
  2. Environment configuration repository that defines the desired state of the application

These repositories contain a declarative description of the infrastructure you need in your specified environment. They also contain an automated process to make your environment match the described state.

Red Hat OpenShift GitOps uses Argo CD to maintain cluster resources. Argo CD is an open-source declarative tool for the continuous integration and continuous deployment (CI/CD) of applications. Red Hat OpenShift GitOps implements Argo CD as a controller so that it continuously monitors application definitions and configurations defined in a Git repository. Then, Argo CD compares the specified state of these configurations with their live state on the cluster.

Argo CD reports any configurations that deviate from their specified state. These reports allow administrators to automatically or manually resync configurations to the defined state. Therefore, Argo CD enables you to deliver global custom resources, like the resources that are used to configure OpenShift Container Platform clusters.

5.2.2.1. Key features

Red Hat OpenShift GitOps helps you automate the following tasks:

  • Ensure that the clusters have similar states for configuration, monitoring, and storage
  • Apply or revert configuration changes to multiple OpenShift Container Platform clusters
  • Associate templated configuration with different environments
  • Promote applications across clusters, from staging to production

5.3. Installing Red Hat OpenShift GitOps

Red Hat OpenShift GitOps uses Argo CD to manage specific cluster-scoped resources, including cluster Operators, optional Operator Lifecycle Manager (OLM) Operators, and user management.

This guide explains how to install the Red Hat OpenShift GitOps Operator to an OpenShift Container Platform cluster and log in to the Argo CD instance.

Important

The latest channel enables installation of the most recent stable version of the Red Hat OpenShift GitOps Operator. Currently, it is the default channel for installing the Red Hat OpenShift GitOps Operator.

To install a specific version of the Red Hat OpenShift GitOps Operator, cluster administrators can use the corresponding gitops-<version> channel. For example, to install the Red Hat OpenShift GitOps Operator version 1.8.x, you can use the gitops-1.8 channel.

5.3.1. Installing Red Hat OpenShift GitOps Operator in web console

Prerequisites

  • Access to the OpenShift Container Platform web console.
  • An account with the cluster-admin role.
  • You are logged in to the OpenShift Container Platform cluster as an administrator.
Warning

If you have already installed the Community version of the Argo CD Operator, remove the Argo CD Community Operator before you install the Red Hat OpenShift GitOps Operator.

Procedure

  1. Open the Administrator perspective of the web console and navigate to Operators OperatorHub in the menu on the left.
  2. Search for OpenShift GitOps, click the Red Hat OpenShift GitOps tile, and then click Install.

    Red Hat OpenShift GitOps will be installed in all namespaces of the cluster.

After the Red Hat OpenShift GitOps Operator is installed, it automatically sets up a ready-to-use Argo CD instance that is available in the openshift-gitops namespace, and an Argo CD icon is displayed in the console toolbar. You can create subsequent Argo CD instances for your applications under your projects.

5.3.2. Installing Red Hat OpenShift GitOps Operator using CLI

You can install Red Hat OpenShift GitOps Operator from the OperatorHub using the CLI.

Procedure

  1. Create a Subscription object YAML file to subscribe a namespace to the Red Hat OpenShift GitOps, for example, sub.yaml:

    Example Subscription

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-gitops-operator
      namespace: openshift-operators
    spec:
      channel: latest 1
      installPlanApproval: Automatic
      name: openshift-gitops-operator 2
      source: redhat-operators 3
      sourceNamespace: openshift-marketplace 4

    1
    Specify the channel name from where you want to subscribe the Operator.
    2
    Specify the name of the Operator to subscribe to.
    3
    Specify the name of the CatalogSource that provides the Operator.
    4
    The namespace of the CatalogSource. Use openshift-marketplace for the default OperatorHub CatalogSources.
  2. Apply the Subscription to the cluster:

    $ oc apply -f openshift-gitops-sub.yaml
  3. After the installation is complete, ensure that all the pods in the openshift-gitops namespace are running:

    $ oc get pods -n openshift-gitops

    Example output

    NAME                                                      	READY   STATUS	RESTARTS   AGE
    cluster-b5798d6f9-zr576                                   	1/1 	Running   0      	65m
    kam-69866d7c48-8nsjv                                      	1/1 	Running   0      	65m
    openshift-gitops-application-controller-0                 	1/1 	Running   0      	53m
    openshift-gitops-applicationset-controller-6447b8dfdd-5ckgh 1/1 	Running   0      	65m
    openshift-gitops-redis-74bd8d7d96-49bjf                   	1/1 	Running   0      	65m
    openshift-gitops-repo-server-c999f75d5-l4rsg              	1/1 	Running   0      	65m
    openshift-gitops-server-5785f7668b-wj57t                  	1/1 	Running   0      	53m

5.3.3. Logging in to the Argo CD instance by using the Argo CD admin account

Red Hat OpenShift GitOps Operator automatically creates a ready-to-use Argo CD instance that is available in the openshift-gitops namespace.

Prerequisites

  • You have installed the Red Hat OpenShift GitOps Operator in your cluster.

Procedure

  1. In the Administrator perspective of the web console, navigate to Operators Installed Operators to verify that the Red Hat OpenShift GitOps Operator is installed.
  2. Navigate to the red hat applications menu icon menu OpenShift GitOps Cluster Argo CD. The login page of the Argo CD UI is displayed in a new window.
  3. Optional: To log in with your OpenShift Container Platform credentials, ensure you are a user of the cluster-admins group and then select the LOG IN VIA OPENSHIFT option in the Argo CD user interface.

    Note

    To be a user of the cluster-admins group, use the oc adm groups new cluster-admins <user> command, where <user> is the default cluster role that you can bind to users and groups cluster-wide or locally.

  4. To log in with your username and password, obtain the password for the Argo CD instance:

    1. In the left panel of the console, use the perspective switcher to switch to the Developer perspective.
    2. Use the Project drop-down list and select the openshift-gitops project.
    3. Use the left navigation panel to navigate to the Secrets page.
    4. Select the openshift-gitops-cluster instance to display the password.
    5. Copy the password.
  5. Use this password and admin as the username to log in to the Argo CD UI in the new window.
Note

You cannot create two Argo CD CRs in the same namespace.

5.4. Uninstalling OpenShift GitOps

Uninstalling the Red Hat OpenShift GitOps Operator is a two-step process:

  1. Delete the Argo CD instances that were added under the default namespace of the Red Hat OpenShift GitOps Operator.
  2. Uninstall the Red Hat OpenShift GitOps Operator.

Uninstalling only the Operator will not remove the Argo CD instances created.

5.4.1. Deleting the Argo CD instances

Delete the Argo CD instances added to the namespace of the GitOps Operator.

Procedure

  1. In the Terminal type the following command:
$ oc delete gitopsservice cluster -n openshift-gitops
Note

You cannot delete an Argo CD cluster from the web console UI.

After the command runs successfully all the Argo CD instances will be deleted from the openshift-gitops namespace.

Delete any other Argo CD instances from other namespaces using the same command:

$ oc delete gitopsservice cluster -n <namespace>

5.4.2. Uninstalling the GitOps Operator

Procedure

  1. From the Operators OperatorHub page, use the Filter by keyword box to search for Red Hat OpenShift GitOps Operator tile.
  2. Click the Red Hat OpenShift GitOps Operator tile. The Operator tile indicates it is installed.
  3. In the Red Hat OpenShift GitOps Operator descriptor page, click Uninstall.

Additional resources

5.5. Setting up an Argo CD instance

By default, the Red Hat OpenShift GitOps installs an instance of Argo CD in the openshift-gitops namespace with additional permissions for managing certain cluster-scoped resources. To manage cluster configurations or deploy applications, you can install and deploy a new Argo CD instance. By default, any new instance has permissions to manage resources only in the namespace where it is deployed.

5.5.1. Installing Argo CD

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

Procedure

  1. Log in to the OpenShift Container Platform web console.
  2. Click Operators Installed Operators.
  3. Create or select the project where you want to install the Argo CD instance from the Project drop-down menu.
  4. Select OpenShift GitOps Operator from the installed operators and select the Argo CD tab.
  5. Click Create to configure the parameters:

    1. Enter the Name of the instance. By default, the Name is set to argocd.
    2. Create an external OS Route to access Argo CD server. Click Server Route and check Enabled.
  6. To open the Argo CD web UI, click the route by navigating to Networking Routes <instance name>-server in the project where the Argo CD instance is installed.

5.5.2. Enabling replicas for Argo CD server and repo server

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.

Procedure

  • Set the replicas parameters for the repo and server spec to the number of replicas you want to run:

    Example Argo CD custom resource

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: repo
    spec:
      repo:
        replicas: <number_of_replicas>
      server:
        replicas: <number_of_replicas>
        route:
          enabled: true
          path: /
          tls:
            insecureEdgeTerminationPolicy: Redirect
            termination: passthrough
          wildcardPolicy: None

5.5.3. Deploying resources to a different namespace

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.

Procedure

  • Configure the namespace:

    $ oc label namespace <namespace> \
    argocd.argoproj.io/managed-by=<instance_name> 1
    1
    The namespace where Argo CD is installed.

5.6. Monitoring Argo CD instances

By default, the Red Hat OpenShift GitOps Operator automatically detects an installed Argo CD instance in your defined namespace, for example, openshift-gitops, and connects it to the monitoring stack of the cluster to provide alerts for out-of-sync applications.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have access to the OpenShift Container Platform web console.
  • You have installed the Red Hat OpenShift GitOps Operator in your cluster.
  • You have installed an Argo CD application in your defined namespace, for example, openshift-gitops.

5.6.1. Monitoring Argo CD health using Prometheus metrics

You can monitor the health status of an Argo CD application by running Prometheus metrics queries against it.

Procedure

  1. In the Developer perspective of the web console, select the namespace where your Argo CD application is installed, and navigate to Observe Metrics.
  2. From the Select query drop-down list, select Custom query.
  3. To check the health status of your Argo CD application, enter the Prometheus Query Language (PromQL) query similar to the following example in the Expression field:

    Example

    sum(argocd_app_info{dest_namespace=~"<your_defined_namespace>",health_status!=""}) by (health_status) 1

    1
    Replace the <your_defined_namespace> variable with the actual name of your defined namespace, for example openshift-gitops.

5.7. Configuring an OpenShift cluster by deploying an application with cluster configurations

With Red Hat OpenShift GitOps, you can configure Argo CD to recursively sync the content of a Git directory with an application that contains custom configurations for your cluster.

Prerequisites

  • You have logged in to the OpenShift Container Platform cluster as an administrator.
  • You have installed the Red Hat OpenShift GitOps Operator in your cluster.
  • You have logged into Argo CD instance.

5.7.1. Using an Argo CD instance to manage cluster-scoped resources

To manage cluster-scoped resources, update the existing Subscription object for the Red Hat OpenShift GitOps Operator and add the namespace of the Argo CD instance to the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable in the spec section.

Procedure

  1. In the Administrator perspective of the web console, navigate to Operators Installed Operators Red Hat OpenShift GitOps Subscription.
  2. Click the Actions drop-down menu then click Edit Subscription.
  3. On the openshift-gitops-operator Subscription details page, under the YAML tab, edit the Subscription YAML file by adding the namespace of the Argo CD instance to the ARGOCD_CLUSTER_CONFIG_NAMESPACES environment variable in the spec section:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-gitops-operator
      namespace: openshift-operators
    ...
    spec:
      config:
        env:
        - name: ARGOCD_CLUSTER_CONFIG_NAMESPACES
          value: openshift-gitops, <list of namespaces of cluster-scoped Argo CD instances>
    ...
  4. To verify that the Argo instance is configured with a cluster role to manage cluster-scoped resources, perform the following steps:

    1. Navigate to User Management Roles and from the Filter drop-down menu select Cluster-wide Roles.
    2. Search for the argocd-application-controller by using the Search by name field.

      The Roles page displays the created cluster role.

      Tip

      Alternatively, in the OpenShift CLI, run the following command:

      oc auth can-i create oauth -n openshift-gitops --as system:serviceaccount:openshift-gitops:openshift-gitops-argocd-application-controller

      The output yes verifies that the Argo instance is configured with a cluster role to manage cluster-scoped resources. Else, check your configurations and take necessary steps as required.

5.7.2. Default permissions of an Argocd instance

By default Argo CD instance has the following permissions:

  • Argo CD instance has the admin privileges to manage resources only in the namespace where it is deployed. For instance, an Argo CD instance deployed in the foo namespace has the admin privileges to manage resources only for that namespace.
  • Argo CD has the following cluster-scoped permissions because Argo CD requires cluster-wide read privileges on resources to function appropriately:

    - verbs:
        - get
        - list
        - watch
       apiGroups:
        - '*'
       resources:
        - '*'
     - verbs:
        - get
        - list
       nonResourceURLs:
        - '*'
Note
  • You can edit the cluster roles used by the argocd-server and argocd-application-controller components where Argo CD is running such that the write privileges are limited to only the namespaces and resources that you wish Argo CD to manage.

    $ oc edit clusterrole argocd-server
    $ oc edit clusterrole argocd-application-controller

5.7.3. Running the Argo CD instance at the cluster-level

The default Argo CD instance and the accompanying controllers, installed by the Red Hat OpenShift GitOps Operator, can now run on the infrastructure nodes of the cluster by setting a simple configuration toggle.

Procedure

  1. Label the existing nodes:

    $ oc label node <node-name> node-role.kubernetes.io/infra=""
  2. Optional: If required, you can also apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes:

    $ oc adm taint nodes -l node-role.kubernetes.io/infra \
    infra=reserved:NoSchedule infra=reserved:NoExecute
  3. Add the runOnInfra toggle in the GitOpsService custom resource:

    apiVersion: pipelines.openshift.io/v1alpha1
    kind: GitopsService
    metadata:
      name: cluster
    spec:
      runOnInfra: true
  4. Optional: If taints have been added to the nodes, then add tolerations to the GitOpsService custom resource, for example:

      spec:
        runOnInfra: true
        tolerations:
        - effect: NoSchedule
          key: infra
          value: reserved
        - effect: NoExecute
          key: infra
          value: reserved
  5. Verify that the workloads in the openshift-gitops namespace are now scheduled on the infrastructure nodes by viewing Pods Pod details for any pod in the console UI.
Note

Any nodeSelectors and tolerations manually added to the default Argo CD custom resource are overwritten by the toggle and tolerations in the GitOpsService custom resource.

Additional resources

5.7.4. Creating an application by using the Argo CD dashboard

Argo CD provides a dashboard which allows you to create applications.

This sample workflow walks you through the process of configuring Argo CD to recursively sync the content of the cluster directory to the cluster-configs application. The directory defines the OpenShift Container Platform web console cluster configurations that add a link to the Red Hat Developer Blog - Kubernetes under the red hat applications menu icon menu in the web console, and defines a namespace spring-petclinic on the cluster.

Procedure

  1. In the Argo CD dashboard, click NEW APP to add a new Argo CD application.
  2. For this workflow, create a cluster-configs application with the following configurations:

    Application Name
    cluster-configs
    Project
    default
    Sync Policy
    Manual
    Repository URL
    https://github.com/redhat-developer/openshift-gitops-getting-started
    Revision
    HEAD
    Path
    cluster
    Destination
    https://kubernetes.default.svc
    Namespace
    spring-petclinic
    Directory Recurse
    checked
  3. Click CREATE to create your application.
  4. Open the Administrator perspective of the web console and navigate to Administration Namespaces in the menu on the left.
  5. Search for and select the namespace, then enter argocd.argoproj.io/managed-by=openshift-gitops in the Label field so that the Argo CD instance in the openshift-gitops namespace can manage your namespace.

5.7.5. Creating an application by using the oc tool

You can create Argo CD applications in your terminal by using the oc tool.

Procedure

  1. Download the sample application:

    $ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git
  2. Create the application:

    $ oc create -f openshift-gitops-getting-started/argo/app.yaml
  3. Run the oc get command to review the created application:

    $ oc get application -n openshift-gitops
  4. Add a label to the namespace your application is deployed in so that the Argo CD instance in the openshift-gitops namespace can manage it:

    $ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops

5.7.6. Synchronizing your application with your Git repository

Procedure

  1. In the Argo CD dashboard, notice that the cluster-configs Argo CD application has the statuses Missing and OutOfSync. Because the application was configured with a manual sync policy, Argo CD does not sync it automatically.
  2. Click SYNC on the cluster-configs tile, review the changes, and then click SYNCHRONIZE. Argo CD will detect any changes in the Git repository automatically. If the configurations are changed, Argo CD will change the status of the cluster-configs to OutOfSync. You can modify the synchronization policy for Argo CD to automatically apply changes from your Git repository to the cluster.
  3. Notice that the cluster-configs Argo CD application now has the statuses Healthy and Synced. Click the cluster-configs tile to check the details of the synchronized resources and their status on the cluster.
  4. Navigate to the OpenShift Container Platform web console and click red hat applications menu icon to verify that a link to the Red Hat Developer Blog - Kubernetes is now present there.
  5. Navigate to the Project page and search for the spring-petclinic namespace to verify that it has been added to the cluster.

    Your cluster configurations have been successfully synchronized to the cluster.

5.7.7. In-built permissions for cluster configuration

By default, the Argo CD instance has permissions to manage specific cluster-scoped resources such as cluster Operators, optional OLM Operators and user management.

Note

Argo CD does not have cluster-admin permissions.

Permissions for the Argo CD instance:

Resources

Descriptions

Resource Groups

Configure the user or administrator

operators.coreos.com

Optional Operators managed by OLM

user.openshift.io , rbac.authorization.k8s.io

Groups, Users and their permissions

config.openshift.io

Control plane Operators managed by CVO used to configure cluster-wide build configuration, registry configuration and scheduler policies

storage.k8s.io

Storage

console.openshift.io

Console customization

5.7.8. Adding permissions for cluster configuration

You can grant permissions for an Argo CD instance to manage cluster configuration. Create a cluster role with additional permissions and then create a new cluster role binding to associate the cluster role with a service account.

Procedure

  1. Log in to the OpenShift Container Platform web console as an admin.
  2. In the web console, select User Management Roles Create Role. Use the following ClusterRole YAML template to add rules to specify the additional permissions.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: secrets-cluster-role
    rules:
    - apiGroups: [""]
      resources: ["secrets"]
      verbs: ["*"]
  3. Click Create to add the cluster role.
  4. Now create the cluster role binding. In the web console, select User Management Role Bindings Create Binding.
  5. Select All Projects from the Project drop-down.
  6. Click Create binding.
  7. Select Binding type as Cluster-wide role binding (ClusterRoleBinding).
  8. Enter a unique value for the RoleBinding name.
  9. Select the newly created cluster role or an existing cluster role from the drop down list.
  10. Select the Subject as ServiceAccount and the provide the Subject namespace and name.

    1. Subject namespace: openshift-gitops
    2. Subject name: openshift-gitops-argocd-application-controller
  11. Click Create. The YAML file for the ClusterRoleBinding object is as follows:

    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: cluster-role-binding
    subjects:
      - kind: ServiceAccount
        name: openshift-gitops-argocd-application-controller
        namespace: openshift-gitops
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: admin

5.7.9. Installing OLM Operators using Red Hat OpenShift GitOps

Red Hat OpenShift GitOps with cluster configurations manages specific cluster-scoped resources and takes care of installing cluster Operators or any namespace-scoped OLM Operators.

Consider a case where as a cluster administrator, you have to install an OLM Operator such as Tekton. You use the OpenShift Container Platform web console to manually install a Tekton Operator or the OpenShift CLI to manually install a Tekton subscription and Tekton Operator group on your cluster.

Red Hat OpenShift GitOps places your Kubernetes resources in your Git repository. As a cluster administrator, use Red Hat OpenShift GitOps to manage and automate the installation of other OLM Operators without any manual procedures. For example, after you place the Tekton subscription in your Git repository by using Red Hat OpenShift GitOps, the Red Hat OpenShift GitOps automatically takes this Tekton subscription from your Git repository and installs the Tekton Operator on your cluster.

5.7.9.1. Installing cluster-scoped Operators

Operator Lifecycle Manager (OLM) uses a default global-operators Operator group in the openshift-operators namespace for cluster-scoped Operators. Hence you do not have to manage the OperatorGroup resource in your Gitops repository. However, for namespace-scoped Operators, you must manage the OperatorGroup resource in that namespace.

To install cluster-scoped Operators, create and place the Subscription resource of the required Operator in your Git repository.

Example: Grafana Operator subscription

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: grafana
spec:
  channel: v4
  installPlanApproval: Automatic
  name: grafana-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

5.7.9.2. Installing namepace-scoped Operators

To install namespace-scoped Operators, create and place the Subscription and OperatorGroup resources of the required Operator in your Git repository.

Example: Ansible Automation Platform Resource Operator

...
apiVersion: v1
kind: Namespace
metadata:
  labels:
    openshift.io/cluster-monitoring: "true"
  name: ansible-automation-platform
...
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ansible-automation-platform-operator
  namespace: ansible-automation-platform
spec:
  targetNamespaces:
    - ansible-automation-platform
...
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ansible-automation-platform
  namespace: ansible-automation-platform
spec:
  channel: patch-me
  installPlanApproval: Automatic
  name: ansible-automation-platform-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
...

Important

When deploying multiple Operators using Red Hat OpenShift GitOps, you must create only a single Operator group in the corresponding namespace. If more than one Operator group exists in a single namespace, any CSV created in that namespace transition to a failure state with the TooManyOperatorGroups reason. After the number of Operator groups in their corresponding namespaces reaches one, all the previous failure state CSVs transition to pending state. You must manually approve the pending install plan to complete the Operator installation.

5.8. Deploying a Spring Boot application with Argo CD

With Argo CD, you can deploy your applications to the OpenShift cluster either by using the Argo CD dashboard or by using the oc tool.

Prerequisites

  • Red Hat OpenShift GitOps is installed in your cluster.
  • Logged into Argo CD instance.

5.8.1. Creating an application by using the Argo CD dashboard

Argo CD provides a dashboard which allows you to create applications.

This sample workflow walks you through the process of configuring Argo CD to recursively sync the content of the cluster directory to the cluster-configs application. The directory defines the OpenShift Container Platform web console cluster configurations that add a link to the Red Hat Developer Blog - Kubernetes under the red hat applications menu icon menu in the web console, and defines a namespace spring-petclinic on the cluster.

Procedure

  1. In the Argo CD dashboard, click NEW APP to add a new Argo CD application.
  2. For this workflow, create a cluster-configs application with the following configurations:

    Application Name
    cluster-configs
    Project
    default
    Sync Policy
    Manual
    Repository URL
    https://github.com/redhat-developer/openshift-gitops-getting-started
    Revision
    HEAD
    Path
    cluster
    Destination
    https://kubernetes.default.svc
    Namespace
    spring-petclinic
    Directory Recurse
    checked
  3. For this workflow, create a spring-petclinic application with the following configurations:

    Application Name
    spring-petclinic
    Project
    default
    Sync Policy
    Automatic
    Repository URL
    https://github.com/redhat-developer/openshift-gitops-getting-started
    Revision
    HEAD
    Path
    app
    Destination
    https://kubernetes.default.svc
    Namespace
    spring-petclinic
  4. Click CREATE to create your application.
  5. Open the Administrator perspective of the web console and navigate to Administration Namespaces in the menu on the left.
  6. Search for and select the namespace, then enter argocd.argoproj.io/managed-by=openshift-gitops in the Label field so that the Argo CD instance in the openshift-gitops namespace can manage your namespace.

5.8.2. Creating an application by using the oc tool

You can create Argo CD applications in your terminal by using the oc tool.

Procedure

  1. Download the sample application:

    $ git clone git@github.com:redhat-developer/openshift-gitops-getting-started.git
  2. Create the application:

    $ oc create -f openshift-gitops-getting-started/argo/app.yaml
    $ oc create -f openshift-gitops-getting-started/argo/app.yaml
  3. Run the oc get command to review the created application:

    $ oc get application -n openshift-gitops
  4. Add a label to the namespace your application is deployed in so that the Argo CD instance in the openshift-gitops namespace can manage it:

    $ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops
    $ oc label namespace spring-petclinic argocd.argoproj.io/managed-by=openshift-gitops

5.8.3. Verifying Argo CD self-healing behavior

Argo CD constantly monitors the state of deployed applications, detects differences between the specified manifests in Git and live changes in the cluster, and then automatically corrects them. This behavior is referred to as self-healing.

You can test and observe the self-healing behavior in Argo CD.

Prerequisites

  • The sample app-spring-petclinic application is deployed and configured.

Procedure

  1. In the Argo CD dashboard, verify that your application has the Synced status.
  2. Click the app-spring-petclinic tile in the Argo CD dashboard to view the application resources that are deployed to the cluster.
  3. In the OpenShift Container Platform web console, navigate to the Developer perspective.
  4. Modify the Spring PetClinic deployment and commit the changes to the app/ directory of the Git repository. Argo CD will automatically deploy the changes to the cluster.

    1. Fork the OpenShift GitOps getting started repository.
    2. In the deployment.yaml file, change the failureThreshold value to 5.
    3. In the deployment cluster, run the following command to verify the changed value of the failureThreshold field:

      $ oc edit deployment spring-petclinic -n spring-petclinic
  5. Test the self-healing behavior by modifying the deployment on the cluster and scaling it up to two pods while watching the application in the OpenShift Container Platform web console.

    1. Run the following command to modify the deployment:

      $ oc scale deployment spring-petclinic --replicas 2  -n spring-petclinic
    2. In the OpenShift Container Platform web console, notice that the deployment scales up to two pods and immediately scales down again to one pod. Argo CD detected a difference from the Git repository and auto-healed the application on the OpenShift Container Platform cluster.
  6. In the Argo CD dashboard, click the app-spring-petclinic tile APP DETAILS EVENTS. The EVENTS tab displays the following events: Argo CD detecting out of sync deployment resources on the cluster and then resyncing the Git repository to correct it.

5.9. Argo CD Operator

The ArgoCD custom resource is a Kubernetes Custom Resource (CRD) that describes the desired state for a given Argo CD cluster that allows you to configure the components which make up an Argo CD cluster.

5.9.1. Argo CD CLI tool

The Argo CD CLI tool is a tool used to configure Argo CD through the command line. Red Hat OpenShift GitOps does not support this binary. Use the OpenShift Console to configure the Argo CD.

5.9.2. Argo CD custom resource properties

The Argo CD Custom Resource consists of the following properties:

Name

Description

Default

Properties

ApplicationInstanceLabelKey

The metadata.label key name where Argo CD injects the app name as a tracking label.

app.kubernetes.io/instance

 

ApplicationSet

ApplicationSet controller configuration options.

<Object>

  • <Image> - The container image for the ApplicationSet controller. This overrides the ARGOCD_APPLICATIONSET_IMAGE environment variable.
  • <Version> - The tag to use with the ApplicationSet container image.
  • <Resources> - The container compute resources.
  • <LogLevel> - The log level used by the Argo CD Application Controller component. Valid options are debug, info, error, and warn.
  • <LogFormat> - The log format used by the Argo CD Application Controller component. Valid options are text or json.
  • <PrallelismLimit> - The kubectl parallelism limit to set for the controller (--kubectl-parallelism-limit flag).

ConfigManagementPlugins

Add a configuration management plugin.

<empty>

 

Controller

Argo CD Application Controller options.

<Object>

  • <Processors.Operation> - The number of operation processors.
  • <Processors.Status> - The number of status processors.
  • <Resources> - The container compute resources.
  • <LogLevel> - The log level used by the Argo CD Application Controller component. Valid options are debug, info, error, and warn.
  • <AppSync> - AppSync is used to control the sync frequency of Argo CD applications
  • <Sharding.enabled> - Enable sharding on the Argo CD Application Controller component. This property is used to manage a large number of clusters to relieve memory pressure on the controller component.
  • <Sharding.replicas> - The number of replicas that will be used to support sharding of the Argo CD Application Controller.
  • <Env> - Environment to set for the application controller workloads.

DisableAdmin

Disables the built-in admin user.

false

 

GATrackingID

Use a Google Analytics tracking ID.

<empty>

 

GAAnonymizeusers

Enable hashed usernames sent to google analytics.

false

 

HA

High availablity options.

<Object>

  • <Enabled> - Toggle high availability support globally for Argo CD.
  • <RedisProxyImage> - The Redis HAProxy container image. This overrides the ARGOCD_REDIS_HA_PROXY_IMAGE environment variable.
  • <RedisProxyVersion> - The tag to use for the Redis HAProxy container image.

HelpChatURL

URL for getting chat help (this will typically be your Slack channel for support).

https://mycorp.slack.com/argo-cd

 

HelpChatText

The text that appears in a text box for getting chat help.

Chat now!

 

Image

The container image for all Argo CD components. This overrides the ARGOCD_IMAGE environment variable.

argoproj/argocd

 

Ingress

Ingress configuration options.

<Object>

 

InitialRepositories

Initial Git repositories to configure Argo CD to use upon creation of the cluster.

<empty>

 

Notifications

Notifications controller configuration options.

<Object>

  • <Enabled> - The toggle to start the notifications-controller.
  • <Image> - The container image for all Argo CD components. This overrides the ARGOCD_IMAGE environment variable.
  • <Version> - The tag to use with the Notifications container image.
  • <Resources> - The container compute resources.
  • <LogLevel> - The log level used by the Argo CD Application Controller component. Valid options are debug, info, error, and warn.

RepositoryCredentials

Git repository credential templates to configure Argo CD to use upon creation of the cluster.

<empty>

 

InitialSSHKnownHosts

Initial SSH Known Hosts for Argo CD to use upon creation of the cluster.

<default_Argo_CD_Known_Hosts>

 

KustomizeBuildOptions

The build options and parameters to use with kustomize build.

<empty>

 

OIDCConfig

The OIDC configuration as an alternative to Dex.

<empty>

 

NodePlacement

Add the nodeSelector and the tolerations.

<empty>

 

Prometheus

Prometheus configuration options.

<Object>

  • <Enabled> - Toggle Prometheus support globally for Argo CD.
  • <Host> - The hostname to use for Ingress or Route resources.
  • <Ingress> - Toggles Ingress for Prometheus.
  • <Route> - Route configuration options.
  • <Size> - The replica count for the Prometheus StatefulSet.

RBAC

RBAC configuration options.

<Object>

  • <DefaultPolicy> - The policy.default property in the argocd-rbac-cm config map. The name of the default role which Argo CD will fall back to, when authorizing API requests.
  • <Policy> - The policy.csv property in the argocd-rbac-cm config map. CSV data containing user-defined RBAC policies and role definitions.
  • <Scopes> - The scopes property in the argocd-rbac-cm config map. Controls which OIDC scopes to examine during RBAC enforcement (in addition to sub scope).

Redis

Redis configuration options.

<Object>

  • <AutoTLS> - Use the provider to create the Redis server’s TLS certificate (one of: openshift). Currently only available for OpenShift Container Platform.
  • <DisableTLSVerification> - Define whether the Redis server should be accessed using strict TLS validation.
  • <Image> - The container image for Redis. This overrides the ARGOCD_REDIS_IMAGE environment variable.
  • <Resources> - The container compute resources.
  • <Version> - The tag to use with the Redis container image.

ResourceCustomizations

Customize resource behavior.

<empty>

 

ResourceExclusions

Completely ignore entire classes of resource group.

<empty>

 

ResourceInclusions

The configuration to configure which resource group/kinds are applied.

<empty>

 

Server

Argo CD Server configuration options.

<Object>

  • <Autoscale> - Server autoscale configuration options.
  • <ExtraCommandArgs> - List of arguments added to the existing arguments set by the Operator.
  • <GRPC> - GRPC configuration options.
  • <Host> - The hostname used for Ingress or Route resources.
  • <Ingress> - Ingress configuration for the Argo CD server component.
  • <Insecure> - Toggles the insecure flag for Argo CD server.
  • <Resources> - The container compute resources.
  • <Replicas> - The number of replicas for the Argo CD server. Must be greater than or equal to 0. If Autoscale is enabled, Replicas is ignored.
  • <Route> - Route configuration options.
  • <Service.Type> - The ServiceType used for the service resource.
  • <LogLevel> - The log level to be used by the Argo CD Server component. Valid options are debug, info, error, and warn.
  • <LogFormat> - The log format used by the Argo CD Application Controller component. Valid options are text or json.
  • <Env> - Environment to set for the server workloads.

SSO

Single Sign-on options.

<Object>

  • <Image> - The container image for Keycloak. This overrides the ARGOCD_KEYCLOAK_IMAGE environment variable.
  • <Keycloak> - Configuration options for Keycloak SSO provider.
  • <Dex> - Configuration options for Dex SSO provider.
  • <Provider> - The name of the provider used to configure Single Sign-on. For now the supported options are Dex and Keycloak.
  • <Resources> - The container compute resources.
  • <VerifyTLS> - Whether to enforce strict TLS checking when communicating with Keycloak service.
  • <Version> - The tag to use with the Keycloak container image.

StatusBadgeEnabled

Enable application status badge.

true

 

TLS

TLS configuration options.

<Object>

  • <CA.ConfigMapName> - The name of the ConfigMap which contains the CA certificate.
  • <CA.SecretName> - The name of the secret which contains the CA Certificate and Key.
  • <InitialCerts> - Initial set of certificates in the argocd-tls-certs-cm config map for connecting Git repositories via HTTPS.

UserAnonyousEnabled

Enable anonymous user access.

true

 

Version

The tag to use with the container image for all Argo CD components.

Latest Argo CD version

 

Banner

Add a UI banner message.

<Object>

  • <Banner.Content> - The banner message content (required if a banner is displayed).
  • <Banner.URL.SecretName> - The banner message link URL (optional).

5.9.3. Repo server properties

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

Name

Default

Description

Resources

<empty>

The container compute resources.

MountSAToken

false

Whether the ServiceAccount token should be mounted to the repo-server pod.

ServiceAccount

""

The name of the ServiceAccount to use with the repo-server pod.

VerifyTLS

false

Whether to enforce strict TLS checking on all components when communicating with repo server.

AutoTLS

""

Provider to use for setting up TLS the repo-server’s gRPC TLS certificate (one of: openshift). Currently only available for OpenShift.

Image

argoproj/argocd

The container image for Argo CD Repo server. This overrides the ARGOCD_REPOSERVER_IMAGE environment variable.

Version

same as .spec.Version

The tag to use with the Argo CD Repo server.

LogLevel

info

The log level used by the Argo CD Repo server. Valid options are debug, info, error, and warn.

LogFormat

text

The log format to be used by the Argo CD Repo server. Valid options are text or json.

ExecTimeout

180

Execution timeout in seconds for rendering tools (e.g. Helm, Kustomize).

Env

<empty>

Environment to set for the repository server workloads.

Replicas

<empty>

The number of replicas for the Argo CD Repo server. Must be greater than or equal to 0.

5.9.4. Enabling notifications with Argo CD instance

To enable or disable the Argo CD notifications controller, set a parameter in the Argo CD custom resource. By default, notifications are disabled. To enable notifications, set the enabled parameter to true in the .yaml file:

Procedure

  1. Set the enabled parameter to true:
apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  notifications:
    enabled: true

5.10. Configuring secure communication with Redis

Using the Transport Layer Security (TLS) encryption with Red Hat OpenShift GitOps, you can secure the communication between the Argo CD components and Redis cache and protect the possibly sensitive data in transit.

You can secure communication with Redis by using one of the following configurations:

  • Enable the autotls setting to issue an appropriate certificate for TLS encryption.
  • Manually configure the TLS encryption by creating the argocd-operator-redis-tls secret with a key and certificate pair.

Both configurations are possible with or without the High Availability (HA) enabled.

Prerequisites

  • You have access to the cluster with cluster-admin privileges.
  • You have access to the OpenShift Container Platform web console.
  • Red Hat OpenShift GitOps Operator is installed on your cluster.

5.10.1. Configuring TLS for Redis with autotls enabled

You can configure TLS encryption for Redis by enabling the autotls setting on a new or already existing Argo CD instance. The configuration automatically provisions the argocd-operator-redis-tls secret and does not require further steps. Currently, OpenShift Container Platform is the only supported secret provider.

Note

By default, the autotls setting is disabled.

Procedure

  1. Log in to the OpenShift Container Platform web console.
  2. Create an Argo CD instance with autotls enabled:

    1. In the Administrator perspective of the web console, use the left navigation panel to go to Administration CustomResourceDefinitions.
    2. Search for argocds.argoproj.io and click ArgoCD custom resource definition (CRD).
    3. On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD.
    4. Edit or replace the YAML similar to the following example:

      Example Argo CD CR with autotls enabled

      apiVersion: argoproj.io/v1alpha1
      kind: ArgoCD
      metadata:
        name: argocd 1
        namespace: openshift-gitops 2
      spec:
        redis:
          autotls: openshift 3
        ha:
          enabled: true 4

      1
      The name of the Argo CD instance.
      2
      The namespace where you want to run the Argo CD instance.
      3
      The flag that enables the autotls setting and creates a TLS certificate for Redis.
      4
      The flag value that enables the HA feature. If you do not want to enable HA, do not include this line or set the flag value as false.
      Tip

      Alternatively, you can enable the autotls setting on an already existing Argo CD instance by running the following command:

      $ oc patch argocds.argoproj.io <instance-name> --type=merge -p '{"spec":{"redis":{"autotls":"openshift"}}}'
    5. Click Create.
    6. Verify that the Argo CD pods are ready and running:

      $ oc get pods -n <namespace> 1
      1
      Specify a namespace where the Argo CD instance is running, for example openshift-gitops.

      Example output with HA disabled

      NAME                                  READY   STATUS    RESTARTS   AGE
      argocd-application-controller-0       1/1     Running   0          26s
      argocd-redis-84b77d4f58-vp6zm         1/1     Running   0          37s
      argocd-repo-server-5b959b57f4-znxjq   1/1     Running   0          37s
      argocd-server-6b8787d686-wv9zh        1/1     Running   0          37s

      Note

      The HA-enabled TLS configuration requires a cluster with at least three worker nodes. It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration.

      Example output with HA enabled

      NAME                                       READY   STATUS    RESTARTS   AGE
      argocd-application-controller-0            1/1     Running   0          10m
      argocd-redis-ha-haproxy-669757fdb7-5xg8h   1/1     Running   0          10m
      argocd-redis-ha-server-0                   2/2     Running   0          9m9s
      argocd-redis-ha-server-1                   2/2     Running   0          98s
      argocd-redis-ha-server-2                   2/2     Running   0          53s
      argocd-repo-server-576499d46d-8hgbh        1/1     Running   0          10m
      argocd-server-9486f88b7-dk2ks              1/1     Running   0          10m

  3. Verify that the argocd-operator-redis-tls secret is created:

    $ oc get secrets argocd-operator-redis-tls -n <namespace> 1
    1
    Specify a namespace where the Argo CD instance is running, for example openshift-gitops.

    Example output

    NAME                        TYPE                DATA   AGE
    argocd-operator-redis-tls   kubernetes.io/tls   2      30s

    The secret must be of the kubernetes.io/tls type and a size of 2.

5.10.2. Configuring TLS for Redis with autotls disabled

You can manually configure TLS encryption for Redis by creating the argocd-operator-redis-tls secret with a key and certificate pair. In addition, you must annotate the secret to indicate that it belongs to the appropriate Argo CD instance. The steps to create a certificate and secret vary for instances with High Availability (HA) enabled.

Procedure

  1. Log in to the OpenShift Container Platform web console.
  2. Create an Argo CD instance:

    1. In the Administrator perspective of the web console, use the left navigation panel to go to Administration CustomResourceDefinitions.
    2. Search for argocds.argoproj.io and click ArgoCD custom resource definition (CRD).
    3. On the CustomResourceDefinition details page, click the Instances tab, and then click Create ArgoCD.
    4. Edit or replace the YAML similar to the following example:

      Example ArgoCD CR with autotls disabled

      apiVersion: argoproj.io/v1alpha1
      kind: ArgoCD
      metadata:
        name: argocd 1
        namespace: openshift-gitops 2
      spec:
        ha:
          enabled: true 3

      1
      The name of the Argo CD instance.
      2
      The namespace where you want to run the Argo CD instance.
      3
      The flag value that enables the HA feature. If you do not want to enable HA, do not include this line or set the flag value as false.
    5. Click Create.
    6. Verify that the Argo CD pods are ready and running:

      $ oc get pods -n <namespace> 1
      1
      Specify a namespace where the Argo CD instance is running, for example openshift-gitops.

      Example output with HA disabled

      NAME                                  READY   STATUS    RESTARTS   AGE
      argocd-application-controller-0       1/1     Running   0          26s
      argocd-redis-84b77d4f58-vp6zm         1/1     Running   0          37s
      argocd-repo-server-5b959b57f4-znxjq   1/1     Running   0          37s
      argocd-server-6b8787d686-wv9zh        1/1     Running   0          37s

      Note

      The HA-enabled TLS configuration requires a cluster with at least three worker nodes. It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration.

      Example output with HA enabled

      NAME                                       READY   STATUS    RESTARTS   AGE
      argocd-application-controller-0            1/1     Running   0          10m
      argocd-redis-ha-haproxy-669757fdb7-5xg8h   1/1     Running   0          10m
      argocd-redis-ha-server-0                   2/2     Running   0          9m9s
      argocd-redis-ha-server-1                   2/2     Running   0          98s
      argocd-redis-ha-server-2                   2/2     Running   0          53s
      argocd-repo-server-576499d46d-8hgbh        1/1     Running   0          10m
      argocd-server-9486f88b7-dk2ks              1/1     Running   0          10m

  3. Create a self-signed certificate for the Redis server by using one of the following options depending on your HA configuration:

    • For the Argo CD instance with HA disabled, run the following command:

      $ openssl req -new -x509 -sha256 \
        -subj "/C=XX/ST=XX/O=Testing/CN=redis" \
        -reqexts SAN -extensions SAN \
        -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1
        -keyout /tmp/redis.key \
        -out /tmp/redis.crt \
        -newkey rsa:4096 \
        -nodes \
        -sha256 \
        -days 10
      1
      Specify a namespace where the Argo CD instance is running, for example openshift-gitops.

      Example output

      Generating a RSA private key
      ...............++++
      ............................++++
      writing new private key to '/tmp/redis.key'

    • For the Argo CD instance with HA enabled, run the following command:

      $ openssl req -new -x509 -sha256 \
        -subj "/C=XX/ST=XX/O=Testing/CN=redis" \
        -reqexts SAN -extensions SAN \
        -config <(printf "\n[SAN]\nsubjectAltName=DNS:argocd-redis-ha-haproxy.<namespace>.svc.cluster.local\n[req]\ndistinguished_name=req") \ 1
        -keyout /tmp/redis-ha.key \
        -out /tmp/redis-ha.crt \
        -newkey rsa:4096 \
        -nodes \
        -sha256 \
        -days 10
      1
      Specify a namespace where the Argo CD instance is running, for example openshift-gitops.

      Example output

      Generating a RSA private key
      ...............++++
      ............................++++
      writing new private key to '/tmp/redis-ha.key'

  4. Verify that the generated certificate and key are available in the /tmp directory by running the following commands:

    $ cd /tmp
    $ ls

    Example output with HA disabled

    ...
    redis.crt
    redis.key
    ...

    Example output with HA enabled

    ...
    redis-ha.crt
    redis-ha.key
    ...

  5. Create the argocd-operator-redis-tls secret by using one of the following options depending on your HA configuration:

    • For the Argo CD instance with HA disabled, run the following command:

      $ oc create secret tls argocd-operator-redis-tls --key=/tmp/redis.key --cert=/tmp/redis.crt
    • For the Argo CD instance with HA enabled, run the following command:

      $ oc create secret tls argocd-operator-redis-tls --key=/tmp/redis-ha.key --cert=/tmp/redis-ha.crt

      Example output

      secret/argocd-operator-redis-tls created

  6. Annotate the secret to indicate that it belongs to the Argo CD CR:

    $ oc annotate secret argocd-operator-redis-tls argocds.argoproj.io/name=<instance-name> 1
    1
    Specify a name of the Argo CD instance, for example argocd.

    Example output

    secret/argocd-operator-redis-tls annotated

  7. Verify that the Argo CD pods are ready and running:

    $ oc get pods -n <namespace> 1
    1
    Specify a namespace where the Argo CD instance is running, for example openshift-gitops.

    Example output with HA disabled

    NAME                                  READY   STATUS    RESTARTS   AGE
    argocd-application-controller-0       1/1     Running   0          26s
    argocd-redis-84b77d4f58-vp6zm         1/1     Running   0          37s
    argocd-repo-server-5b959b57f4-znxjq   1/1     Running   0          37s
    argocd-server-6b8787d686-wv9zh        1/1     Running   0          37s

    Note

    It can take a few minutes for the output to appear if you have enabled the Argo CD instances with HA configuration.

    Example output with HA enabled

    NAME                                       READY   STATUS    RESTARTS   AGE
    argocd-application-controller-0            1/1     Running   0          10m
    argocd-redis-ha-haproxy-669757fdb7-5xg8h   1/1     Running   0          10m
    argocd-redis-ha-server-0                   2/2     Running   0          9m9s
    argocd-redis-ha-server-1                   2/2     Running   0          98s
    argocd-redis-ha-server-2                   2/2     Running   0          53s
    argocd-repo-server-576499d46d-8hgbh        1/1     Running   0          10m
    argocd-server-9486f88b7-dk2ks              1/1     Running   0          10m

5.11. Monitoring health information for application resources and deployments

The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console shows a list of the successful deployments of the application environments, along with links to the revision for each deployment.

The Application environments page in the Developer perspective of the OpenShift Container Platform web console displays the health status of the application resources, such as routes, synchronization status, deployment configuration, and deployment history.

The environments pages in the Developer perspective of the OpenShift Container Platform web console are decoupled from the Red Hat OpenShift GitOps Application Manager command-line interface (CLI), kam. You do not have to use kam to generate Application Environment manifests for the environments to show up in the Developer perspective of the OpenShift Container Platform web console. You can use your own manifests, but the environments must still be represented by namespaces. In addition, specific labels and annotations are still needed.

5.11.1. Settings for environment labels and annotations

This section provides reference settings for environment labels and annotations required to display an environment application in the Environments page, in the Developer perspective of the OpenShift Container Platform web console.

Environment labels

The environment application manifest must contain labels.openshift.gitops/environment and destination.namespace fields. You must set identical values for the <environment_name> variable and the name of the environment application manifest.

Specification of the environment application manifest

spec:
  labels:
    openshift.gitops/environment: <environment_name>
  destination:
    namespace: <environment_name>
...

Example of an environment application manifest

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: dev-env 1
  namespace: openshift-gitops
spec:
  labels:
    openshift.gitops/environment: dev-env
  destination:
    namespace: dev-env
...

1
The name of the environment application manifest. The value set is the same as the value of the <environment_name> variable.
Environment annotations

The environment namespace manifest must contain the annotations.app.openshift.io/vcs-uri and annotations.app.openshift.io/vcs-ref fields to specify the version controller code source of the application. You must set identical values for the <environment_name> variable and the name of the environment namespace manifest.

Specification of the environment namespace manifest

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    app.openshift.io/vcs-uri: <application_source_url>
    app.openshift.io/vcs-ref: <branch_reference>
  name: <environment_name> 1
...

1
The name of the environment namespace manifest. The value set is the same as the value of the <environment_name> variable.

Example of an environment namespace manifest

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    app.openshift.io/vcs-uri: https://example.com/<your_domain>/<your_gitops.git>
    app.openshift.io/vcs-ref: main
  labels:
    argocd.argoproj.io/managed-by: openshift-gitops
  name: dev-env
...

5.11.2. Checking health information

The Red Hat OpenShift GitOps Operator will install the GitOps backend service in the openshift-gitops namespace.

Prerequisites

  • The Red Hat OpenShift GitOps Operator is installed from OperatorHub.
  • Ensure that your applications are synchronized by Argo CD.

Procedure

  1. Click Environments under the Developer perspective. The Environments page shows the list of applications along with their Environment status.
  2. Hover over the icons under the Environment status column to see the synchronization status of all the environments.
  3. Click on the application name from the list to view the details of a specific application.
  4. In the Application environments page, if the Resources section under the Overview tab displays icons, hover over the icons to get status details.

    • A broken heart indicates that resource issues have degraded the application’s performance.
    • A yellow yield sign indicates that resource issues have delayed data about the application’s health.

5.12. Configuring SSO for Argo CD using Dex

After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with admin permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO).

Important

The spec.dex parameter in the ArgoCD CR is deprecated. In a future release of Red Hat OpenShift GitOps v1.9, configuring Dex using the spec.dex parameter in the ArgoCD CR is planned to be removed. Consider using the .spec.sso parameter instead.

5.12.1. Enabling the Dex OpenShift OAuth Connector

Dex uses the users and groups defined within OpenShift by checking the OAuth server provided by the platform. The following example shows the properties of Dex along with example configurations:

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example-argocd
  labels:
    example: openshift-oauth
spec:
  dex:
    openShiftOAuth: true 1
    groups:2
     - default
  rbac:3
    defaultPolicy: 'role:readonly'
    policy: |
      g, cluster-admins, role:admin
    scopes: '[groups]'
1
The openShiftOAuth property triggers the Operator to automatically configure the built-in OpenShift OAuth server when the value is set to true.
2
The groups property allows users of the specified group(s) to log in.
3
The RBAC policy property assigns the admin role in the Argo CD cluster to users in the OpenShift cluster-admins group.

5.12.1.1. Mapping users to specific roles

Argo CD cannot map users to specific roles if they have a direct ClusterRoleBinding role. You can manually change the role as role:admin on SSO through OpenShift.

Procedure

  1. Create a group named cluster-admins.

    $ oc adm groups new cluster-admins
  2. Add the user to the group.

    $ oc adm groups add-users cluster-admins USER
  3. Apply the cluster-admin ClusterRole to the group:

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admins

5.12.2. Disabling Dex

Dex is installed by default for all the Argo CD instances created by the Operator. You can configure Red Hat OpenShift GitOps to use Dex as the SSO authentication provider by setting the .spec.dex parameter.

Important

In Red Hat OpenShift GitOps v1.6.0, DISABLE_DEX is deprecated and is planned to be removed in Red Hat OpenShift GitOps v1.9.0. Consider using the .spec.sso.dex parameter instead. See "Enabling or disabling Dex using .spec.sso".

Procedure

  • Set the environmental variable DISABLE_DEX to true in the YAML resource of the Operator:

    ...
    spec:
      config:
        env:
        - name: DISABLE_DEX
          value: "true"
    ...

5.12.3. Enabling or disabling Dex using .spec.sso

You can configure Red Hat OpenShift GitOps to use Dex as its SSO authentication provider by setting the .spec.sso parameter.

Procedure

  1. To enable Dex, set the .spec.sso.provider: dex parameter in the YAML resource of the Operator:

    ...
    spec:
      sso:
        provider: dex
        dex:
          openShiftOAuth: true
    ...
  2. To disable dex, either remove the spec.sso element from the Argo CD custom resource, or specify a different SSO provider.

5.13. Configuring SSO for Argo CD using Keycloak

After the Red Hat OpenShift GitOps Operator is installed, Argo CD automatically creates a user with admin permissions. To manage multiple users, cluster administrators can use Argo CD to configure Single Sign-On (SSO).

Prerequisites

  • Red Hat SSO is installed on the cluster.
  • Red Hat OpenShift GitOps Operator is installed on the cluster.
  • Argo CD is installed on the cluster.

5.13.1. Configuring a new client in Keycloak

Dex is installed by default for all the Argo CD instances created by the Operator. However, you can delete the Dex configuration and add Keycloak instead to log in to Argo CD using your OpenShift credentials. Keycloak acts as an identity broker between Argo CD and OpenShift.

Procedure

To configure Keycloak, follow these steps:

  1. Delete the Dex configuration by removing the .spec.sso.dex parameter from the Argo CD custom resource (CR), and save the CR:

    dex:
        openShiftOAuth: true
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
  2. Set the value of the provider parameter to keycloak in the Argo CD CR.
  3. Configure Keycloak by performing one of the following steps:

    • For a secure connection, set the value of the rootCA parameter as shown in the following example:

      apiVersion: argoproj.io/v1alpha1
      kind: ArgoCD
      metadata:
        name: example-argocd
        labels:
          example: basic
      spec:
        sso:
          provider: keycloak
          keycloak:
            rootCA: "<PEM-encoded-root-certificate>" 1
        server:
          route:
            enabled: true
      1
      A custom certificate used to verify the Keycloak’s TLS certificate.

      The Operator reconciles changes in the .spec.keycloak.rootCA parameter and updates the oidc.config parameter with the PEM encoded root certificate in the argocd-cm configuration map.

    • For an insecure connection, leave the value of the rootCA parameter empty and use the oidc.tls.insecure.skip.verify parameter as shown below:

      apiVersion: argoproj.io/v1alpha1
      kind: ArgoCD
      metadata:
        name: example-argocd
        labels:
          example: basic
      spec:
        extraConfig:
          oidc.tls.insecure.skip.verify: "true"
        sso:
          provider: keycloak
          keycloak:
            rootCA: ""
Note

The Keycloak instance takes 2-3 minutes to install and run.

5.13.2. Logging in to Keycloak

Log in to the Keycloak console to manage identities or roles and define the permissions assigned to the various roles.

Prerequisites

  • The default configuration of Dex is removed.
  • Your Argo CD CR must be configured to use the Keycloak SSO provider.

Procedure

  1. Get the Keycloak route URL for login:

    $ oc -n argocd get route keycloak
    
    NAME        HOST/PORT                                                        PATH   SERVICES   PORT    TERMINATION   WILDCARD
    keycloak    keycloak-default.apps.ci-ln-******.origin-ci-int-aws.dev.**.com         keycloak   <all>    reencrypt     None
  2. Get the Keycloak pod name that stores the user name and password as environment variables:

    $ oc -n argocd get pods
    
    NAME                      READY   STATUS           RESTARTS   AGE
    keycloak-1-2sjcl           1/1    Running            0        45m
    1. Get the Keycloak user name:

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_USERNAME
      
      SSO_ADMIN_USERNAME=<username>
    2. Get the Keycloak password:

      $ oc -n argocd exec keycloak-1-2sjcl -- "env" | grep SSO_ADMIN_PASSWORD
      
      SSO_ADMIN_PASSWORD=<password>
  3. On the login page, click LOG IN VIA KEYCLOAK.

    Note

    You only see the option LOGIN VIA KEYCLOAK after the Keycloak instance is ready.

  4. Click Login with OpenShift.

    Note

    Login using kubeadmin is not supported.

  5. Enter the OpenShift credentials to log in.
  6. Optional: By default, any user logged in to Argo CD has read-only access. You can manage the user level access by updating the argocd-rbac-cm config map:

    policy.csv:
    <name>, <email>, role:admin

5.13.3. Uninstalling Keycloak

You can delete the Keycloak resources and their relevant configurations by removing the SSO field from the Argo CD Custom Resource (CR) file. After you remove the SSO field, the values in the file look similar to the following:

  apiVersion: argoproj.io/v1alpha1
  kind: ArgoCD
  metadata:
    name: example-argocd
    labels:
      example: basic
  spec:
    server:
      route:
       enabled: true
Note

A Keycloak application created by using this method is currently not persistent. Additional configurations created in the Argo CD Keycloak realm are deleted when the server restarts.

5.14. Configuring Argo CD RBAC

By default, if you are logged into Argo CD using RHSSO, you are a read-only user. You can change and manage the user level access.

5.14.1. Configuring user level access

To manage and modify the user level access, configure the RBAC section in Argo CD custom resource.

Procedure

  • Edit the argocd Custom Resource:

    $ oc edit argocd [argocd-instance-name] -n [namespace]

    Output

    metadata
    ...
    ...
      rbac:
        policy: 'g, rbacsystem:cluster-admins, role:admin'
        scopes: '[groups]'

  • Add the policy configuration to the rbac section and add the name, email and the role of the user:

    metadata
    ...
    ...
    rbac:
        policy: <name>, <email>, role:<admin>
        scopes: '[groups]'
Note

Currently, RHSSO cannot read the group information of Red Hat OpenShift GitOps users. Therefore, configure the RBAC at the user level.

5.14.2. Modifying RHSSO resource requests/limits

By default, the RHSSO container is created with resource requests and limitations. You can change and manage the resource requests.

ResourceRequestsLimits

CPU

500

1000m

Memory

512 Mi

1024 Mi

Procedure

Modify the default resource requirements patching the Argo CD CR:

$ oc -n openshift-gitops patch argocd openshift-gitops --type='json' -p='[{"op": "add", "path": "/spec/sso", "value": {"provider": "keycloak", "resources": {"requests": {"cpu": "512m", "memory": "512Mi"}, "limits": {"cpu": "1024m", "memory": "1024Mi"}} }}]'
Note

RHSSO created by the Red Hat OpenShift GitOps only persists the changes that are made by the operator. If the RHSSO restarts, any additional configuration created by the Admin in RHSSO is deleted.

5.15. Configuring resource quota or requests

With the Argo CD Custom Resource, you can create, update, and delete resource requests and limits for Argo CD workloads.

5.15.1. Configuring workloads with resource requests and limits

You can create Argo CD custom resource workloads with resource requests and limits. This is required when you want to deploy the Argo CD instance in a namespace that is configured with resource quotas.

The following Argo CD instance deploys the Argo CD workloads such as Application Controller, ApplicationSet Controller, Dex, Redis,Repo Server, and Server with resource requests and limits. You can also create the other workloads with resource requirements in the same manner.

apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
  name: example
spec:
  server:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 125m
        memory: 128Mi
    route:
      enabled: true
  applicationSet:
    resources:
      limits:
        cpu: '2'
        memory: 1Gi
      requests:
        cpu: 250m
        memory: 512Mi
  repo:
    resources:
      limits:
        cpu: '1'
        memory: 512Mi
      requests:
        cpu: 250m
        memory: 256Mi
  dex:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 250m
        memory: 128Mi
  redis:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 250m
        memory: 128Mi
  controller:
    resources:
      limits:
        cpu: '2'
        memory: 2Gi
      requests:
        cpu: 250m
        memory: 1Gi

5.15.2. Patching Argo CD instance to update the resource requirements

You can update the resource requirements for all or any of the workloads post installation.

Procedure

Update the Application Controller resource requests of an Argo CD instance in the Argo CD namespace.

oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/cpu", "value":"1"}]'

oc -n argocd patch argocd example --type='json' -p='[{"op": "replace", "path": "/spec/controller/resources/requests/memory", "value":"512Mi"}]'

5.15.3. Removing resource requests

You can also remove resource requirements for all or any of your workloads after installation.

Procedure

Remove the Application Controller resource requests of an Argo CD instance in the Argo CD namespace.

oc -n argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/cpu"}]'

oc -n argocd argocd patch argocd example --type='json' -p='[{"op": "remove", "path": "/spec/controller/resources/requests/memory"}]'

5.16. Monitoring Argo CD custom resource workloads

With Red Hat OpenShift GitOps, you can monitor the availability of Argo CD custom resource workloads for specific Argo CD instances. By monitoring Argo CD custom resource workloads, you have the latest information about the state of your Argo CD instances by enabling alerts for them. When the component workload pods such as application-controller, repo-server, or server of the corresponding Argo CD instance are unable to come up for certain reasons and there is a drift between the number of ready replicas and the number of desired replicas for a certain period of time, the Operator then triggers the alerts.

You can enable and disable the setting for monitoring Argo CD custom resource workloads.

Prerequisites

  • You have access to the cluster as a user with the cluster-admin role.
  • Red Hat OpenShift GitOps is installed in your cluster.
  • The monitoring stack is configured in your cluster in the openshift-monitoring project. In addition, the Argo CD instance is in a namespace that you can monitor through Prometheus.
  • The kube-state-metrics service is running in your cluster.
  • Optional: If you are enabling monitoring for an Argo CD instance already present in a user-defined project, ensure that the monitoring is enabled for user-defined projects in your cluster.

    Note

    If you want to enable monitoring for an Argo CD instance in a namespace that is not watched by the default openshift-monitoring stack, for example, any namespace that does not start with openshift-*, then you must enable user workload monitoring in your cluster. This action enables the monitoring stack to pick up the created PrometheusRule.

5.16.1. Enabling Monitoring for Argo CD custom resource workloads

By default, the monitoring configuration for Argo CD custom resource workloads is set to false.

With Red Hat OpenShift GitOps, you can enable workload monitoring for specific Argo CD instances. As a result, the Operator creates a PrometheusRule object that contains alert rules for all the workloads managed by the specific Argo CD instances. These alert rules trigger the firing of an alert when the replica count of the corresponding component has drifted from the desired state for a certain amount of time. The Operator will not overwrite the changes made to the PrometheusRule object by the users.

Procedure

  1. Set the .spec.monitoring.enabled field value to true on a given Argo CD instance:

    Example Argo CD custom resource

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: repo
    spec:
      ...
      monitoring:
        enabled: true
      ...

  2. Verify whether an alert rule is included in the PrometheusRule created by the Operator:

    Example alert rule

    apiVersion: monitoring.coreos.com/v1
    kind: PrometheusRule
    metadata:
      name: argocd-component-status-alert
      namespace: openshift-gitops
    spec:
      groups:
        - name: ArgoCDComponentStatus
          rules:
            ...
            - alert: ApplicationSetControllerNotReady 1
              annotations:
                message: >-
                  applicationSet controller deployment for Argo CD instance in
                  namespace "default" is not running
              expr: >-
                kube_statefulset_status_replicas{statefulset="openshift-gitops-application-controller statefulset",
                namespace="openshift-gitops"} !=
                kube_statefulset_status_replicas_ready{statefulset="openshift-gitops-application-controller statefulset",
                namespace="openshift-gitops"}
              for: 1m
              labels:
                severity: critical

    1
    Alert rule in the PrometheusRule that checks whether the workloads created by the Argo CD instances are running as expected.

5.16.2. Disabling Monitoring for Argo CD custom resource workloads

You can disable workload monitoring for specific Argo CD instances. Disabling workload monitoring deletes the created PrometheusRule.

Procedure

  • Set the .spec.monitoring.enabled field value to false on a given Argo CD instance:

    Example Argo CD custom resource

    apiVersion: argoproj.io/v1alpha1
    kind: ArgoCD
    metadata:
      name: example-argocd
      labels:
        example: repo
    spec:
      ...
      monitoring:
        enabled: false
      ...

5.16.3. Additional resources

5.17. Viewing Argo CD logs

You can view the Argo CD logs with the logging subsystem for Red Hat OpenShift. The logging subsystem visualizes the logs on a Kibana dashboard. The OpenShift Logging Operator enables logging with Argo CD by default.

5.17.1. Storing and retrieving Argo CD logs

You can use the Kibana dashboard to store and retrieve Argo CD logs.

Prerequisites

  • The Red Hat OpenShift GitOps Operator is installed in your cluster.
  • The logging subsystem for Red Hat OpenShift is installed with default configuration in your cluster.

Procedure

  1. In the OpenShift Container Platform web console, go to the red hat applications menu icon menu Observability Logging to view the Kibana dashboard.
  2. Create an index pattern.

    1. To display all the indices, define the index pattern as *, and click Next step.
    2. Select @timestamp for Time Filter field name.
    3. Click Create index pattern.
  3. In the navigation panel of the Kibana dashboard, click the Discover tab.
  4. Create a filter to retrieve logs for Argo CD. The following steps create a filter that retrieves logs for all the pods in the openshift-gitops namespace:

    1. Click Add a filter +.
    2. Select the kubernetes.namespace_name field.
    3. Select the is operator.
    4. Select the openshift-gitops value.
    5. Click Save.
  5. Optional: Add additional filters to narrow the search. For example, to retrieve logs for a particular pod, you can create another filter with kubernetes.pod_name as the field.
  6. View the filtered Argo CD logs in the Kibana dashboard.

5.17.2. Additional resources

5.18. Running GitOps control plane workloads on infrastructure nodes

You can use infrastructure nodes to prevent additional billing cost against subscription counts.

You can use the OpenShift Container Platform to run certain workloads on infrastructure nodes installed by the Red Hat OpenShift GitOps Operator. This comprises the workloads that are installed by the Red Hat OpenShift GitOps Operator by default in the openshift-gitops namespace, including the default Argo CD instance in that namespace.

Note

Any other Argo CD instances installed to user namespaces are not eligible to run on infrastructure nodes.

5.18.1. Moving GitOps workloads to infrastructure nodes

You can move the default workloads installed by the Red Hat OpenShift GitOps to the infrastructure nodes. The workloads that can be moved are:

  • kam deployment
  • cluster deployment (backend service)
  • openshift-gitops-applicationset-controller deployment
  • openshift-gitops-dex-server deployment
  • openshift-gitops-redis deployment
  • openshift-gitops-redis-ha-haproxy deployment
  • openshift-gitops-repo-sever deployment
  • openshift-gitops-server deployment
  • openshift-gitops-application-controller statefulset
  • openshift-gitops-redis-server statefulset

Procedure

  1. Label existing nodes as infrastructure by running the following command:

    $ oc label node <node-name> node-role.kubernetes.io/infra=
  2. Edit the GitOpsService custom resource (CR) to add the infrastructure node selector:

    $ oc edit gitopsservice -n openshift-gitops
  3. In the GitOpsService CR file, add runOnInfra field to the spec section and set it to true. This field moves the workloads in openshift-gitops namespace to the infrastructure nodes:

    apiVersion: pipelines.openshift.io/v1alpha1
    kind: GitopsService
    metadata:
      name: cluster
    spec:
      runOnInfra: true
  4. Optional: Apply taints and isolate the workloads on infrastructure nodes and prevent other workloads from scheduling on these nodes.

    $ oc adm taint nodes -l node-role.kubernetes.io/infra
    infra=reserved:NoSchedule infra=reserved:NoExecute
  5. Optional: If you apply taints to the nodes, you can add tolerations in the GitOpsService CR:

    spec:
      runOnInfra: true
      tolerations:
      - effect: NoSchedule
        key: infra
        value: reserved
      - effect: NoExecute
        key: infra
        value: reserved

To verify that the workloads are scheduled on infrastructure nodes in the Red Hat OpenShift GitOps namespace, click any of the pod names and ensure that the Node selector and Tolerations have been added.

Note

Any manually added Node selectors and Tolerations in the default Argo CD CR will be overwritten by the toggle and the tolerations in the GitOpsService CR.

5.18.2. Additional resources

5.19. Sizing requirements for GitOps Operator

The sizing requirements page displays the sizing requirements for installing Red Hat OpenShift GitOps on OpenShift Container Platform. It also provides the sizing details for the default ArgoCD instance that is instantiated by the GitOps Operator.

5.19.1. Sizing requirements for GitOps

Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud-native applications. Through GitOps, you can define and configure the CPU and memory requirements of your application.

Every time you install the Red Hat OpenShift GitOps Operator, the resources on the namespace are installed within the defined limits. If the default installation does not set any limits or requests, the Operator fails within the namespace with quotas. Without enough resources, the cluster cannot schedule ArgoCD related pods. The following table details the resource requests and limits for the default workloads:

WorkloadCPU requestsCPU limitsMemory requestsMemory limits

argocd-application-controller

1

2

1024M

2048M

applicationset-controller

1

2

512M

1024M

argocd-server

0.125

0.5

128M

256M

argocd-repo-server

0.5

1

256M

1024M

argocd-redis

0.25

0.5

128M

256M

argocd-dex

0.25

0.5

128M

256M

HAProxy

0.25

0.5

128M

256M

Optionally, you can also use the ArgoCD custom resource with the oc command to see the specifics and modify them:

oc edit argocd <name of argo cd> -n namespace

5.20. Troubleshooting issues in Red Hat OpenShift GitOps

When working with Red Hat OpenShift GitOps, you might face issues related to performance, monitoring, configuration, and other aspects. This section helps you to understand those issues and provide solutions to resolve them.

5.20.1. Issue: Auto-reboot during Argo CD sync with machine configurations

In the Red Hat OpenShift Container Platform, nodes are updated automatically through the Red Hat OpenShift Machine Config Operator (MCO). A Machine Config Operator (MCO) is a custom resource that is used by the cluster to manage the complete life cycle of its nodes.

When an MCO resource is created or updated in a cluster, the MCO picks up the update, performs the necessary changes to the selected nodes, and restarts the nodes gracefully by cordoning, draining, and rebooting those nodes. It handles everything from the kernel to the kubelet.

However, interactions between the MCO and the GitOps workflow can introduce major performance issues and other undesired behaviors. This section shows how to make the MCO and the Argo CD GitOps orchestration tool work well together.

5.20.1.1. Solution: Enhance performance in machine configurations and Argo CD

When you are using a Machine Config Operator as part of a GitOps workflow, the following sequence can produce suboptimal performance:

  • Argo CD starts an automated sync job after a commit to the Git repository that contains application resources.
  • If Argo CD notices a new or an updated machine configuration while the sync operation is in process, MCO picks up the change to the machine configuration and starts rebooting the nodes to apply the change.
  • If a rebooting node in the cluster contains the Argo CD application controller, the application controller terminates, and the application sync is aborted.

As the MCO reboots the nodes in sequential order, and the Argo CD workloads can be rescheduled on each reboot, it can take some time for the sync to be completed. This results in an undefined behavior until the MCO has rebooted all nodes affected by the machine configurations within the sync.

5.20.2. Additional resources

Red Hat logoGithubRedditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita ilBlog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

© 2024 Red Hat, Inc.