Chapter 1. Red Hat OpenShift GitOps release notes

Issued: 2026-10-07

For a complete list of security fixes and enhancements in this release, see the advisory:

Issued: 2026-09-30

The enhancements included in this release are documented in the following advisory:

With this update, the GitOps Console Plugin for OpenShift Container Platform is promoted from Technology Preview (TP) to General Availability (GA). You can view Argo CD, Argo CD Image Updater, and Argo Rollouts resources in the OpenShift Container Platform Console list and detailed views. You can edit or perform actions on these resources and promote or roll back Rollout revisions. For more information, see the Additional Resources section, which includes documentation for the GitOps Console Plugin.

GITOPS-10080

With this update, the ApplicationSets in any namespace feature is promoted from Technology Preview (TP) to General Availability (GA). You can create and manage Argo CD ApplicationSets in namespaces other than the control-plane namespace, supporting namespace-level isolation and multi-tenancy use cases. For more information, see the Additional Resources section, which includes documentation for managing ApplicationSets in non-control plane namespaces.

GITOPS-9787

With this update, the Red Hat OpenShift GitOps Console Plugin integrates Argo CD Image Updater into the OpenShift Container Platform Developer Console. You can view and manage Argo CD Image Updater resources directly in the Developer Console UI, providing a unified experience for managing GitOps resources.

GITOPS-8288

With this update, you can create multi-source Argo CD Applications directly from the New Application UI. You can add, configure, and remove multiple sources using the Add Source workflow. Each source includes its own configuration section for repository URL, revision, path or chart, and source-specific parameters. The Web UI generates the same spec.sources structure used by the CLI and declarative manifests, eliminating the need to use the CLI or manual YAML editing to combine multiple Git, Helm, or OCI sources.

If sources are removed until only one remains, the Application automatically converts back to the single-source spec.source format.

GITOPS-9407

With this update, you can enable the Argo CD Source Hydrator feature through the Red Hat OpenShift GitOps Operator. The Source Hydrator enables the rendered-manifest pattern, which lets you commit rendered manifests to a Git repository and synchronize them to the cluster. This feature separates the manifest generation process from the deployment process, providing better control over what gets deployed. For more information, see the Additional Resources section, which includes links to the upstream Argo CD Source Hydrator documentation.

GITOPS-9347

With this update, a productized container image of the GitOps Promoter is available. The Red Hat OpenShift GitOps Operator adds a field in the Argo CD custom resource (CR) to enable the GitOps Promoter controller and its API server on cluster-scoped instances. The GitOps Promoter enables environment promotions through GitOps, allowing you to manage progressive application rollouts across development, staging, and production environments. For more information, see the Additional Resources section, which includes links to the upstream GitOps Promoter documentation.

GITOPS-10243

With this update, all Red Hat OpenShift GitOps and Argo CD components adhere to the central TLS profile configuration in OpenShift Container Platform. This ensures consistent TLS settings across all components based on the cluster-wide security policy.

The Red Hat OpenShift GitOps components support the following TLS profile configurations:

With this update, Red Hat OpenShift GitOps automatically masks sensitive annotations, such as cleartext tokens in kubernetes.io/dockercfg Secrets, in the Argo CD web UI and CLI. This eliminates the need to manually configure resource.sensitive.mask.annotations and helps prevent sensitive information from being exposed.

GITOPS-10230

With this update, AppProject maintainers can configure requirements for source signing using the new Source Integrity declaration. It replaces the GPG signatureKeys option, with new and expanded features. Users are advised to migrate their signatureKeys configs to get ahead of their removal, and to start benefiting from the new features Source Integrity offers. The GPG verification can be applied to multi-source applications, use selective config on a per-repository basis, and optionally validate entire git repository history using so-called "strict" mode for GPG verification. For more information, see the Additional Resources section, which includes links to the upstream Argo CD Source Integrity documentation.

GITOPS-8846

With this update, Argo CD Image Updater introduces key-based image signature verification using Cosign. Administrators can configure signature verification rules in the ImageUpdater custom resource to verify image signatures before propagating updates to Git or Argo CD Applications. This capability helps verify the authenticity of container images and reduces the risk of deploying tampered images.

