Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Use System Managed Identity OR User Managed Identity for AKSCluster #292

Open
2 tasks
Tracked by #164 ...
MMerzinger opened this issue Sep 18, 2021 · 4 comments
Open
2 tasks
Tracked by #164 ...
Assignees
Labels
enhancement New feature or request

Comments

@MMerzinger
Copy link

MMerzinger commented Sep 18, 2021

Hello everyone

What problem are you facing?

During my tests with Crossplane I figured out that the AKSCluster API implementation uses a self-managed Service Principal under the hood. This comes with the following drawbacks:

  • Credential rotation (currently every 5 years)
  • Requires the Service Principal that is used by Crossplane to have specific privileges on the Azure AD Graph API
  • Azure AD Graph API is deprecated, this issue addresses this topic

How could Crossplane help solve your problem?

I believe that using a System Assigned Managed Identity or User Managed Identity could solve these drawbacks:

  • No credential rotation - credentials are hidden under the hood of ARM
  • The Service Principal that is used by Crossplane does not need to have the privileges on Azure AD Graph API to manage other Service Principals - i.e. resulting in an easier usage of the azure provider

The drawback for this approach is that a change on existing cluster is required to move to a Managed Identity.

These are my thoughts on using Crossplane to deploy AKS clusters, so this is not really a feature request, but more of a discussion.

Looking forward to hear from you!

Related issues:

@MMerzinger MMerzinger added the enhancement New feature or request label Sep 18, 2021
@jbw976
Copy link
Member

jbw976 commented Dec 8, 2021

Thank you for suggesting this @MMerzinger - it's long been an annoyance that our AKS controller had to create a new service principal on the fly for the new AKS cluster to use when communicating to other Azure APIs. IIRC this was required way back when this controller was first coded, but it's great to see that there are some potential improvements here on the Azure side where this is no longer required.

This has potential to definitely improve the experience here and remove the need to have this extra permission at all. Thanks for this suggestion!

I wonder if the new provider-jet-azure already support this, maybe @ulucinar has some good insight into that?

@ulucinar
Copy link
Collaborator

Some further details associated with this issue are here:
https://docs.microsoft.com/en-us/azure/aks/use-managed-identity

@ulucinar
Copy link
Collaborator

ulucinar commented Mar 25, 2022

I wonder if the new provider-jet-azure already support this, maybe @ulucinar has some good insight into that?

Yes, with provider-jet-azure we support using system-assigned or user-assigned managed identities via specifying them with spec.forProvider.identity. And here's the relevant doc from Terraform registry:
https://registry.terraform.io/providers/hashicorp/azurerm/2.78.0/docs/resources/kubernetes_cluster#identity
(Hopefully we will have these docs become part of CRD docs with https://github.com/crossplane/crossplane/blob/99a70b193197dba4ef8c30d9e4fc6f34c154f893/design/one-pager-terrajet-metadata-extraction.md#goals :)

@ulucinar
Copy link
Collaborator

We had a discussion about this issue with @ezgidemirel. #330 adds support for using managed identities in AKS clusters. However, using service principals is out of scope of that PR. I've opened a separate issue for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants