I run a central ArgoCD instance in EKS and use ApplicationSets to manage several EKS clusters over private networking. One cluster is in a completely separate AWS account and doesn't fit into the existing network design. VPN and Transit Gateway connectivity aren't practical options in this setup, so I'm considering enabling that cluster's public Kubernetes API endpoint and restricting access to the NAT egress IP used by ArgoCD. This feels less than ideal, though. Is a tightly restricted public endpoint reasonable here, or are there better alternatives such as an access proxy or overlay network?
3 Answers
A public endpoint with a very tight CIDR allowlist is the usual compromise when private connectivity isn’t available. Limit it to stable, dedicated NAT egress IPs used only by ArgoCD rather than a shared office or general-purpose NAT range. If possible, enable both public and private endpoint access so workloads inside the VPC still have a private path. Treat the public endpoint as a temporary design, keep the allowlist updated when egress changes, and review Kubernetes authentication and authorization bindings carefully.
An access proxy or overlay network can avoid exposing the API directly. Tools such as Teleport or Tailscale can provide a private path between ArgoCD and the cluster without requiring a full site-to-site VPN or Transit Gateway. Whether that’s worth the added operational complexity depends on how important this cluster is and how long the cross-account arrangement will remain.
The main risk is that everyone sharing the approved NAT IP can reach the Kubernetes API, and a future control-plane vulnerability could make a public endpoint more dangerous. If you take this route, use dedicated egress, strong identity-based access, audit logging, and strict authorization. It’s workable, but it should be viewed as a compensating control rather than an ideal architecture.
Even a temporary overlay node can be easier to justify than permanently exposing the control plane. The important part is making sure ArgoCD connects through a stable, controlled path rather than relying on a broad shared egress address.