Is a Public EKS API Endpoint Safe with a Strict IP Allowlist?
Asked by
MellowKite42
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?
Answers
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.
Reply to this answer
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.
Reply to this answer
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.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions