Azure Portal in a nutshell

Azure Portal in a nutshell

Over the past year, I’ve had a few tasks at work that involve using Azure Portal. I believe I’ve gotten a decent understanding of Azure portal, at least to the point of being able to navigate around and get the job done. This article represents how I view the portal in my head. This is not going to be detailed with every piece of info, it is just to get an overall view. For the details, I usually do this and recommend you to do it as well, which is to RTFM. Do note that this is my current understanding at the time of writing, so in case I’m wrong in anything do let me know :)

Here are the main things to keep in mind:

  1. Tenant / Directory
  2. Subscription
  3. Resource groups
  4. Resource
  5. Registered app
  6. Service principal

One way of segregating the above items is into 2 categories, with all of them existing under a tenant:

1. Authentication / Authorization

  • Registered app
  • Service principal

2. Resource

  • Subscription
  • Resource groups
  • Resource

Now, the general flow to keep in mind (for resource category) is this: Tenant > Subscription > Resource group > Resource

1. Tenant / Directory

This is the top-most level that contains everything else within. An account can have one or multiple tenants. An example of having multiple tenants is that you keep one tenant for your application that exists on different environments and another tenant for internal R&D that employees can use. Tenant and directory are used interchangeably as words. In Azure Portal, this specifically becomes Entra ID. To give an analogy, think of tenant as “database” and Entra ID as “postgres”.

2. Subscription

Let’s imagine a scenario where you’re doing a garage sale. There is a condition that you have to put all items in boxes. A subscription in this case is a box and the items inside a box are the resources you create. A tenant can have multiple subscriptions. Subscription is the level where:

  • Azure can give you the total cost of the subscription by calculating usage of resources present under
  • You can implement RBAC policies of who has access to what
  • You can add in limits to your resource usage

3. Resource group

A resource group is just what it sounds like. A group of resources. One subscription can have multiple resource groups. It’s a nice way to be able to segregate resources based on your or your company’s grouping logic. A nice way for organizing resource groups under a subscription is by the environment (dev, int, qa, perf, preprod, prod) if that’s relevant to your work.

4. Resource

A resource is the actual thing you want to use. A subscription and resource group are just logical containers but resource is the entity that would use actual compute. Resources are of different types like App Service, Log Analytics Workspace, AKS, CosmosDB, Azure OpenAI service, Key vault, etc. Depending on what you require, you create the resource, put it under a resource group, which would exist under a subscription.

Okay, we’ve covered the Resource category. Now let’s say you want to access a Log Analytics Workspace in your CI to know the volume of logs ingested, how would you go about that? That’s where a Registered app comes in.

5. Registered app

A registered app (or app registrations) is what allows your CI from the above scenario access Log Analytics Workspace (or any resource for that matter). Fun fact about a registered app, they don’t come under a subscription since they don’t live under the resource category. You can create client credentials which allows 3rd parties to access the resources present in your Azure portal. When you create an app registration on Azure portal, 2 things are created:

  • Application object (an object that represents your created app)
  • Service principal (check next section)

Think of app registration as a blueprint and an application object an instance of that blueprint.

6. Service principal

The core identity representation to access what you want in Azure portal is a service principal. Let’s continue that example from above. Your CI pipeline has to access a Log Analytics Workspace. To access that workspace, you create an app registration where you do the following:

  • Create client credentials (to generate a token to access Azure portal through API)
  • Add read permission for Log Analytics Workspace on the registered app
  • Add your app as a reader under IAM of the Log Analytics Workspace

After this is done, you have your script which gets the access token, gets the volume of logs ingested through the API and logs it to the console. When your script queries for the volume of logs ingested, that’s where Service Principal comes in. That generated token which you sent in the query to get the volume of logs tells Azure that the registered app’s client is what is trying to access the Log Analytics Workspace.

The rest of the details like different types of resources and their working, or what happens when you delete a resource group with resources present in it, and other things are implementation details that one can get from the docs. I believe with these concepts, one can navigate the Azure portal fluently.