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

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.

> In this blog, we will describe how Rafay Zero Trust Kubectl Access Proxy gives Argo CD a secure path to every cluster in the fleet, even when those clusters sit deep behind corporate firewalls.

## Least Privilege Developer Access for Kubernetes Clusters

In our [recent release in July](https://docs.rafay.co/releasenotes/2023/july/), we enhanced our [**zero trust kubectl**](https://docs.rafay.co/accessproxy/overview/) service to address the needs to **two completely different cohorts** of customers. At a high level, users of the Rafay Platform fall into two ends of the **access spectrum** when it comes to answering the following question.

> Should developers be allowed to view **[Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)?**. Should they be allowed to **exec into running containers/pods** for troubleshooting purposes?