Support OpenID Connect Tokens for Kube Auth

[frodopwns]

What happened:

Users would like to use the OpenID Connect functionality built into Kubernetes in order to authenticate using OIDC providers. Users are unable to set the parameters outlined in the Kubernetes documentation. https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens

Users submitted feedback seeking resolution:

• ApiServer options #10
• https://feedback.azure.com/forums/914020-azure-kubernetes-service-aks/suggestions/35100826-support-oidc-parameters

No updates and the issue was closed.

What you expected to happen:

Issues addressed either by solving the problem or an explanation of why it can't be done or when to expect it.

[ghost]

Triage required from @Azure/aks-pm

[TomGeske]

You can use AKS-managed AAD https://aka.ms/aks/managed-aad

[reallydontask]

@TomGeske

You can use AKS-managed AAD https://aka.ms/aks/managed-aad

I am, presumably, on the same boat as @frodopwns, namely not wanting to use AAD but a different OIDC provider, which is what the ticket relates to.

is this possible and if so how?

[TomGeske]

No, other OIDC provider are not supported at this point.

[reallydontask]

thanks for confirming

[ghost]

Action required from @Azure/aks-pm

[cre8minus1]

Plus 1 for this. EKS just added this https://aws.amazon.com/blogs/containers/introducing-oidc-identity-provider-authentication-amazon-eks/

[ghost]

Issue needing attention of @Azure/aks-leads

[villanub]

This is something we are looking to leverage for managing a large customer base. Any update on plans to support this? EKS has taken the lead and it would be good for AKS to catch up.

[starkers]

I was thinking about migrating from AWS to Azure and just found out AKS doesn't support something a vanilla k8s cluster does.. Zoinks :/

[miwithro]

We currently have:
https://docs.microsoft.com/en-us/azure/aks/use-azure-ad-pod-identity

We are developing V2 of the above implementation which is based on OIDC Federation support. Looking at a Private Preview in the end of Q2 2021.

[villanub]

Feel free to reach out to me to participate in the Private Preview, happy to work on this as it is a critical piece of our requirement for success.

[ryaneorth]

@miwithro and @villanub - thanks for your update on this new feature, but that doesn't seem to address the original ask raised for this issue. Does AKS plan to support OIDC authentication to the Kubernetes API server (similar to EKS)?

[starkers]

Yes, we just want to authorise users via an existing OIDC system, nothing fancy.. its vanilla kubernetes

[mtiller]

Just to add that for our internal bare metal clusters we already have this. Furthermore, I'd like all of our clusters to be able to use the same OIDC provider. I understand that if all I used was Azure and AAD, then the current functionality would make sense. But for people who run multiple clusters, it would be an absolute nightmare to require users of each cluster to be registered with independent identity providers for each one.

[rmt]

I'm not convinced that they understand what this ticket is asking for. This is about user identities, not pod or service identities.

In February this year, AWS EKS introduced the much requested feature. EKS allows you to "Associate (an OIDC) Identity Provider" with a cluster. To configure this, you provide an Issuer URL, Client ID, Username claim and Groups claim.

For example, https://oidc.mycompany.com/, myclientID, "username", and "groups". Kubernetes will regularly check https://oidc.mycompany.com/.well-known/openid-configuration, and from then on it will trust the username & groups in any valid JWT tokens from that provider.

The reason that this is important is that many companies manage Kubernetes clusters across multiple datacenters and clouds, and OpenID connect is the standard way to do this, helping to maintain consistent auth & audit trail.

[keymon]

We would love to have this feature too. EKS has it and it is a game changer, to allow us to better integrate the developer workflows for our services and k8s in the same manner, without having to provide cloud credentials.

[dstockton]

GKE also has this now - https://cloud.google.com/kubernetes-engine/docs/how-to/oidc

[thomas-maurice]

Is there any updates on this ? This would be a tremendously useful feature to have.

[miwithro]

We have it on our plans to tackle this feature early this quarter. Once we have a firm plan, I will update this issue.

[szymonrychu]

I'm also stuck with this, other major providers AWS/GCP allow for this to happen. Currently I'm working in multicloud environment and NEED to centralize authorization around kuberneteses.
Is there any workaround for this?

[miwithro]

@xiaowanzizuibang

[UXabre]

Hi, I am correct to assume that #2861 is the follow up for this issue as it states to support external IDPs (and seems to be in the commited swimlane 🎉🎉🎉)? Perhaps this current issue can then be closed as it deals with the same topic and it would help people who are "waiting" for this feature to know that it is actually seemingly moving forward?

[CocoWang-wql]

Currently AKS supports Azure AD as the identity provider for authentication. The External identity provider feature is in planning and we would post here once there is any update. #2861

[atiasadir]

