×

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.

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

OpenShift GitOps Component Versions OpenShift Versions

Version

kam

Helm

Kustomize

Argo CD

ApplicationSet

Dex

RH SSO

Notifications Controller

1.7.0

0.0.46 TP

3.10.0 GA

4.5.7 GA

2.5.4 GA

2.4.5 GA

2.35.1 GA

7.5.1 GA

2.4.5 TP

4.8-4.11

1.6.0

0.0.46 TP

3.8.1 GA

4.4.1 GA

2.4.5 GA

2.4.5 GA

2.30.3 GA

7.5.1 GA

2.4.5 TP

4.8-4.10

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.10

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.9

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

  • "kam" is an abbreviation for Red Hat OpenShift GitOps Application Manager (kam).

  • "RH SSO" is an abbreviation for Red Hat SSO.

  • The Environments page in the Developer perspective of the OpenShift Container Platform web console is also in Technology Preview.

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.

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.8, 4.9, 4.10, and 4.11.

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:

    Subkey Key form Mapped 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

    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 feature on the Developer tab 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, applications can be created in any namespace in the same cluster and still managed by the same control-plane‚Äôs ArgoCD instance. This is done by adding a new label argocd.argoproj.io/managed-by-cluster-argocd to the namespace added in spec.sourceNamespaces of the Argo CD custom resource. GITOPS-2341

Argo CD Applications 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 https://access.redhat.com/support/offerings/techpreview/.

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,