-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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] 2.0 - Azure Active Directory #2322
Comments
I think it makes a lot of sense and it was always what I expected to be the design. |
This would be very nice. We already experimented with this in our organization, a dedicated Azure AD provider for managing users, groups and application roles. Also because Terraform is "infrastructure as code" tool, it very much felt like the Azue AD resources that will be accepted in the AzureRM provider would mostly be to support building of infrastructure (like the data sources for users and groups). Having a dedicated Azure AD provider perhaps means that it will be alot easier to add other functionality and resources that is not related to creating resources in Azure subscriptions. |
I would be very pleased to see a separate provider and think this is a better strategic solution than what I was considering. Thank you |
LOVE this. We're pretty heavily invested into AzureAD, but less so into Azure itself. They also seem to have different "cadences". MS is investing heavily into the identity side of things on AzureAD, and the functionality keeps evolving quickly. |
This sounds a good idea, it may be worth thinking about how terraform providers AzureAD and AzureRM could be used in combination - for example, build a virtual machine including a managed identity using AzureRM, use AzureAD to assign a role with specific permissions to the managed identity service principal, grant rights to perform actions on other Azure resources such as Azure Key Vault or Azure SQL. |
I like the idea as well. Let me know if I can help. I can't wait as I already have a working resource for azuread_domain_services ready :-) |
@tombuildsstuff Is there an estimated timeline or something similar for this project? I'm just wondering whether I should start building new templates based on the Azure AD resources available in this provider now, or rather wait for 2.0 and the new Azure AD provider. The decision hangs at least a little on whether I'll wait days, weeks or months on the new provider (days would be awesome, weeks is more realistic, and months means I can use "ye olde ways" without feeling bad about the upcoming migration). |
@tomasaschan so @katbyte is taking a look into this - but I'd expect this work will start on this new provider this side of the new year. At this time I'd suggest using the resources in this provider for the moment - they're going to exist in this Provider until 2.0 so the intention is that it's possible to use the resources in both for a little while :) Thanks! |
that makes a lot of sense. Also Azure AD is extending with new capabilities like Privilege Identity Management (PIM), Conditional access policies, identity risk based profiles. I can see that coming over time under an azuread resource provider. It could be an opportunity to also add more azure ad tenant configuration capabilities like custom domain, configure the guest policies, notification... |
I think it is a great idea as well. There is a lot of things in Azure AD as well. We have enough Azure AD resources that it almost takes up an entire persons time. I haven't been able to do much with Terraform in AzureAD yet (app registrations and service principals). |
hey @perbergland @joakimhellum-in @tiwood @tomasaschan @LaurentLesle @midacts @paulschwarzenberger @rayterrill Just to let you know that the Azure Active DIrectory resources have been split out into the new AzureAD Provider, which is now available and lives it's own repository (nice work @katbyte 🥇). The initial release (v0.1.0) contains the existing data sources/resources from this repository - and there'll be a migration guide coming out as a part of the next release of the AzureRM Provider. The current AzureAD resources (in this provider) will be deprecated in the AzureRM Provider in the next release (v1.21) and then removed in v2.0. Since this is now split out we should be able to work on the improvements listed above (and in the other GitHub issues) - we're also migrating the AzureAD issues over to the new repository too. Thanks! |
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 👉 [email protected]. Thanks! |
As a part of v2.0 of the AzureRM Provider we're working through some of the longer-term changes we'd like to make.
Over the past year or so we've shipped support for some Azure Active Directory resources within the AzureRM Provider - including support for Applications, Service Principals (and there's PR's/feature requests for more AzureAD resources).
Upon reflecting on this a little - we realised that Azure Active Directory may make more sense as a Provider in it's own right. There's several reasons for this:
1. Acceptance Tests
We run Acceptance Tests for all of the Data Sources and Resources in the AzureRM Provider every night - which means that we spin up thousands of resources on demand. This has allowed the AzureRM Provider (along with all the other Terraform Providers) to move pretty quickly - we ship new releases often and have confidence in the resources we're shipping.
All of the AzureAD resources we currently support have acceptance tests, which run nightly too. However there's several Resources/Data Sources we want to add (such as Users) which are considerably harder to write automated acceptance tests for; this is because they (for example) involve sending an email and then completing a Captcha on signup etc. In addition - (almost) every Data Source has an associated Resource - however being unable to write Acceptance Tests for a given resource means we're also unable to support a Data Source either.
Splitting AzureAD out into it's own provider would allow us to manually test the components which can't be automatically tested (prior to a release) whilst still remaining confident in the other resources (since there'd still be automated tests). Since we'd be moving slower in this provider (specifically, we'd be upgrading the Azure SDK for Go less) - shipping support for a resource that's manually tested wouldn't be /as/ big of a deal as it would be in the AzureRM Provider (whilst obviously not being ideal).
2. Re-evaluating the design of some of the AzureAD Application/Service Principal resources
After shipping the
azurerm_azuread_application
,azurerm_azuread_service_principal
andazurerm_azuread_service_principal_password
resources and seeing some real world feedback - there's sufficient bugs/issues in these resources that I believe these resources require some thought/re-work. At this point in time I'm wondering if it'd make sense to combine the Service Principal resources together - but it requires some prototyping/consultation/additional research to confirm we've covered all the edge-cases.Splitting AzureAD out into it's own provider would allow us to reevaluate the design of these resources.
3. Authentication
The AzureRM Provider's tied to a Subscription (since almost all resources in AzureRM are subscription-level) - however Azure Active Directory is instead tied to a Tenant, which means the Subscription is Optional. This means at this time it's not possible to manage AzureAD resources in Terraform if there's no Subscription configured for the Tenant (as in the case of Office 365).
Splitting AzureAD out into it's own provider would allow us to drop the dependency on the Subscription.
As such - we're thinking about splitting the AzureAD resources out into their own provider -
azuread
- this'd allow us to ship some of the highly requested Data Sources/Resources such as Users/Groups (since we can manually test these hard to acceptance test cases).This issue's primarily here to get feedback on this as early as possible - thoughts? :)
The text was updated successfully, but these errors were encountered: