Argo CD 3.5 Supply Chain Security: Enable Signed GitOps and Internal mTLS

Introduction

For years, GitOps had a quiet blind spot. Argo CD would faithfully reconcile whatever lived in your Git repository into the cluster, but it never asked the most basic security question: did the right person actually write this commit? If an attacker pushed a tampered manifest, or a compromised CI bot force-pushed an unsigned change, Argo CD would deploy it without hesitation. The trust boundary stopped at "the repo is the source of truth" and went no further.

Argo CD 3.5, released as a release candidate in June 2026, closes that gap. This is the release where GitOps grows up on supply-chain security. Two features stand out: Source Integrity validation, which refuses to sync unsigned or untrusted commits, and mTLS for the repo-server, which encrypts and authenticates traffic between Argo CD's own internal components. There is more in the release — Helm 4 support, a native ApplicationSet UI, impersonation and Source Hydrator both graduating to beta — but the security story is the headline, and it is the one platform teams should act on first.

This guide walks through what actually changed, how to turn each control on with copy-paste configuration, and how Argo CD's approach compares to Flux, Rancher Fleet, and Jenkins X. If you run GitOps in a regulated or multi-tenant environment, this is the upgrade you have been waiting for.

Why supply-chain security finally reached GitOps

The threat model is not hypothetical. A GitOps controller is, by design, a privileged actor: it has cluster-admin-level reach and it deploys whatever the repository tells it to. That makes the repository itself the highest-value target in the whole pipeline. Compromise the repo, or compromise a token that can write to it, and you own production — no need to touch the cluster API directly.

Before 3.5, Argo CD had no native answer to this. As InfoQ put it in their coverage of the release, "nothing in Argo CD prevented a compromised Git repository from silently deploying unsigned or tampered manifests." Teams bolted on external admission controllers or Git-provider branch protections, but there was no first-class, in-the-reconcile-loop check.

The second gap was internal. Communication between the repo-server and the other Argo CD components — the API server, the application controller, the ApplicationSet controller — was unencrypted. Most teams apply mTLS at the ingress and then forget that the software behind it is chattering in plaintext. In a shared cluster, that internal traffic is exactly the kind of lateral-movement surface a serious attacker looks for. If you have read our Kubernetes security best practices, you already know that "secure the perimeter and trust the inside" is the anti-pattern that keeps incident responders employed.

What makes 3.5 notable is who built it. The security features landed from engineers at Red Hat, Octopus Deploy, GoTo, and Intuit. Supply-chain hardening in GitOps is no longer one vendor's pet project; it is a cross-industry priority, which is a strong signal that this is where the ecosystem is heading.

Enabling Source Integrity: signed commits, enforced

Source Integrity is the feature that makes Argo CD verify that a Git source has been signed, and that the signature validates, before it syncs anything. Credit for the implementation goes to Oliver Gondza at Red Hat.

You enable it per-Application in the spec. The minimal form looks like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-api
  namespace: argocd
spec:
  project: payments
  source:
    repoURL: https://github.com/acme/payments-manifests.git
    targetRevision: main
    path: overlays/production
  sourceIntegrity:
    required: true
  destination:
    server: https://kubernetes.default.svc
    namespace: payments
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

The key line is sourceIntegrity.required: true. With that set, Argo CD will only hydrate and deploy manifests from commits carrying a valid signature. An unsigned commit — or one signed by a key Argo CD does not trust — stops at the door. The sync fails loudly instead of shipping quietly.

If you prefer to drive it imperatively, or you are scripting a rollout across many Applications, the CLI flag does the same thing:

argocd app set payments-api --source-integrity-required

For teams using the Source Hydrator (which separates "dry" un-rendered manifests from their hydrated output), 3.5 extends the same check to dry commits. That means integrity is verified at the very start of the hydration pipeline, before any rendering happens, so a tampered dry manifest never even gets processed. This dry-source support, contributed by Boostrack, is part of what pushed the Source Hydrator to beta.

A practical rollout tip: do not flip required: true across every Application on day one. Start with one non-critical workload, confirm your signing setup actually produces commits Argo CD trusts, and only then expand. A misconfigured trust store will happily block every sync, and discovering that during a production incident is not the lesson you want. This is the same canary discipline we advocate in the incident management runbook template: change one thing, watch it, then widen the blast radius on purpose.

Turning on repo-server mTLS

The second pillar is internal mTLS. In 3.5 the repo-server can require client certificates from every component that connects to it, so the API server, application controller, and ApplicationSet controller all have to prove who they are before they get a manifest rendered. Georgios Papapetrou at Octopus Deploy implemented it.

The pragmatic detail that makes this easy to adopt: for environments without custom certificates, the repo-server generates self-signed certs in memory. It does not depend on the filesystem, and it does not require you to stand up a full PKI just to get internal encryption working. That is a deliberate design choice to lower the barrier — you get authenticated internal traffic and better health-check behavior without a certificate-management project attached.

In a Helm-based install, you opt in through values on the repo-server component:

repoServer:
  extraArgs:
    - --repo-server-strict-tls
  env:
    - name: ARGOCD_REPO_SERVER_STRICT_TLS
      value: "true"

Once strict TLS is on, any component that connects without a valid client certificate is refused. For organizations that already run an internal CA — or a service mesh issuing workload identities — you can supply your own certificates instead of the in-memory self-signed ones and fold Argo CD's internal traffic into your existing trust hierarchy. Either way, the plaintext-between-components era is over.

Think of Source Integrity and mTLS as two ends of the same chain of custody. Source Integrity guarantees the manifest that enters Argo CD is trustworthy; mTLS guarantees it cannot be tampered with or spoofed while moving between Argo CD's own parts. Defense in depth, applied to your delivery system itself.

Multi-tenancy: impersonation and per-team ApplicationSets

Security is not only about cryptography; it is about who is allowed to do what. Two 3.5 changes matter here.

Impersonation graduated from alpha to beta. When you configure it through an AppProject or RBAC policy, Argo CD now assumes the correct user identity automatically for server-side operations — log streaming, resource deletion, and sync all execute with the right permissions instead of Argo CD's blanket service account. In a multi-tenant cluster, that is the difference between an audit log that says "argocd-server did it" and one that says "team-payments-ci did it." GoTo's Alexy Mantha contributed the server-operations work.

ApplicationSets in any namespace is now stable, contributed by Red Hat's Mangaal. Previously all ApplicationSets had to live in the Argo CD namespace, which forced central-team bottlenecks. Now each team can own its ApplicationSets in its own namespace with its own access controls — a real enabler for the self-service model that platform engineering keeps promising. Pair that with the new ApplicationSet concurrency controls (which cap how many applications get processed at once so you do not hammer the cluster or your Git provider's API) and large fleets become much safer to operate.

If you are still deciding how much autonomy to hand teams versus the platform group, our breakdown of SRE, DevOps, and platform engineering frames the trade-offs these features let you actually implement.

How Argo CD 3.5 compares to Flux, Fleet, and Jenkins X

Context matters. Some of what 3.5 ships as new has existed elsewhere, and some of it is genuinely ahead. Here is the honest comparison, drawn from InfoQ's analysis.

The nuance: Flux avoided the internal-mTLS problem by architecture — its controllers communicate through Kubernetes API objects rather than direct gRPC, so there is no unencrypted internal channel to secure in the first place. And Flux has offered native commit-signature verification longer than Argo CD, so on that specific point Argo CD is catching up, not leading. Where Argo CD 3.5 clearly pulls ahead is the ApplicationSet Preview experience and the breadth of enterprise auth integrations. Choose based on your architecture, not the changelog length.

A practical upgrade checklist

Before you roll 3.5 into production, work through this:

• Test the release candidate in a non-production cluster first — it is an RC, and the Argo team explicitly asked for community feedback before the final release.
• Stand up commit signing in CI before enabling sourceIntegrity.required, so trusted commits exist to sync.
• Enable Source Integrity on one low-risk Application, verify a signed commit syncs and an unsigned one is rejected, then expand.
• Decide on certificates for repo-server mTLS: in-memory self-signed for a quick win, or your own CA/mesh identity for a unified trust store.
• Audit your AppProjects and RBAC so impersonation maps to the identities you actually want in your audit logs.
• Review ApplicationSet concurrency limits if you manage hundreds of applications, to protect both the cluster and your Git provider's rate limits.

If you containerize your own tooling around this pipeline, the same supply-chain mindset applies to your images — our guide to Docker multi-stage builds covers keeping build provenance clean and attack surface small.

Conclusion

Argo CD 3.5 is a security release wearing a feature release's clothing. Helm 4 and the ApplicationSet UI will get the demos, but Source Integrity and repo-server mTLS are the changes that alter your risk posture. Together they extend the GitOps trust boundary from "the repo is the source of truth" to "the repo is the source of truth, and we can prove every commit and every internal hop is authentic."

That the work came from Red Hat, Octopus Deploy, GoTo, and Intuit tells you this is not a niche concern — it is where the whole GitOps ecosystem is converging. Signed, verifiable, internally-encrypted continuous delivery is becoming table stakes, not a differentiator.

Upgrade deliberately. Sign your commits, turn on Source Integrity for one workload, watch it, and widen from there. Your future incident responder — possibly you at 3 a.m. — will thank you for closing the door before someone walked through it.