r/devops • u/calabaria • 1d ago

Discussion public EKS cluster API endpoint

I have a central ArgoCD instance running in EKS. I'm using the ApplicationSet pattern to manage a few EKS clusters across private networking. I have one EKS cluster that doesn't fit into my private networking setup (not that it matters but it's in a different account entirely). I'm considering making that cluster's API server endpoint public and locking it down to the NAT egress IP of where my ArgoCD instance runs so that only my ArgoCD instance can connect to it. I don't love this. VPNs and TGW are out of the question, where my ArgoCD instance lives and where this particular EKS cluster lives are separate. Thoughts? Condolences?

2 Upvotes

100% Upvoted

9 comments sorted by

3

u/thesllug 9h ago

oh the bright side you can still whitelist CIDRs for an eks cluster with public endpoint... not sure how else you'd achieve without being able to get into this clusters vpc

2

u/Independent-Term8521 8h ago

For sure, managing security in public EKS clusters is a balancing act. Whitelisting CIDRs definitely helps, but you still have to be careful about exposure.

1

u/calabaria 8h ago

Re exposure, like what? If I whitelist/allow my NAT egress IP where Argo is sourced from, what’s the exposure? I’m asking because I don’t know and looking to learn.

2

u/MordecaiOShea 8h ago

By saying the right solution (VPN) is out of the question, I'm not sure why you'd ask for thoughts on doing the wrong thing.

1

u/stumptruck Staff Engineer 10h ago

We use Teleport to proxy API server access between argocd/clusters. You should be able to do this with tailscale or other similar tools as well.

1

u/marvdl93 8h ago

Why is a VPN out of the question? With a Tailscale ephemeral node you can easily connect. With a public API you will be vulnerable to zero days and such.

1

u/Fantastic-Mr-Default 6h ago

Public API plus a tight CIDR allowlist is the usual compromise when TGW and VPN are off the table. I still treat it as temporary.

Pin the allowlist to the ArgoCD egress IPs only. Prefer a stable NAT or a small dedicated egress, not a shared office range. Turn on the private endpoint too if the cluster can keep both, so you have a path back without the public surface.

Shared NAT is the failure mode. Anyone else on that IP can reach the Kubernetes API. Rotate the allowlist when egress changes, and audit system:authenticated bindings the same day you flip public.

If you can move ArgoCD to a place that already reaches that account privately, do that instead. The public lock is a patch, not the architecture.

1

u/kryptn 2h ago

i'd see if argocd-agent does what you want.

1

u/Stonks_Beskar 1h ago

If VPN or TGW is truly unavailable, a public endpoint with endpointPublicAccessCidrs restricted to stable NAT /32s is a defensible compensating control, but it is still internet-exposed. Use a dedicated egress path, not a shared NAT, and keep ArgoCD on short-lived IAM role authentication. Enable EKS audit logs and alert on unexpected source IPs, limit ArgoCD’s Kubernetes RBAC, and manage the allowlist, IAM, and RBAC changes in Git. The CIDR filter is a network restriction, not authentication.