DevOps trick - Provision Azure Active Directory Apps in a highly controlled way

  • Article

Hi,

Besides promoting a new collaboration mindset between development & operations, DevOps' primary goal is to use tooling in order to reach continuous development as well as continuous deployment. As it implies a cultural change, it often cristalizes tensions between the involved stakeholders but I'm not gonna debate about its current effectivness and reality within the enterprise, instead, I'm going to focus on automated deployments of Azure Active Directory Applications.

As you know, Azure Active Directory is the corner stone of any Cloud/Hybrid application that uses Microsoft technologies. Therefore, having a good deployment strategy for Azure Active Directory applications is key. Of course, automating things is great but we need to make sure to do it properly without introducing security concerns.

Historically, the responsibility of on-prem active directories is often in the hand of the identity & access management team (IAM) and it still makes sense that this team is in charge of Azure Active Directory as well, since most of the times, there is a synchronization of identities from the on-prem AD to AAD. However, Azure Active Directory introduced a new kid in town, namely the Azure Active Directory Applications (among other things) and this thing sounds more like a dev topic or at least, a hybrid beast, in between the infra & development worlds. So, it sounds like a good candidate for DevOps. So, developers want to automate the provisioning of apps as part of the release lifecycle, while the identity & access management team wants to make sure not to grant too much permissions in order to avoid unexpected interferences with other apps (non-DevOps ones). So, typically, DevOps will not be granted the Global Admin privilege as they would have full power over their own apps but also over every other app and that should remain the privilege of the sole IAM team...Here is a small schema representing what we're trying to achieve, sometimes pictures help :):

 Figure 1: DevOps being able to provision apps automatically but only with a specific isolated SPN that has no permission over other apps.

In this blog post, I'm going to give you the high-level picture only of how to achieve this. I might write a full walkthrough article later this year, so don't hesitate to comment on this if you'd like to see such article.

So, let's review the IAM team's requirements:

  • You cannot be global admin as you'd have way too much privileges and we can't prevent you from performing harmful operations
  • You cannot interfere with other apps (non-owned apps)

In Microsoft's world, Vistual Studio Team Services aka VSTS plays the most important role in terms of tooling for DevOps, as it not only stores applications'source code, it is also the starting point of any build, release and deployment. So, in a nutshell, here are the steps required to achieve automation with the above requirements:

  • Setup an ARM endpoint in VSTS.
  • Grant the required AAD Application Permission to the VSTS app

    and make sure to perform an admin consentThis level of permission suits exactly our needs. With this in hands, VSTS will be able to create/update/delete any type of AAD App (Native/WebAPI) and configure it as needed (reply urls, required resource access, etc.) while not being able to touch any non-owned app.  On top of that, should VSTS create apps with permissions that need admin consent, it will not be able to perform the admin consent, so the IAM team will still need to perform it, ensuring the holistic view against the entire directory & set of applications, and preventing from unattended access to resources.
  • Make sure you have a build and a release definition
  • Install AAD V2 PowerShell cmdlets on your agent if you use a company hosted build agent.
    Azure Active Directory V2 PowerShell cmdlets are a must here as it comes with all the required cmdlets as well as parameters that allow you to perform complex operations on apps.
  • Write the deployment scripts
    For the time being, there is no AAD ARM template (that you can use to provision other types of components such as app services, app service plans, sql databases, etc.) so you'll have to write your own script to get the job done.

So, the two first bullet points are a no brainer in terms of complexity but they represent the trick as not everyone knows about the fact that VSTS can use an app to provision things in Azure and even less people know about this very specific app permission.

For the third one, you need to have a good understanding of VSTS and that's what would require a walkthrough article should I elaborate more. As you might understand, the ultimate goal is to make sure your release definition in VSTS picks up the PowerShell script you wrote while using the VSTS Azure Active Directory app's permissions.

Happy Deployments!