GitOps Without Borders: Running Argo CD Across Isolated Security Domains with Rafay’s Zero-Trust Kubectl

GitOps Without Borders: Running Argo CD Across Isolated Security Domains with Rafay’s Zero-Trust Kubectl

August 6, 2025

Modern enterprises rarely run applications in a single cluster. A production fleet might include on-prem clusters in Singapore and London, a regulated environment in AWS us-east-1, and a developer sandbox in someone’s laptop. GitOps with Argo CD is the natural way to keep all those clusters in the desired state—but the moment clusters live in different security domains (fire-walled data centers, private VPCs, or even air-gapped networks) the simple argocd cluster add story breaks down:

Rafay’s Zero-Trust Kubectl Access (ZTKA) solves all three problems in one stroke. By front-loading the connection with a hardened Kube API Access Proxy—and issuing just-in-time (JIT), short-lived ServiceAccounts inside every cluster.

How the Pieces Fit Together

Component Role
Rafay Controller + Kubectl Proxy Central brain that enforces RBAC, issues client certs, and audits every kubectl call.
Rafay Kubernetes Operator Rafay pod running in each cluster. All traffic is outbound-only to the Controller— no inbound ports, no VPNs.
Argo CD GitOps engine deployed inside your enterprise network (or one of the clusters). It talks only to ZTKA endpoints.

End Result is that Argo CD remains blissfully ignorant of cluster IPs, firewall rules, or cloud-provider auth quirks. Each cluster looks like a single TLS endpoint.

Step-by-Step Integration

Assumption: You already have ArgoCD running somewhere on a trusted network.

Step Command/Action Why it matters
1 · Create an “automation” user in Rafay Console → Users → Add User → role GitOps Least-privilege identity and clean audit trail.
2 · Generate kubeconfig for each cluster rctl kubeconfig download Contains short-lived kubeconfig
3 · Store as Argo Secret kubectl -n argocd create secret generic clusters Argo never sees bearer tokens; it re-authenticates through the Kubectl proxy.
4 · Register cluster argocd cluster add --kubeconfig file Works like normal cluster add, but no direct network reachability is required.
5 · Repeat for every cluster Keep secret and cluster names consistent with your Git repo taxonomy. Simplifies ApplicationSet cluster generators.

Why This Beats DIY Solutions

a. Zero-Trust Security End-to-End

b. Operational Simplicity

Security & Compliance Wins

No CIDR whitelists

API servers can stay on private IPs; only the Rafay Kubernetes Operator needs outbound port 443 to the Rafay Controller.

Auditors love it

Authentication events and kubectl verbs are query-able in a single console.

Zero-trust by design

Mutual TLS, per-request authorization, and short-lived credentials map neatly to NIST 800-207 and SOC 2 controls.

Conclusion

GitOps promises hands-free, reproducible deployments—but only if your delivery system can reach every cluster securely and performantly. By integrating Argo CD with Rafay’s Zero-Trust Kubectl, you get the following benefits:

  1. Locked-down access with short-lived, centrally managed credentials
  2. One-click onboarding across clouds and data centers
  3. Near-local latency thanks to regional proxies
  4. Complete observability of every change, human or automated

The net result is a simpler, safer, and faster multi-cluster GitOps pipeline—so your developers ship features instead of babysitting tunnels and tokens.

Are you ready to try it? Spin up a free Rafay Org, point your ArgoCD at the ZTKA endpoint of a dev cluster, and watch your first Application sync in seconds—no firewall tickets required.