We have it on our plans to tackle this feature early this quarter. Once we have a firm plan, I will update this issue.

@miwithro Any update regarding ETA ?

@amirschw

[miwithro]

@atiasadir it is planned for summer.

[Eugst]

@miwithro it's a middle of summer! how things are going there? :)

[cre8minus1]

@miwithro it's a middle of summer! how things are going there? :)

+1 - We are looking to standardize on OIDC across on-prem and cloud, this will really help.

[ashmuck]

Any updates on this?

[jgourmelen]

Any update ?

[CocoWang-wql]

Can you try to use Pinniped project can meet your requirements? (kindly replace the GKE steps with AKS equivalent steps)
If not, pls feel free to talk about it with me. In case you don't want to expose internal info here, you can open an Azure support ticket and attach the GitHub link, then ask the support engineer to loop me in the cal. Thank you all for your feedback.

[CocoWang-wql]

Link the duplicated issue here which contains the complete conversation. Pls feel free to refer to it.

[szymonrychu]

@CocoWang-wql so the official answer is that, in Azure it's necessary to implement and maintain solution based on external operator in order to use otherwise kubernetes'es built in functionality?

Does it mean, that Azure will offer refunds for resources lost in the process (CPU, mem, monitoring, man-hours, etc)? I mean- it's an additional cost to handle such external entities in the cluster.

[miwithro]

@szymonrychu

The Pinniped approach is currently the only option for AKS users who need this functionality.  It requires an extra "agent" on clusters, exactly in the same way as GKE's officially supported solution does.  Since Pinniped is not an officially supported solution, customers are responsible for its maintenance should they choose to use it. Many AKS features require extra pods to run on worker nodes, and, for now, the proposed approach requires that as well.  Customers are always responsible for the billing associated with these nodes.

[szymonrychu]

@miwithro yup, I can confirm, that GKE's official guide asks to deploy an operator to managed kubernetes so from that standpoint, the solution is not that different. https://cloud.google.com/kubernetes-engine/docs/how-to/oidc

What strikes me most is the difference in approach:

1. In AWS the functionality is embodied into the management of the EKS and doesn't require anything extra to be deployed (this is something I would expect)
2. In GKE it's expected to install an operator, but as I understand (e.g. based on name of the CRD), it's Google's "extension" documented, developed, tested and supported for their platform on their platform.
3. Finally in Azure, it's expected to install 3rd party's solution and be dependent on their support, good will and or payment plan.

I just think, that after all this time waiting it's not the real solution we all been expecting- especially from 2nd biggest cloud provider (or the biggest one- depends on whom you would ask).

[aslamkhan-atlan]

Is the solution still to use third party?

[CocoWang-wql]

Yep, it's still in the planning.

[PlagueHO]

Are there any updates on this? It will allow our partners to simplify and improve auth into AKS.

[cailyoung]

Hi there, with Hashicorp's recent announcement of dynamic credentials for the Kubernetes provider this would be very very useful to have as a feature on our AKS clusters.

[PlagueHO]

Hi @CocoWang-wql - I'm keen to determine if this is still being planned? It is preventing 3rd party providers from implementing OIDC support for auth to AKS.

[gigabytte]

This issue is getting very long in the tooth, any updates? Are we to assume this will just work in k8s 1.30 when released for AKS?

[CocoWang-wql]

Yes, we start the design work this month. Hope to deliver it soon.

[Cryptophobia]

We waited for four years for this feature. We can wait a little longer!

At this point, it is safe to say that we probably may need to re-evaluate if anyone really needs this feature. In fact, lots of the users here may have decided that it is no longer required for them. Based on waterfall project management, if the water falls for 4 years, the requirements pool has been muddied.

Are you sure you really want to support something that is supposed to be native to Kubernetes clusters? You should know better.

Let's have a public survey at the next AKS conference on who actually needs this.

/close

[keymon]

We need it. We can live without it, and we have workarounds... but I would rather have this feature and have the same auth than EKS. -- Héctor Rivas

…

On Fri, Jun 28, 2024 at 8:24 PM AMO ❤️⛺✨ ***@***.***> wrote: We waited for four years for this feature. We can wait a little more! At this point, it is safe to say that we probably may need to re-evaluate if anyone really needs this. In fact, lots of the users here may have decided that it is no longer required for them. Are you sure you really want to support something that is supposed to be native to Kubernetes clusters? You should know better. Let's have a public survey at the next AKS conference on who actually needs this. /close — Reply to this email directly, view it on GitHub <#1767 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACELYH4SUN3QUO34IH2RPDZJWZ5JAVCNFSM4PVUWPO2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJZG42DSOJZGQ2Q> . You are receiving this because you commented.Message ID: ***@***.***>