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

Feature Request: azurerm_service_principal #16

Closed
hashibot opened this issue Jun 13, 2017 · 15 comments · Fixed by #1564
Closed

Feature Request: azurerm_service_principal #16

hashibot opened this issue Jun 13, 2017 · 15 comments · Fixed by #1564

Comments

@hashibot
Copy link

This issue was originally opened by @colemickens as hashicorp/terraform#8094. It was migrated here as part of the provider split. The original body of the issue is below.


Feature request: Support creating AAD users and assigning RBAC roles.

Scenario: I want to automate creating Kubernetes clusters for Azure. We're doing this currently with Terraform + Ansible. It currently requires the user to provision a service account for the cluster manually and then feed those credentials into a config file that is used in a template_file data resource and then ultimately pushed into the VM and consumed by Ansible.

If I could have an azurerm_aad_serviceprincipal then I could automatically provision new service accounts, without needing to do it out of band. (Currently I'm considering using a local-exec provisioner to run azure-cli to create the SP and assign it permissions to the resource group that Terraform is deploying/creating).

Depends on: Azure/azure-sdk-for-go#378

@colemickens
Copy link

This is unblocked. The Go SDK for Azure has everything needed to manage lifecycle of AAD Apps/ServicePrincipals, as well as the RBAC Client.

@moritzheiber
Copy link

Is there any way this could be picked up in the near future? The inability to provision anything user/access related using the provider is a huge show-stopper for organizations wanting to provision their Azure subscriptions with code.

@tombuildsstuff tombuildsstuff changed the title azurerm: support provisioning AAD users with RBAC roles Feature Request: managing AzureAD users & RBAC roles Feb 22, 2018
@achandmsft achandmsft added this to the 1.4.0 milestone Mar 23, 2018
@achandmsft
Copy link
Contributor

@tombuildsstuff what's the status on this one?

@colemickens
Copy link

Does Explicit MSI not change the story here? I assume with explicit MSI I'll be able to create an SP via ARM rather than having to go to Graph?

That's what I had in mind when I filed this originally anyway. It also seems more fitting that "azure_rm" module for identity would use ARM/MSI rather than talking to AAD directly, maybe?

@tombuildsstuff tombuildsstuff removed this from the 1.4.0 milestone Apr 4, 2018
@achandmsft achandmsft modified the milestones: Soon, Future Apr 20, 2018
@achandmsft
Copy link
Contributor

@tombuildsstuff ping on status of this one?

@tombuildsstuff tombuildsstuff changed the title Feature Request: managing AzureAD users & RBAC roles Feature Request: azurerm_service_principal Apr 23, 2018
@tombuildsstuff
Copy link
Contributor

@achandmsft missed your ping here, given the above I'm re-scoping this to focus on Service Principals - which is available in the SDK - Role Assignments can already be managed via Terraform, so that should support this auth story (which can be used for both Users, Service Principals and Service Principals coming from MSI)

@colemickens
Copy link

Is there guidance from Azure on whether users should go through Graph or Explicit MSI for provisioning service account identities in Terraform-like workflows? @achandmsft ?

@achandmsft
Copy link
Contributor

@colemickens the guidance is to use Graph as Explicit MSI might not be integrated with all downstream services. However MSI is good to use where available such as with App Service for instance.

@colemickens
Copy link

I don't understand, isn't explicit MSI creating an AAD identity and app? That's how implict MSI works...

I thought explicit MSI was just being able to provision the service account and then directly re-use it?

Can we get docs for explicit MSI please?

@colemickens
Copy link

Ah, sorry, docs seem to be public under a slightly different name. :)

https://docs.microsoft.com/en-us/azure/active-directory/managed-service-identity/overview

A User Assigned Identity (public preview) is created as a standalone Azure resource. Through a create process, Azure creates an identity in the Azure AD tenant trusted by the subscription being used. After the identity is created, it can be assigned to one or more Azure service instances. The life cycle of a user assigned identity is managed separately from the life cycle of the Azure service instances it is assigned to.

I had wonder if maybe Explicit MSI would also expose SP/App as an ARM resource, but it seems this isn't the case. So I guess Terraform can only talk to Graph to provision identities. And then MSI only comes into play if you are using an MSI-enabled service and use a system-assigned identity or use a pre-provisioned Graph SP/App as a "system-assigned identity". Hopefully that's an accurate take on it.

@colemickens
Copy link

I don't know what the ARM API looks like, or if it exists, or if there are schemas/etc, but "identities" are now a first-rate concept support in the Azure CLI for EMSI scenarios. This is presumably what Terraform should be creating, rather than poking Graph directly.

@lawrencegripper
Copy link
Contributor

@tombuildsstuff Is this one up for grabs?

I have a project coming up which would benefit from the functionality so I can look at building this out in a PR. On a related note we also want to create Azure AD Users too so I would probably look to create a provider for that functionality too as they're pretty closely related.

@achandmsft
Copy link
Contributor

@tombuildsstuff what is the current status of this one?

@tombuildsstuff
Copy link
Contributor

@achandmsft this can be added once #1269 is merged (since it’s dependent on it)

@tombuildsstuff tombuildsstuff modified the milestones: Soon, 1.10.0 Jul 13, 2018
@tombuildsstuff tombuildsstuff self-assigned this Jul 13, 2018
@tombuildsstuff tombuildsstuff removed this from the 1.10.0 milestone Jul 16, 2018
@ghost
Copy link

ghost commented Mar 30, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.