Walking through Azure Cloud || Part-7

If you are landing first time, this is the link to go for you. In this blog, we shall learn about ManagedIdentities from Microsoft-Azure :-

Example #1

Question → How the permissions are checked for the Users ?

Answer → We can basically assign different Roles to a particular User.

Question → Showcase how can our Application, can access some resources which are present in our Azure Storage Account, using the very basic approach ?

Answer → Here is how we can access the files present in our Storage-Container :-

Step #1.) Let’s first see the files which are present inside our container :-

• Storage Name → “appstore55455344243”
• Container Name → “data”

Step #2.) Let’s now navigate to “Access Keys” section for our Storage Account. Below screenshot, we can see the ConnectionString and Key that we can use, in order to access this storage-account :-

Step #3.) Here is how our code looks like in order to access this file. We make use of following things :-

• BlobServiceClient
• BlobContainerClient
• BlobClient

In the above approach, there is a problem — We have manually entered the credentials (i.e. ConnectionString) inside our code.

Question → Showcase how can our Application, can access some resources which are present in our Azure Storage Account without having to mention the connectionString ?

Answer → This can be done with the help of “Application-Object”.

Step #1.) Let’s first see navigate inside our EntraId first.

Step #2.) We would register an Application now :-

Step #3.) We would now supply the name of the Application :- In our case, we are specifying the name as “blobapp”.

Step #4.) Once our Application is registered successfully, we take note of following things :-

• TenantId.
• ClientId

Step #5.) We would now go inside the : “Certificates and Secrets” as shown below and create the “Client-Secrets”.

Here is we can see the “Client Secrets” :-

Step #6.) Now, so far we registered an Application and now, we need to allocate the permission to this Application-Object. So, let’s first go inside the Storage-Account → Access-Control → Add-Role-Assignment.

Next :-

• We have selected the role as : “Storage Blob Data Reader”.
• Under the option : “Assign access to” :-we choose : “User, Group, or Service Principal” :-
• When we click on Select-Members → we can select our Application-Object i.e. “blobapp”.

Finally, once the Role is assigned to this ApplicationObject, this is ready to be used in our application-codebase.

Step #7.) Now, we shall directly access the files, which are present inside our Storage-Account → Container → Files using :-

• ClientSecretCredential
• BlobClient

Now, when we execute our code at our local-personal-On-Premise-machine, we shall be able to download the file successfully now :-

Question → What’s the main dis-advantage of using Application-Object mechanism of accessing the Azure-Resources from the Application codebase ?

Answer → The main problem here is :- Even though, we have made use of RBAC, we still needed to embed the credentials of the Application-Object in our codebase :-

Example #2

Question → What is the alternative to the Application-Objects ?

Answer → The alternative to the “Application Object” is to use : “Managed Entities”. This gives us a way for our Applications to authenticate to Azure Resources without the need of embedding the credentials.

Question → What is the main requirement in order to use the “Managed Entities” ?

Answer → The main requirement is :

• Our application-code needs to be hosted on a service that supports Managed-Entities like VM, App-Engine, etc.
• Under the hoods, the “Managed Entities” shall create a Service-Principal for that resource.

Step #1.) After our first is successfully created at our Azure Account, Under the “Identities” section, we enable the System Managed Entity :-

Once we enable the “System Assigned Managed Entity”, here is how it would look :-

Step #2.) Now, let’s assign the RBACs. Here, we are saying , we shall allocate the permissions of accessing the Storage-Account to our VM.

• So, for this, we go to the Storage-Account → “Access Control (IAM)”.
• Please note that, this is the Account, that has to be accessed by our application-codebase.

Step #3.) We shall choose the Role as : “Storage Blob Data Reader” and move forward :-

• We choose : “Managed Identity”.
• Under Members, we choose our VM, to which the access to Storage-Account has to be assigned.

So, here we choose our VM that we created in aforementioned-step :-

After the Role has been assigned to the afore-shown VM, here is how the UI would look like. Now, we hit the : “Review and Assign” button.

Step #4.) The class that we shall use to access the Storage-Account from the Application-codebase is : “DefaultAzureCredential” :-

Step #5.) The code to access the Storage-Account & objects in the container , through the DefaultAzureCredential looks like as follows :-

• BlobClient.

Please note that :-

• The aforementioned code-base can’t be executed at our local-on-premise-machine, rather this code can only be executed at VM, which is present inside our Azure Ecosystem.
• In the above mentioned steps, we have created the VM (at which we shall be running the afore-shown code-piece).
• So, we first build the code at our local and would take the executables at our VM.

Question → How does DefaultAzureCredential works under the hoods ?

Answer → Under the hoods, it generates a token, which VM shall be used to hit the Storage-Accounts :-

Step #1.) Here, Azure exposes this endpoint, which we shall copy from here :-

Step #2.) Let’s now write this code, to access the token for the Storage-Account :-

Step #3.) We build this code at our local machine and take this executable at the VM. Once the executable is there is at the VM, we shall execute it and we can now see the token, which is what being used under the hoods of ManagedEntity :-

Step #4.) Now, we can also fetch, some more informations from this Token :-

Step #5.) Now, we again build the code at our local :-

We now take the executable to VM :-

We now execute the same DLL at VM and we can see some additional information from this Token :-

• client_id
• token_type

Step #6.) Here is now, we can execute our code to access the Storage Account too :-

The procedure would remain same. Build at Local → Transfer to VM → Execute at VM.

Example #3

Question:- Demonstrate the concept of Managed-Identities with some different example ?

Step #1.) Imagine that we have a Virtual-Machine.

• First, we go and enable the System-Assigned Identity at this VM.
• Once we enable to System-Assigned Managed-Identity for this Resource (VM), it would be able to call other Azure services.

Once we enable the System-Assigned-Managed-Identity for this VM, we can see it’s Principal-Id :-

Step #2.) Imagine that our application is running at the afore-said VM and it wants to access the below shown Storage-Account (“tempfunction4567grob884”), then we shall have to : “Add the Role Assignment” on the storage-Account :-

Here, we have to choose the Job-Function-Role : “Storage Blob Data Contributor”, because we want our VM to be able to contribute to the Storage Blob Data :-

Under the Members section, we can choose “Managed-Identity” and under the MI, we can choose the VM (for which we enabled the MI in step #1) :-

We shall be able to see the VM (for which we enabled the MI in step #1) :-

Here, we can see the final step :-

So, finally now, our application (running at our VM) would now be able to access the Storage-Account automatically.

Example #4

Question:- Demonstrate the concept of UAMI with some different example ?

Step #1.) Let’s first create an User-Assigned-managed-Identity :-

This is how our UAMI would look like, once it is succesfully created :-

Step #2.) Now, we go to our Storage-Account and attach this UAMI to this Storage Account :-

From the Role, we shall assign the : “Storage Blob Data Delegator” role to the Storage-Account :-

Now, we associate the Managed-Identity to this Storage-Account :-

Here is how, it would look, after we attach the MI to this Storage-Account :-

And we can see here that, UAMI has been associated with the Storage-Account succesfully :-

Step #3.) Now, we associate the afore-created UAMI with our Virtual-Machine.

• Note that, our intention here is that, our application running on this VM, should be able to access the afore-shown Storage-Account.
• We can attach this UAMI to as many resources as we want. Say tomorrow some App-Function wants to access this Storage-Account, then we can associate this same UAMI to that App-Function as well. We don’t need to enable the MI again & again inside the Storage-Account.

Let’s add the Identity to our VM now :-