GITOPS-9963

With this update, Argo CD Image Updater requires webhook secrets for registered handlers and uses constant-time operations to validate secrets. These changes help prevent unauthorized webhook access and reduce the risk of timing side-channel vulnerabilities.

GITOPS-9948

With this update, Argo CD Image Updater supports applications that use the Argo CD Source Hydrator feature. The Image Updater can now determine the application source for Source Hydrator applications and perform image updates, resolving errors where applications failed with: Could not create write-back config for app <app-name>, skipping: application source is not defined.

GITOPS-9173

With this update, Argo CD Image Updater supports Plugin-type Argo CD applications in addition to Helm and Kustomize types. The Image Updater provides the following support for Plugin applications:

With this update, the Red Hat OpenShift GitOps Operator supports creating Kubernetes NetworkPolicy resources for the Argo CD Image Updater workload. The existing spec.networkPolicy field in the Argo CD custom resource (CR) controls whether the Operator creates NetworkPolicy resources. When the Image Updater and network policy are enabled in the Argo CD CR, the Operator reconciles NetworkPolicy resources that restrict inbound traffic to the ports that the Image Updater component exposes.

NetworkPolicy resources are enabled by default. To explicitly set NetworkPolicy and Image Updater configuration, use the following example in the Argo CD CR:

spec:
  networkPolicy:
    enabled: true
  imageUpdater:
    enabled: true

To disable NetworkPolicy resources, which removes all NetworkPolicy resources created by the Operator for the Argo CD instance, set the following configuration:

spec:
  networkPolicy:
    enabled: false

GITOPS-9092

With this update, Argo CD Image Updater avoids creating duplicate pull requests when using the pull request workflow. The Image Updater checks for existing open pull requests before creating a new one, ensuring only unique requests are created. Additionally, the Image Updater combines pull requests that share the same write-back target and include updates across multiple applications into a single pull request, reducing duplication.

GITOPS-10436

With this update, Argo CD Image Updater adds native webhook support for Alibaba Cloud Container Registry (ACR). A dedicated Aliyun ACR webhook handler enables the Image Updater controller to respond to image push events in real time, replacing the need for polling and reducing image update detection latency.

GITOPS-10000

With this update, the Red Hat OpenShift GitOps Operator supports configuring label selectors for Argo CD Agent components. Label selectors filter resources on the cluster, providing administrators with fine-grained control over resource management. Configure label selectors through the Argo CD custom resource (CR).

GITOPS-10307

With this update, the Argo CD Agent supports a TLS certificate blocklist. Administrators can block agents from connecting to the principal by adding client certificate fingerprints to the blocklist. This enhances security by providing fine-grained control over which agents can establish connections.

GITOPS-10334

With this update, you can disable the default ClusterRole for both the principal and agent components of the Argo CD Agent by using the DefaultClusterScopedRoleDisabled field. When you enable this on the Argo CD custom resource (CR), you must provide new roles through the PRINCIPAL_CLUSTER_ROLE and AGENT_CLUSTER_ROLE environment variables. This provides fine-grained control over RBAC permissions for Agent deployments.

GITOPS-9296

With this update, Hybrid architecture for Argo CD Agent is generally available (GA). This enables gradual adoption of the agent pull model without replacing the existing push-based architecture. Traditional applications continue to use the Application Controller on the control plane. Agent applications are synced to the workload clusters via the agent pull model. Both appear in the same UI. Label selectors and the argocd.argoproj.io/skip-reconcile annotation enforce isolation between them.

GITOPS-9738

With this update, you can apply custom annotations to the Dex and Redis pods through the Argo CD custom resource using .spec.sso.dex.annotations and .spec.redis.annotations. This brings these components in line with the annotation support already available for other Argo CD components and covers the Redis Deployment as well as the StatefulSet used in high-availability mode.

GITOPS-9794

