search

Azure / AKS

Azure Kubernetes Service
https://azure.github.io/AKS/
1.93k stars 295 forks source link

Support OpenID Connect Tokens for Kube Auth #1767

Open frodopwns opened 3 years ago

frodopwns commented 3 years ago

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:

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 commented 3 years ago

Triage required from @Azure/aks-pm

TomGeske commented 3 years ago

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

reallydontask commented 3 years ago

@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 commented 3 years ago

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

reallydontask commented 3 years ago

thanks for confirming

ghost commented 3 years ago

Action required from @Azure/aks-pm

cre8minus1 commented 3 years ago

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

ghost commented 3 years ago

Issue needing attention of @Azure/aks-leads

villanub commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

mtiller commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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

thomas-maurice commented 2 years ago

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

HerrmannHinz commented 2 years ago

+1

UXabre commented 2 years ago

We also have a use-case for this, as we're using our own IDP, completely separate from AD. It would be great if we could pass a token from our API towards the kubernetes API to create resources (as this seems to be what is supported already by native kubernetes)

miwithro commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@xiaowanzizuibang

UXabre commented 2 years ago

Hi, I am correct to assume that https://github.com/Azure/AKS/issues/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 commented 2 years ago

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. https://github.com/Azure/AKS/issues/2861

atiasadir commented 2 years ago

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 commented 2 years ago

@atiasadir it is planned for summer.

Eugst commented 2 years ago

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

cre8minus1 commented 2 years ago

@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 commented 1 year ago

Any updates on this?

jgourmelen commented 1 year ago

Any update ?

CocoWang-wql commented 1 year ago

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 commented 1 year ago

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

szymonrychu commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

Is the solution still to use third party?

CocoWang-wql commented 1 year ago

Yep, it's still in the planning.

PlagueHO commented 8 months ago

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

cailyoung commented 8 months ago

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 commented 5 months ago

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 commented 3 months ago

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 commented 3 months ago

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

Cryptophobia commented 3 weeks ago

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 commented 3 weeks ago

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 https://github.com/Azure/AKS/issues/1767#issuecomment-2197499945, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACELYH4SUN3QUO34IH2RPDZJWZ5JAVCNFSM4PVUWPO2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJZG42DSOJZGQ2Q . You are receiving this because you commented.Message ID: @.***>