# 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:

- Bespoke bastion hosts or VPN tunnels for every hop
- Long-lived bearer-token Secrets stashed in Argo’s namespace
- High latency between the GitOps engine and far-flung clusters, turning reconciliations into a slog

**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](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#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](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#why-this-beats-diy-solutions)

### [a. Zero-Trust Security End-to-End](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#zero-trust-security-end-to-end)

- No ingress, no VPNs, no bastions. Every connection is outbound TLS from cluster to Controller.
- JIT ServiceAccounts. Credentials are born when Argo touches the cluster and garbage-collected after idle timeout.
- Centralized policy. MFA, session length, and RBAC live in one place; disable a user once, revoke access everywhere.

### [b. Operational Simplicity](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#b-operational-simplicity)

- Fleet onboarding in minutes. Import a cluster, let the Operator self-register, hand Argo the endpoint—done.
- Unified audit trail. Every verb, human or automation, logged centrally with timestamp and user.
- Declarative everything. Feed kubeconfigs into ApplicationSets and scale to hundreds of clusters with a single YAML.

## [Security & Compliance Wins](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#security-compliance-wins)

### [**No CIDR whitelists**](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#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**](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#auditors-love-it)

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

### [**Zero-trust by design**](https://docs.rafay.co/blog/2025/08/06/gitops-without-borders-running-argo-cd-across-isolated-security-domains-with-rafays-zero-trust-kubectl/#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.