[EKS] [request]: Add ability to set oidc options

[jaxxstorm]

Tell us about your request Using IAM for authentication is not always the most desirable solution. I'd like to be able to specify server side configuration, specifically for oidc authentication

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? When interacting with EKS clusters from non Amazon resources, having to create and specify access keys and secret keys can be cumbersome. We do this a lot at $work and because we can't specify an oidc configuration for the API server, we end up having to build our own clusters. Being able to set the following API flags on the api server:

• oidc-issuer-url
• oidc-client-id
• oidc-ca-file
• oidc-username-claim
• oidc-groups-claim

Would make this possible.

Are you currently working around this issue? We are building our clusters using kubeadm :(

Additional context This could be argued that it should be made possible to specify any API server flags, but I'd like to keep the scope smaller now

[Tokynet]

...Bueller? Any update or acknowledgment from AWS team would be appreciated.

[mhausenblas]

Any update or acknowledgment from AWS team would be appreciated.

I hear you. Lemme check back with the team and see if I can confirm something.

(PS: the 80s want their lines back ;)

[mikestef9]

Hey all, just moved status to "coming soon". One important note here, is that EKS will only support issuer URLs with a publicly signed CA certificate, and oidc-ca-file will not be a supported flag.

[alex-berger]

@mikestef9 Why is setting oidc-ca-file not supported, is there a technical reason or is it just not in scope for the first MVP? And which trust anchors (root CAs) will be used by the control plane to verify the oidc issuer's server certificate?

[degonzalezo]

Any news? Would like to start using this configuration as the current state via AWS SSO leads to undesired drifts when managing multiple cluster environments at scale.

[mercantiandrea]

any news?

[cdobbyn]

It's not a high priority for them. They seemed pretty dismissive of it and suggested kube-oidc-proxy. It's pretty debilitating for administrators to have to link this to IAM. This becomes ultra complicated when you're managing multiple tenants on multiple clusters whom may need access to subsets of namespaces, across a number of aws accounts.

It sounds like the kind of priority that will keep getting shifted down to the bottom of the priority list.

[Morriz]

I don't think AWS is interested in supporting other cloud users...out of the big cloud players, they seem to favor lock in the most...I am assuming they allow AWS Cognito via oidc?

[pierluigilenoci]

@Morriz Cognito via OIDC is already working but it is annoying because every time you have to go through tokens with very short expiration and through the CLI. And you need to change the cluster config deeply to integrate with AAD groups. :(

[Morriz]

@pierluigilenoci that is what I meant: they support their own (Cognito), but make it hard to use others (AAD).

[mikestef9]

Hey everyone, happy to announce EKS now supports OIDC compatible identity providers as an additional user authentication option! The launch blog below walks through using Cognito as an example, but you can use any compatible OIDC provider as long as the issuer URL is publicly available with a commercially signed CA.

• What's New
• Launch Blog
• EKS Documentation
• Kubernetes docs

[Freyert]

Does anyone have tips on troubleshooting this feature? The configuration is active, but when we submit a kubectl with a --token the audit log shows that the server did not populate the user field of the request.

The release blog shows the request should have a user field like so:

    "user": {
        "username": "test@example.com",
        "groups": [
            "gid:secret-reader",
            "system:authenticated"
        ]
    },

But our request always turn up like:

    "user": {
    },

And that's as far as I can get. I don't know of any other logs to look at to troubleshoot this issue.

---

It look like the apiserver handles these requests itself. Found these:

E0624 17:03:16.231600 9 authentication.go:63] "Unable to authenticate the request" err="[invalid bearer token, oidc: verify token: oidc: id token signed with unsupported algorithm, expected [\"RS256\"] got \"ES256\", unknown]"

🤞 that's the issue.

---

Update: it was and it works now. If you are also debugging this feature look at the apiserver log streams in cloudwatch.