[EKS] [request]: Support OIDC provider inside VPC (private ip address)

[lel-war]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Tell us about your request What do you want us to build? Ability to use an internal OICD provider that is private (only public supported now)

Which service(s) is this request for? EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Currently, only public OICD providers are supported, nonetheless, sometime organizations have internal OID providers that are only reachable inside de VPC. Since controlplane is outside the VPC, it cannot reach the internal OIDC.

Are you currently working around this issue? I tried using a proxy inside the cluster, but did not work.

Additional context Not that I can think of.

Attachments If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

[posquit0]

I'm having the same issue and so need PrivateLink support for oidc.eks.${region}.amazonaws.com.

I was happy to hear the news of EKS PrivateLink support, but I confirmed that it was difficult to use yet in an environment with limited egress internet traffic due to the lack of support for OIDC domains.

[keivinonline]

Issue: I encountered this issue when I enabled com.amazonaws.ap-southeast-1.eks VPC endpoint and was not able to resolve the DNS oidc.eks.${region}.amazonaws.com.

Workaround: Toggle Private DNS names enabled to false for the EKS VPC endpoint. Alternatively, removing the EKS vpc endpoint if not in use at all.

End result: EKS API endpoint was kept private but OIDC endpoint is done via public route as only public (DNS and route) is supported for that currently.

[mikestef9]

@keivinonline That is actually a separate issue. This issue is talking about support for resolving private external OIDC providers for cluster authentication. You are encountering an issue with behavior between PrivateLink and the EKS cluster OIDC endpoint. Could you open a separate issue for this?

[heggenu]

@mikestef9 @posquit0 @keivinonline - I have created a new issue for OIDC Support for Privatelink EKS VPC Endpoint

[rluan]

We have implemented an OIDC provider on top of DEX+LDAP, hosted on a private EKS workloads and exposed the DEX URL to public access with ALB. We are looking for a private solutions from security concerns. At least we need the EKS source IP addresses to be fixed ranges and be able to get , to set with SG ingress rules.

[alfredkrohmer]

For what it's worth: we are successfully using Dex as an IDP for EKS clusters (Dex pods in the same cluster, fronted by an internal ALB with a publicly resolvable DNS name (pointing to the internal VPC IPs) in the same VPC as the cluster) and got confirmation from AWS support that this is a supported scenario.

[vivekgkwd]

Hi

I am facing the same issue In my case I have my Dex IdP in a different VPC and it is peered with the control plane VPC But when I create an internal load balancer for dex , I get an error saying unauthorised Where as when I create a internet-facing load balancer for dex, I am able to login

Control plane logs:

E0219 16:06:31.424942 9 oidc.go:335] oidc authenticator: initializing plugin: Get "https://#######/.well-known/openid-configuration": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

[alfredkrohmer]

@vivekgkwd I think this is only supposed to work if the IDP is in the same VPC as the cluster.

[rluan]

@alfredkrohmer Thanks! It works! Deployed dex and authenticator under the same EKS cluster Deployed both public and internal ALBs in front of nodes and use internal one to forward traffic to dex pods. Just made the dex public DNS (rt53) point to the internal ALB and rebuild the OIDC associations, everything works smoothly!

EKS 1.29

helm list -n dex NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION dex dex 1 2024-03-13 02:35:02.779077055 +0000 UTC deployed dex-0.15.3 2.37.0 dex-k8s-authenticator dex 1 2024-03-13 02:35:05.859718857 +0000 UTC deployed dex-k8s-authenticator-0.0.2 1.4.0

[changhyuni]

We need this feature We want to be able to request normally even if the IDP has a private domain.

[mikestef9]

Adding some clarification here. Not the entire OIDC provider needs to be public to work with EKS. Only two particular URLs need to be publicly accessible, everything else can be private.

https://<domain\>/realms/\<realm\>/.well-known/openid-configuration
https://<domain\>/realms/\<realm\>/protocol/openid-connect/certs

The first URL is for OIDC Discovery.

The second URL is to get public signing keys. This url is also referred to as jwks_uri or JSON Web Key Set (JWKS) endpoint. This URI is discovered using the discovery URL. The actual url path will vary based on the implementation.