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] 2.0 - Azure Active Directory #2322

Closed
tombuildsstuff opened this issue Nov 15, 2018 · 13 comments
Closed

[Proposal] 2.0 - Azure Active Directory #2322

tombuildsstuff opened this issue Nov 15, 2018 · 13 comments

Comments

@tombuildsstuff
Copy link
Contributor

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 and azurerm_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? :)

@perbergland
Copy link

I think it makes a lot of sense and it was always what I expected to be the design.
The AD entities and the ARM ones always seemed quite separate to me.
Will this approach also allow us to use the two providers in the same project?
My current solution has AD mutation happening both before and after the AzureRM run, like creation of AD groups, then assigning roles to these groups and finally populating the groups with MSI principals from resources created by TF

@joakimhellum
Copy link

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.

@davepattie
Copy link

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

@rayterrill
Copy link

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.

@paulschwarzenberger
Copy link

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.

@tombuildsstuff
Copy link
Contributor Author

Once this is done we should be able to port the work done by @tiwood in #1865 / #1839 (which adds support for AD Users/Groups) over to the new AzureAD Provider repository. Since both of those PR's are blocked on this split-out I've temporarily closed those PR's for the moment.

@tiwood
Copy link
Contributor

tiwood commented Nov 27, 2018

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 :-)

@tomasaschan
Copy link
Contributor

@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).

@tombuildsstuff
Copy link
Contributor Author

@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!

@LaurentLesle
Copy link
Contributor

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...

@midacts
Copy link
Contributor

midacts commented Dec 7, 2018

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).
Hopefully after the azuread provider is created, more resources will be available.

@tombuildsstuff
Copy link
Contributor Author

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!

@tombuildsstuff tombuildsstuff modified the milestones: 2.0.0, 1.22.0 Jan 21, 2019
@ghost
Copy link

ghost commented Mar 5, 2019

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!

@ghost ghost locked and limited conversation to collaborators Mar 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests