A place to share technical learnings, etc.
aws | jekyll | github | apigateway | serverless | ad | powershell | windows | webdev | nodejs | terraform | consul | nomad | jenkins | traefik | azuread | azure |
As noted in HelloAgainAzure, I’ve spent the last few years using AWS for nearly everything,
One of the pieces I “miss” from AWS is AssumeRole - specifically the concept that you can jump around between accounts with ephemeral roles as-needed vs having individualized credentials in each account. Azure appears to really has no equivalent to this functionality, although there are a few pieces you can use to approach some of this.
After digging in a bit, I found Azure supports the ability to have a single identity be usable across directories (and their trusting subscriptions) - one of the major use cases I’ve used previously with AssumeRole (this could be particularly useful with an infrastructure deployment system like Atlantis where we want to support the ability to deploy changes to resources serviced by multiple directories).
AzureAD supports multitenant applications - that is, applications that are defined once, and can then be installed into multiple directories. When the application is installed into directories, a service principal object is created representing that instance of the application in that specific tenant. Microsoft defines this as:
The application object defines the application’s identity configuration globally (across all tenants where it has access), providing a template from which its corresponding service principal object(s) are derived for use locally at run-time (in a specific tenant).
As a possible solution for this particular use case, we could define an application that represents the workload we’d like to use across multiple directories, then install that into each directory where we need that workload to be able to do work. This would allow us to use service principal authentication to log into each directory, using credentials defined in our “home” directory.
This scenario is illustrated below, where we have a home “Management” directory with a number of subscriptions, as well as a “child” directory with a number of subscriptions.
For simplicity’s sake, I’ll show this in the Azure Portal, and I’ll assume you’re a Global Admin in all tenants. Similar configuration could be done with Terraform, PowerShell, Azure CLI, etc.
At this point, we should be able to test login using the Azure CLI to our Home/Management directory with our service principal.
az login --service-principal --username [Application (client) ID from above] --tenant [Tenant ID for our Home/Management tenant]. You’ll be prompted for the password. If everything worked correctly, you’ll be logged in successfully. Depending on what permissions you’ve assigned to the application, you should also be able to perform operations as this service principal. .
Now that you’ve validated that your application works as expected in the Home/Management directory, lets install it into another Azure Active Directory.
https://login.microsoftonline.com/[Child Tenant ID]/oauth2/authorize?client_id=[Application (client) ID from above]&response_type=code&redirect_uri=https://portal.azure.comin the browser, substituting in the Tenant ID of the child Azure Active Directory tenant as “Child Tenant ID”, as well as the App Registration’s “Application (client) ID” as “Application (client) ID”. You’ll be presented with a Consent prompt to install the application into the target directory. Check the box to consent on behalf of the org, and click “Accept” to install the app into the directory.
At this point, we should be able to test login using the Azure CLI to our child directory with our service principal.
az login --service-principal --username [Application (client) ID from above] --tenant [Tenant ID for our child tenant]. You’ll be prompted for the password. If everything worked correctly, you’ll be logged in successfully. Depending on what permissions you’ve assigned to the application, you should also be able to perform operations as this service principal. .
Rinse/Repeat on any additional Directories as needed.
This works, but it’s both significantly more complicated than similar functionality in AWS, as well as less flexible.
Ideally, I’d like to see this kind of functionality supported by Azure Managed Identites, but that’s currently not possible https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/managed-identities-faq#can-i-use-a-managed-identity-to-access-a-resource-in-a-different-directorytenant. Having cross-directory functionality supported by user-assigned managed identities would be a big win.tags: azure - azuread