Before this update, the Red Hat OpenShift GitOps Operator attempted to create or update roles in namespaces that were stuck in a Terminating state when spec.sourceNamespaces included such namespaces. Because Kubernetes rejects creating content in a terminating namespace, this caused the entire Argo CD reconciliation to fail and prevented the remaining source namespaces from being reconciled. With this update, the Red Hat OpenShift GitOps Operator skips source namespaces with a DeletionTimestamp, matching the existing behavior for managed namespaces. As a result, reconciliation succeeds for all healthy namespaces even when one is terminating.

GITOPS-10508

Before this update, DNS queries for short cluster hostnames triggered unnecessary upstream lookups, increasing the load on DNS infrastructure. With this update, Red Hat OpenShift GitOps components optimize DNS query behavior to minimize unnecessary upstream lookups, improving cluster performance.

GITOPS-9186

Before this update, when the Dex service account token expired, token rotation modified the Dex configuration, which triggered a restart of the Argo CD server and Dex processes. During each restart, internal resources were not fully released, causing a memory leak in the Argo CD server pod. Over time, memory consumption grew until the pod was terminated with an out-of-memory error. With this update, service account token rotation is handled on disk without modifying the Dex configuration, so the Argo CD server and Dex processes are no longer restarted. The Argo CD server pod no longer experiences memory growth caused by token rotation and users are no longer affected by out-of-memory restarts.

GITOPS-10364

Before this update, when the Dex service account token expired, the Dex process restarted and discarded all in-memory signing keys. As a result, verification of previously issued session tokens failed, the Argo CD server repeatedly re-initialized its authorization provider, and logged-in users were forced to re-authenticate. With this update, the Dex service account token is rotated on disk without restarting the Dex process. Users are no longer forced to re-authenticate when the token expires, and the Argo CD server no longer repeatedly re-initializes the authorization provider.

GITOPS-10429

The Argo CD Image Updater fails to commit updates for Applications that use spec.sourceHydrator instead of spec.source. When you use Helm write-back methods (helmvalues:./values.yaml custom target or the argocd write-back method), the Image Updater logs a success message but does not commit the updated image tag to Git. This issue occurs because the Image Updater’s internal code modifies a local copy of the source configuration for sourceHydrator Applications instead of the actual Application specification. As a result, the changes are discarded.

To work around this issue, add an empty tool block to spec.sourceHydrator.drySource that matches the tool type of the dry source.

Example for Helm-based dry source:

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  sourceHydrator:
    drySource:
      repoURL: https://example.com/repo.git
      path: charts/app
      targetRevision: HEAD
      helm: {}  # Add this empty block for Helm charts
    syncSource:
      targetBranch: env/dev
      path: charts/app

Example for Kustomize-based dry source:

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  sourceHydrator:
    drySource:
      repoURL: https://example.com/repo.git
      path: overlays/production
      targetRevision: HEAD
      kustomize: {}  # Add this empty block for Kustomize overlays
    syncSource:
      targetBranch: env/production
      path: overlays/production

GITOPS-11441

When you upgrade to Red Hat OpenShift GitOps 1.22 with Redis high availability (HA) enabled, the *-redis-ha-server-N pods enter an inconsistent state with liveness probe failures and eventually enter CrashLoopBackOff. A manual intervention is needed to enforce the pod spec update and resume normal operation.

To work around this issue, delete the affected Redis HA pods one by one and allow the StatefulSet to recreate them with the updated configuration:

$ oc delete pod <argocd-instance>-redis-ha-server-0 -n <namespace>

Wait for the pod to be recreated and reach the Running state before deleting the next pod. Repeat this process for all redis-ha-server pods in the StatefulSet.

GITOPS-11294

In Red Hat OpenShift GitOps 1.22, enabling spec.runOnInfra: true on the gitopsservice cluster CR applies infrastructure node scheduling by a namespace annotation rather than updating workload pod templates. Existing pods are not automatically rescheduled to infrastructure nodes when this setting is enabled.

To move existing workloads to infrastructure nodes after enabling spec.runOnInfra: true, manually restart the affected pods:

$ oc delete pod <pod-name> -n <namespace>

The recreated pods will be scheduled on infrastructure nodes according to the namespace annotation.

GITOPS-11499