1. AZ-203/ 204 – What is the Azure Key Vault Service
Hi, and welcome back. Now, in this chapter, I want to go ahead and talk about the Azure Keyword Service. So the Azure Keyword service is basically a managed service in Azure, which is basically used to manage all of your secrets. So let’s say you want to securely store a database password somewhere. You can actually go there and make use of the Azure Keyword service. So let’s say your application needs to connect to a database. So, remember, in order to connect to the database, it needs to use a username and a password. Now, you could embed the password within the application itself, but this is not a secure practice. Instead, you can make your application make a secure call onto the Azure Keywall service. The application could then fetch the password from the Azure Keywall service, and then it could go ahead and connect to the database.
So the keyword “service” is a secure place for storing all of your secrets. Now, in addition to storing secrets such as passwords, it could also go ahead and store encryption keys. So if you want to go ahead and have a place to store your keys that can be used to encrypt your data, you can make use of the Azure Keywall service. You can also go ahead and store your certificates as well. So, instead of maintaining their own on-premises server and installing software on that server, a company can simply go ahead and securely store, say, their encryption keys and certificates in the Azure Keyword service. This is a completely managed service. It’s a secure service. It’s a safe service that you can use for creating and managing all of your secrets. So let’s move on to the next set of chapters, in which we are going to see how to work with the Azure Keyword service.
2. AZ-203/ 204 – Lab – Azure Key Vault
So here I’m at zero. Now let me go ahead and add a new resource. So I’ll search for the key vault. I’ll hit “create.” I’ll go ahead and choose my subscription. I’ll choose a resource group. Let me give the vault a name. So it needs to be unique. Now, if you want to ensure that you can recover your deleted objects, So let’s say someone accidentally deletes one of the objects in the Key Vault. If you enable soft delete, then you can go ahead and recover those deleted objects. So if you want, you can keep this enabled. You can then specify a retention period.
So if someone deletes it, how long do you want to retain that data for? So you can keep it at 90 days. I’ll leave the cleaning to you. Production has been disabled. I’ll go on to the access policy next. Now, I’m going to leave the settings as they are. I’ll let you handle the networking. I’ll go on to tags, review, and creation. And let me go ahead and create the Azure Keyword Resource. Now, once you have the resource in place, you can go out onto the resource. Now over here on the left-hand side, you can see that you can create keys, secrets, and certificates, right? So in this chapter, I just want to go through the concept of creating an Azure Keyword Resource. Let’s go on to the subsequent chapters and see how to work with the different artefacts that are available in the Key Vault.
3. AZ-203/ 204 – What is a service principal
Hi, and welcome back. Now in this chapter, I want to go through the concept of the service principle. now has a user. So you can define a user in an Azure advertisement. And using that user principle, you can actually go ahead. Once you authenticate yourself on Azure, you can have them access resources such as the Azure SQL database, the Azure Virtual Machine, or even the Azure Keyword Service. But let’s say you want to have an application that needs to go ahead and fetch, say, a secret from the Azure Keyword Service. Since we’re actually going to go ahead and understand how this can be achieved, it’s important to understand the basis of the service principle. So in your application, instead of embedding the username and password of a user principal, which is a bad security practice, you can go ahead and create a service principal in Azure.
So it’s like creating a user, but the only difference is that it’s basically a separate principle that can be given permissions and then assigned to the application. And then, using that service principle, the application can then access the resources or objects in the Azure Keyword Service. And that’s what we are going to do. So when we go ahead and actually see how to allow an application to access, let’s say, a key or a secret in the Azure Keyword Service, we are all going to go ahead and create a service principle. We are going to ensure the service principal has the right permissions over either the key, the secrets, or the certificates in the Azure Key Vault service. And then we can go ahead and allow the application to actually access those resources in the Azure Key Vault. Right? So just a quick note on the service principle before we move forward.
4. AZ-203/ 204 – Lab – Azure Key vault – Secrets
Hi, and welcome back. Now in this chapter, I’m going to show you how you can make use of secrets as your keyword. So let’s go over to our keyword. Now I’ll go on to secrets. So remember, if you want to store objects, which are your database passwords, in the Keyword service, you can go ahead and make use of secrets. Let me go ahead and generate a new secret. Let me give a name to the secret. I’ll enter the value of the secret.
So I’ll just put a value of “secret password.” Now, you can also set an activation date and an expiration date for the secret. You can even do it for the key as well. So over here, you can say that the key or the secret should only be used after the activation date and before the expiration date. Let me hit on “create.” So let’s imagine that this is a password for a database. And let’s say now we need to have a programme that first needs to go ahead and fetch the value of this DB password from the Azure Keywall Service. And then the application can go ahead and use a password to connect to a database. Now over here, I have Visual Studio open. What I’m trying to do over here is go onto the keyword, which you can do via the Key Vault URL. So, if you go to Key Vault and then to Overview, you’ll find your Key Vault URL over here. So let me go back on to the program.
So once I go on to the URL, I’m just using a class to go ahead and fetch secrets from the vault. I’ll mention what the name of the secret is that I need to fetch, and then I’ll display it on the console. Now, this programme needs some way of authorising itself to go ahead and work with the Azure Key Vault service. And for that, we’re going to implement a couple of steps. So remember, I talked about that service principle. So that service principle is something that we need to create. We need to ensure that the service principal will have access to the Azure Key Vault. So first I’m going to go on to Azure. I’m going to go ahead and open an Azure cloud shell. Now over here, I’m going to execute the following command: So over here, I’m executing a command against a zero of 80. I’m ensuring that I create a service principle. Here’s the name of the service principle. I’m ensuring that role-based access control is enabled for the service principle. So let me go ahead and execute this command. So we’ve finally gotten the service principle. Now what’s important in the output is basically the application ID, the password, and the tenant. Now there are multiple ways for your application to go ahead and use these particular values to go ahead and authenticate and start using the Azure Keyword service.
But one way for a developer to go ahead is to basically change the environment variables. So I’m on a Windows machine, so let me go ahead and just set some environment variables. So on my system, I’ve just gone ahead and set these three environment variables. So, what is the Azure Client ID? The Azure Client secret and the Azure Tenant’s ID Once you’ve done this, your Azure Client ID will be mapped to your application ID. It has the same value. Then the client secret is basically the password over here. And your Azure tenant ID is basically the tenant value over here. So once you’ve gone ahead and set this, I’m going to make sure I restart Visual Studio so it will go ahead and take those values. So I’ve gone ahead and restarted Visual Studio. Now we’ve gone ahead and created our service principle. Now we must execute one more command, in which that service principle is essentially granted access to the secrets.
So, if I go to the top, I’m essentially providing or establishing a policy for that key vault for that service principle. So remember, here is a service principal ID. And here I’m giving you all the secret lists and secret permissions. So there’s backup, delete, get, list, and set. So this is important. So first, you go ahead and create your service principle. That service principal detail is now part of the environment variables of the system on which the programme is running. And now we are ensuring that we set a policy so that the service principal now has permission to access your secrets. Now let me go ahead and run the Visual Studio program. So when you run the program, you’re basically now getting the value of the secret, which is the secret password. That’s what I said was the value of the DB password. So now your programme is making a secure call onto the Azure Keyword Service and getting the value of a secret. So this is the entire idea of having secrets in the Azure Keyword Service.
So just a quick review of what we did in our lab So for our application, in order to access the secrets in the Azure Key wall service, we have to create something known as a service principle. That service principle is basically defined in Azure 80. So the application uses the service principal to authenticate onto Azure 80. And then we need to give that service principal permission to go ahead and access secrets in the Azure Keyword service. So the permissions we have given our backup are delete, get list, and set. So once the application uses the service principal and the service principal has been assigned these permissions, the application can then authenticate onto Azure and would be authorized to go ahead and access the secrets in the Azure Keyword service. Right. So this marks the end of this chapter. You.
5. AZ-203/ 204 – Lab – Azure Key vault – Encryption keys
And welcome back. Now in this chapter, let’s look at working with encryption keys in the Azure Key wall service. So, let’s say you want to generate or have a key that can be used to encrypt data. You can go ahead and create one in the Azure Keyword service. So you can go on to the service, go on to keys. Let’s go ahead and create a new encryption key. So let’s give it a name. In this section, you can specify the key type and size. So Alibaba has it again; you may specify the activation and expiration dates. So Alibaba has this, and let me go ahead and create the key in the Azure Keyword service, right? So that’s done. Now over here, again, I have a Visual Studio program. So again, this programmer is making a request to the Azure Key Vault.
This time, I’m using the key client class to go ahead and get the new key from the key vault. I’m then using that key to go ahead and encrypt this sensor data. So I have a text over here. So this can be encrypted using that encryption key. I can then go ahead and again use the necessary classes to decrypt that encrypted text or that cypher text, and then go ahead and display what the plain text is. So remember, you can go ahead and store your encryption keys in the Azure Keyword service. We then use your own application or your own encryption methods or algorithms to ensure that you encrypt the data and then use the same encryption key for decrypting the data.
Now, in order to ensure that this programme runs, remember that in the prior chapter, we had gone ahead and created a service principle. We gave those permissions for the principal service, Secrets, in the Azure Keyword service. Now, here also, we have to perform the same operation. We have to ensure that we give permissions to our service principal for the encryption keys in our Azure Key Vault. So I’ll go over to Azure. I’ll go over to Azure. Cloud shell. I’ll hit “paste.” So, in essence, what I’m doing over here is configuring the AZ keyword and policy. I’m giving the vault its name. And then I’m giving backup, delete, get list, create, encrypt, decrypt, and update permissions. And again, I’m mentioning the same service principle. So let me go ahead and execute this. So now that I’ve given the required permissions, if I go on to the program, let me run the program.
So over here, we’re getting the plaintext, as this is sensitive data. So remember, for this particular string, what we’ve done is that we’ve first encrypted the string using the encryption key, and then we’ve gone ahead and decrypted that particular text and displayed it on the console. So, if you look at the review, you’ll notice that the concept is similar, so we have our application. We have a service principle. We’ve granted the permissions for the keys in the Azure Keywall service. So when the application needs to use an encryption key to go ahead and encrypt data, it will go ahead and use the service principle. It will authenticate onto Azure Ad and then authorise itself to go ahead and use AKey in the Azure Keyword Service. Right. So this marks the end of this chapter.
6. AZ-203/ 204 – Lab – Permisisons vs RBAC
Hi, and welcome back. Now in this chapter, I want to go through the key concept or the difference between permissions and role-based access control when it comes to the Azure Key wall Service. So in the prior chapters, we had seen how we could work with secrets and how we could work with keys in the Azure Key wall Service.
Now, when we had our application running and either retrieving a secret or a key, So remember, first we registered an application in Azure, or a service principal. And for that service principle, we ensure that the service principal has the right permissions whenever it comes to working with secrets or keys in the Azure Keyword Service. So the first thing from this that you have to understand is that in order to access any of these artifacts, whether it be an encryption key, a certificate, or a secret, you need to ensure that you have the right permissions in place for these particular resources. So, for example, if you’re looking at encryption keys, a user, an application, or a service principal needs to have permissions.
So, for example, you could grant the permissions to create an encryption key or to encrypt and perform decryption operations using the encryption key. Similarly, for a certificate, you could give permission to go ahead and create a certificate. And for secrets, you could go ahead and give the permissions to either set the value of a secret, list the secrets, or get the value of a particular secret. So remember, permissions are important. You have to give permissions to the resources in your Azure Key vault. Now next we come to role based access control. Now, role-based access control is given at the control plane level, which is at the Azure Key Vault level, not at the encryption key level, the certificate level, or the secret level. So for that, you have the permissions. So role-based access control is given at the keyword level, the Azure keyword level.
So, for example, one of the roles that you can actually give to users is “keyword contributor.” So this lets you manage the key vault and the various aspects of the key vault, but it does not give you access to the data itself in the key vault. So I said that to give access to the data in the key vault, you have to look at giving permissions. Now let me go on to Asia just to show you both of these aspects. So, as I move on to our existing keywords, keep in mind that we had ensured that we worked with keys and secrets in this keyword. Now, if I go on to access policies over here, you can see that we have two access policies in place. So these access policies are given for an application and for a particular user. So this is basically our global administrator. Now over here, if I just scroll on to the right, So here you can see that you can give permissions for your keys, your secrets, and your certificates if I go on to any of the permissions. So these are the only permissions available in the key permissions. So if you want a user or an application to perform different operations on the keys that are available in the Azure Keyword service, then you have to ensure that you give the right permissions.
Similarly, when it comes to secrets, the situation is the same. So over here, you have the permissions that are available for a secret, and then you have the permissions that are available for a certificate. Let’s say you want to give another user access to or permissions over either keys or secrets. You could go ahead and add an access policy. So first, you could go ahead and select the principal. So let’s say I want to give the user the option to select multiple items. So I have selected my principal. The principal can now be a user principal or a service principal. Then you can go ahead and give the required permissions. So let’s say that you want to ensure that this user can go ahead and get the values of secrets in the Azure Keyword service, or list the secrets and set the value of secrets in the Azure Keyword service.
So you can go ahead and select these permissions. You can then scroll down, click on Add, and then, very important, it even mentions it over here. Please ensure that you click the Save button to go ahead and commit your changes. So go ahead and click on “Save.” So once you’ve done that, you now have the three principles in place over here, which have different access or permissions on either keys, secrets, or certificates in the Azure Key Vault. And then we have our normal role-based access control. So if you go on to access control, click on role assignment. So again, over here, you can go ahead and select the different roles. So I said if you want users to go ahead and manage the different aspects of the keyword, you can go ahead and select the Keyword Contributor role, go ahead and select the user, and that’s it. So this is at the control plane, just to manage the keyword vault. It is not used to manage the data in the key vault itself. So these are the two different aspects when it comes to access control for Azure Key Vault. So this marks the end of this chapter.
7. AZ-203 – Lab – Azure VM Disk Encryption
Hi, and welcome back. Now, in this chapter, we are going to go through disc encryption for Azure Virtual Machines. So, remember, with Azure Disk Encryption, you can go ahead and encrypt the volumes that are attached to your virtual machine. So over here, I’ve gone ahead and logged into one of my virtual machines. So the name of the virtual machine is basically “new VM.” Now, if you look at the volumes I have over here, that is, my Windows drive and my temporary storage, Please make a note that at the moment, there is no lock symbol on either of these volumes. Now let’s go ahead and ensure that these volumes are encrypted. Basically, the underlying discs are encrypted using Azure disc encryption. So for this, we have to make use of an Azure keyword. So the Azure key vault will ensure the keys are in place for the encryption process. So I’m going to go ahead and use an existing vault, a demo Vault 990 vault. Now, before we can execute the command to enable encryption of the volumes on the Azure Virtual Machine, we must first go over access policy.
So there’s one setting that we have to ensure or implement. So we have to go and enable Azure decryption for volume encryption. So this is important. Now, once you’ve gone ahead and done this, you have to go ahead and click on Save to commit the changes once this is done. Now, in another tab, I have opened the Azure Cloud Shell. So over here, we’re going to go ahead and execute a command that will be used to perform disencryption. So over here, I’m going ahead and using the Azvm Encryption Enable command. I’m mentioning the resource group, I’m mentioning the name of the virtual machine, and I’m mentioning what the name of the key vault is. Let me go ahead and execute this command. So over here, I’m going to execute the command for enabling disc encryption. So I’m going to be using the Azvm encryption enable command. I’m going to be giving the name of my resource group, the name of the virtual machine, and the name of the key vault. Let me go ahead and execute this command. Now, during the execution of this command, you might lose your remote desktop session on the virtual machine. Let’s come back once this command has been executed. After some time, once the command has completed execution, connect to your virtual machine. So remember, your session might have disconnected during the encryption process. You can then go ahead and reconnect to your virtual machine. Now, over here, when you go on to your volumes, you can see that there is a lock symbol in front of both of the volumes, both on your C and your D drive. And that means they have now been encrypted using BitLocker. So now your data on your Windows Virtual Machine is encrypted at rest, and this marks the end of this chapter.
8. AZ-203/ 204 – Lab – Azure Key Vault – Invoking via API calls
Hi, and welcome back. Now in this chapter, we are going to see how we can access a secret stored in the ASIO Key Vault via an API call. Now, before we get into how we’re going to do this, a quick note about the ASIO advertisement. Now, in Azure AD, you have three types of entities that you can create for an identity purpose. So you could create a user, you could create a group of users, or you could create a service principle, and then you could give these identities access to the Azure Key Vault. Now, normally in your application, you’ll be using an application to make calls to an Azure Key Vault. So during that time, you would not embed any user credentials in your application code to gain access to the Azure Key Vault. So what you can do with that, and what we’re going to be doing in our lab, is create something known as a service principle.
So you can create a service principle either via the Azure command line interface or you could do an app registration in the Azure Portal, and you would use this service principle to gain access to the Azure Key Vault. And you could make your application make an API call to fetch the secret from the Azure Key Vault. Now, in our lab, we are going to be performing the following steps: So this is important if you want to make a Rest API call to the Azio Keywall service.
So first we’re going to create a service principle. We’ll be creating something as client access keys. As a result, you can use these keys in your application to authenticate to Azure AD. Remember that Even has a service principle. That service principle is an identity within Azure ad. Now, if your application wants to access an Azure resource, it needs to authenticate itself. So now it’s authenticating itself using that service principle. So it could authenticate itself with the service principal using something known as “client access keys.” We’ll see how to do this in our lab. We have to ensure that we give RBAC access to the service principal for our subscription.
We also have to give access to the service principal for the Azure keyword actions. So there are actions or operations in place in Azure Keyword. In the Rest API, you can assign actions to service principles or even directly to users to perform any operation in the Azure Keyword service. Before we can actually make a call onto the Azure Keyword service, we are going to be using the client access keys to actually generate something known as a bearer token. That token is actually going to authenticate our application on the Azure Key Vault service. And then we make a request to read the secret from the Azure Key Vault. Right? So quite a number of steps Let’s go ahead and see how we can accomplish this. Now, we’re going to be making an incoming call via the Postman Tool. So this is an API call to fetch a secret from the key vault. Now for this, we are first going to get something known as a bearer token. Now for the bearer token, we are going to be using this URL. Now the only thing that you have to replace in this is your directory ID or your tenant ID. We also need something that knows the client ID and the client secret. So let’s go ahead and understand the entire flow of how we’re going to make a request via an API call to fetch the value of a secret in the Azure Keywall Service.
So if I go on to the keyword service, I have a secret in place. So it’s known as a database password. So now I basically want to know what the value of this database password is if I go on to show the secret value. So it’s basically just a password. But now I’d like to obtain this value. So how do I do that? So, the first thing you can do is get your directory ID. So you can go on to your active directory, go to Properties, and get your directory ID from here. So here I have the Postmark tool in place, so I can go ahead and enter the URL. I have to make sure this is a post request. Then, in the body, I need to include the following key value pairs: The first consideration is the type of grant. So the grant type is client credentials. Next. We need the client ID and the client secret. And finally, we have the resource. Stbwater Azure Net is the resource.
So now we need this client ID. and the client’s secret. So in Azure, you could do this via the Azure command-line interface, or you could go on to Azure AD. You could go on to app registration. So it could be the new one or the legacy one. Let’s go on to the new one. So let’s perform a new app registration. So just give the app a name for the app. You can specify a dummy URL. So this is like you’re listing your application, which is going to make a call to the Azure Key wall Service. You can go ahead and click on “register.” Now, if you go on to Clients and Secrets, you can generate a new client secret. Give a name for the secret, click on “Add,” and copy the value.
As a result, the value will be found in the client secret. And now we need the client ID. Now for the client ID. Go on to the overview. This is the client ID. You can copy it from here. Note that in the newer version of the app Restrictions, you can also copy the directory ID from here itself. So now everything is in place. But before we click on Send, we first must perform the other operations necessary to make sure that our application has the required access to our subscription. So let’s do that. So we’ll start with all services and work our way down. Let’s go on to our subscriptions. Let’s go on to our Pay as You Go. Let’s go on to access control. Let’s add a role assignment.
So now that we have chosen the role of contributor, let me search for my application. Let me click on “save.” So now I’m making sure that my application has access to my subscription, right? So that’s one thing done. Now let’s go on to the Azure Keyword Service. Let’s go on to all the resources. Let’s go on to our key vault. Let’s go on to access policies. So here we also need to ensure that a user, a group, or a service principal has access to the operations of our Azure keyword via our access policies. So let’s go ahead and click on “Add New.” Let’s select our principal. So again, that’s our application. So let’s search for a sample app. Click on “select.” You can now grant permissions from this page. Now that we want to give permission for the secrets and I want to make sure that I can get the value or maybe even list the secrets, we can do that. So we’ll choose these two permissions. Click on OK, and please make sure you click on Save.
This is an important step. So now we’ve granted access to the application through our subscription. We have also made sure that our application now has the ability to talk to the Azure Keyword. Now we’ve also made sure that our application can fetch the secret value because they’ve granted access permissions via the access policies. Let us now ensure that we complete one more step in Azure advertising. So let’s go on to our Sample App. Now we can go on to view API permissions. So if we’re going to make sure that we add a permission for the Azure Keyword Service itself, we’ll choose the user permissions and click on Add Permissions, right? I’ll also click on “grant admin consent.” Click on “yes.” So that’s done. After you’ve set all of the permissions, return to Postman and click the Send button to get something called an access token. So this is your complete access token, which you’ve got from Azure. Now we can go ahead and copy this access token. In a separate tab, we’ll make a request to Azure Keyword Service to retrieve the password.
So first, let’s go head-on to the headers. Let’s add the authorization. We have to add the value of bearer, a space, and then the bearer token that we got in the previous request. Now, let’s enter the URL. So the URL is basically our keyword, “namevault Azure Net Secrets.” What is the secret we want to fetch and the API version? Let’s go ahead and click on “Send.” And now you can see you’re understanding the value of a password. So now you’ve made use of a Rest API to make a call to the Azure Keyword Service to get the value of a secret. So this marks the end of this chapter.
9. AZ-203 – Lab – Azure Storage Account Encryption – Key Vault
Hi, and welcome back. Now in the subsequent chapters, we’re going to look at the managed service identity. So what exactly is the purpose of the managed service identity? So let me illustrate this with the help of an example. Now let’s say you have an application, right? Let’s say the application needs to use a key for encrypting data. Or maybe it just needs a password. This could be a database password. So let’s say the application connects to a database. So it needs a password to connect to the database. Now, let’s say that you want to ensure security for your entire environment, so you could store the encryption key or even the password in the Azure Keyword service.
Now, your application, when it wants to connect to the database, let’s say it needs to fetch a password. It needs to fetch the password from the Azure Keywall service, right? So this is a secure method. Now, in order for the application to authorize itself to get the password from the Azure Key wall service again in the application, you have to mention some sort of credentials because those credentials will be used to authorise itself to the Azure Key wall service. So this defeats the entire purpose of actually having a secure environment. So even though you’re securely getting the password from the Azure Key wall service in the application, you still have to mention something, some sort of credentials, to actually authorize getting the password from the Azure Key wall service in the first place. So I said it kind of defeats the purpose. And this is where you can use the managed service identity.
So let’s say this application is running on a virtual machine. What you can do is assign a system identity to this virtual machine. You can then create an access policy in the Azure Key vault requesting that this identity be granted access to possibly retrieve secrets from the key vault. So now when the application needs to fetch the password from the Azure Key Vault service, the application will use the local metadata service. So this is a service that runs on the virtual machine to get an access token. Now, what the virtual machine will do is get the access token via its identity. So it will use the identity to authorise itself against the keyword service, get an access token, which now has the authorization, and an access token can now be used by the application to fetch the password. So here you are not mentioning any credentials in the application itself. And we’ll see this in.NET programmes in the coming lapse to fully comprehend the full use of the managed service identity. So let’s go ahead.
10. AZ-203/ 204 – Managed Service Identity
Hi, and welcome back. Now in the subsequent chapters, we’re going to look at the managed service identity. So what exactly is the purpose of the managed service identity? So let me illustrate this with the help of an example. Now let’s say you have an application, right? Let’s say the application needs to use a key for encrypting data.
Or maybe it just needs a password. This could be a database password. So let’s say the application connects to a database. So it needs a password to connect to the database. Now, let’s say that you want to ensure security for your entire environment, so you could store the encryption key or even the password in the Azure Keyword service. Now, your application, when it wants to connect to the database, let’s say it needs to fetch a password. It needs to fetch the password from the Azure Keywall service, right? So this is a secure method.
Now, in order for the application to authorise itself to get the password from the Azure Keywall service again in the application, you have to mention some sort of credentials because those credentials will be used to authorise itself to the Azure Keywall service. So this defeats the entire purpose of actually having a secure environment. So even though you’re securely getting the password from the Azure Keywall service in the application, you still have to mention something, some sort of credentials, to actually authorise getting the password from the Azure Keywall service in the first place. So I said it kind of defeats the purpose. And this is where you can use the managed service identity. So let’s say this application is running on a virtual machine. What you can do is assign a system identity to this virtual machine.
You can then create an access policy in the Azure Key vault requesting that this identity be granted access to possibly retrieve secrets from the key vault. So now when the application needs to fetch the password from the Azure Key Vault service, the application will use the local metadata service. So this is a service that runs on the virtual machine to get an access token. Now, what the virtual machine will do is get the access token via its identity. So it will use the identity to authorise itself against the keyword service, get an access token, which now has the authorization, and an access token can now be used by the application to fetch the password. So here you are not mentioning any credentials in the application itself. And we’ll see this in.NET programmes in the coming lapse to fully comprehend the full use of the managed service identity. So let’s go ahead.
