I run a central Argo CD instance in EKS using ApplicationSets to manage several EKS clusters over private networking. One additional cluster is in a separate account and cannot use the same private connectivity setup. Since VPN and Transit Gateway connectivity are not practical in this case, I'm considering exposing that cluster's Kubernetes API endpoint publicly while restricting access to the NAT egress IP used by Argo CD. How reasonable is this approach, and are there safer alternatives such as an access proxy or overlay network?
3 Answers
An access proxy may be a better fit than exposing the API directly. Tools such as Teleport or Tailscale can provide a private path between Argo CD and the cluster without requiring a full VPN or Transit Gateway connection. This still requires operating another component, but it reduces the Kubernetes API’s public attack surface.
If the private networking options are truly unavailable, the IP restriction is a defensible short-term solution, but it is not equivalent to private connectivity. Anyone who can originate traffic from an allowed NAT address may still reach the API, and a future vulnerability in the public endpoint could bypass the comfort of the allowlist. I’d use it only with dedicated egress, strong auditing, and a plan to replace it later.
A public endpoint with a very narrow CIDR allowlist is the usual compromise when private connectivity is unavailable. Limit it to the stable NAT egress IPs used only by Argo CD, rather than a shared office or general-purpose range. If possible, keep the private endpoint enabled as well. Treat the public exposure as temporary, monitor changes to the allowlist, and review the cluster’s authentication and authorization bindings carefully.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures