AZ-204 Microsoft Azure Developer Associate – Implement Azure Security part 2
- AZ-203 – Lab – Azure VM Disk Encryption
Hi and welcome back. Now, in this chapter, we are going to go through disk 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, so 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 disks are encrypted using Azure disk 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 a vault, an existing vault, which I have of demo Vault 990. Now, before we can actually go ahead and execute the command to enable encryption of the volumes on the Azure Virtual Machine, we have to go on to access policy. So there’s one setting that we have to ensure or to implement. So we have to go and enable Azure disencryption 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 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 is the name of the key vault. Let me go ahead and execute this command. So over here, I’m going to execute the command for Enabling disk 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 onto the virtual machine. Let’s come back once this command has been executed.
Now, after some time, once the command has finished executing, if you now 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 now see that there is a lock symbol in front of both of the volumes, both 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 now encrypted at rest so this marks the end of this chapter.
- AZ-203/ 204 – Lab – Azure Key Vault – Invoking via API calls
Hi and welcome back. Now in this chapter, we are going to see a lab on how we can access a secret stored in the ASIO Key Vault via an API call. Now, before we actually dwell into how we’re going to be doing this, just a quick note in terms of ASIO ad. Now, in Azure ad, you have three types of entities that you can create from 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 to 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 onto the Azio Keywall service. So first we’re going to be creating a service principle. We’re going to be generating something as client access keys.
So you can use these keys within your application to authenticate onto Azure ad. So, remember, 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 principle 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 for the service principal for the Azure Keyword actions. So there are actions or operations in place in Azure Keyword.
You can give actions onto service principles or even on to users to perform any operation in the Azure Keyword service in the Rest API. 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 onto 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 a rest 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 has 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 known has the client ID and the client secret. So let’s go ahead and understand the entire flow of how we are 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, so I have a secret in place. So it’s known as database password. So now I basically want to get what’s the value of this database password if I go on to this, if I go on to show the secret value. So it’s basically just password. But now I want to get this value. So how do I do that? So, the first thing you can do is to get your directory ID.
So you can go on to as your active directory, go on 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. And then in the body I need to go ahead and add the following key value pairs. So first is the grant type. So the grant type is client credentials. Next. We need the client ID and the client secret. And finally we have the Resource. And the resource is Stbwater Azure net. So now we need this client ID. And the client secret. So in Azure, so 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 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 Keywall Service. You can go ahead and click on Register. Now if you go on to Client and Secrets, you can generate a new Client secret. Give a name for the secret, click on Add, copy the value. So the value will come here 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 do the other operations of making sure that our application has the required access to our subscription. So let’s do that. So first we are going to go on to all services.
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 if we choose the Role has 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 Azure Keyword service. Let’s go on to all 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 to 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 sample app.
Click on select. Now here you can give permissions. Now since we want to give permissions 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. An important step. So now we’ve given access to the application onto our subscription. We have also made sure that now our application has the ability to talk to the Azure Keyword. Now we also made sure that our application can fetch the secret value because they’ve given the access permissions via the Access Policies. Now let’s make sure that we do one more step in Azure ad.
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, so we’ll choose on the user permissions, click on Add Permissions, right? I’ll also click on grant admin consent. Click on yes. So that’s done. Now, once all the permissions have been set, if you now go back to Postman and you click on the Send button, you now get something known as 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. Now in a separate tab, we are now going to make a request to fetch the password from Azure Keyword Service.
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 which we got in the previous request. Now, let’s enter the URL. So the URL is basically our keyword name vault 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 getting the value of password. So now you 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.
- AZ-203 – Lab – Azure Storage Account Encryption – Key Vault
Hi and welcome back. Now, in this lab, we are going to see how we can encrypt the data on a storage account using a managed key from the Azure Keywall service. Now, in Azure, the data at rest can be encrypted. This is an added security option. So when the data, let’s say, in the Blob service is finally stored on the physical service in the Azure data center, it will be encrypted at rest so that even if a malicious user were to get hold of the data, they would not be able to decrypt the data without the encryption key. Now, automatically, Azure can create its own encryption key, encrypt your data, and manage the key on its own.
You don’t have to think about managing the key that’s used for the encryption and decryption process. But sometimes companies want to have a little more control wherein they should be the owner of the key that’s actually used to encrypt the data in the storage account. In such a case, what you can do is that the organization can create a key vault or use a key vault service. They can then create a key in the Azure Keywall service, and that key can then be used to encrypt the data in the storage account. Now, one more very important aspect to understand is the authorization. Now, in order for Azure Blob to fetch the key from the Azio Keywall service, the Azure storage account needs to authorize itself to the Azure Keyword service to fetch the key.
Now, in this case, what we’re going to see is that we’re going to see how to use the manage service identity so we can assign an identity to the storage account. And that identity can be used to authorize itself to the Azure Keyword service. So we’re going to go ahead and issue commands to actually implement this scenario. So here we are in Azure. So let’s see how we can actually encrypt the data in a storage account using a key in the Azure Keyword service. Now. I’ve already gone ahead on to cloud shell. Let me execute the first command to go ahead and create a key vault. So I’m going ahead with this command to create a new Aze your key vault. I’m giving a name to the vault mentioning the resource group and the location.
Now, the Enable Soft Delete actually ensures that there is a retention period in place for those objects in the key vault which are deleted. So if anyone wants to recover objects in the keyword that have been deleted since the last 90 days, they can actually fetch it. If the Enable Soft delete is present on the Azure Key vault, the enable purge production ensures that any object in the vault which is in the deleted state cannot be purged until the retention period of 90 days has passed. So let me go ahead and execute this command now that we have the keyword in place. If you want. You can click on Refresh over here. And now you can see we have the Azure Key vault.
Now please note it’s saying that no access policy is set on the key vault. And that just means that if you go on to the key vault, if you go on to access Policies, there is currently no policy in place. This means that no user or no application has access to the key vault. So we’ll set the access policies as part of this exercise. Now the next step is to ensure that we set the Azure Storage account, that we have our demo store 2020 to have an identity assigned to the storage account. This identity will then have access to the Azure Keyword service. So let’s go ahead and assign an identity to the storage account. Once we have the identity in place, we now set the access policy for the key vault, this time to the identity that has been assigned to the storage account, the principal ID.
And we’ll give permissions to wrap the key, unwrap the key, get and recover. So I’m going ahead and executing this command. If you click on Refresh for the key vault, you can now see that we have one policy in place and you have the four permissions which have been assigned to the identity of the storage account. Now, what I’m also going to do is that I’m going to assign my user. So currently I have logged in with my root account. I’m going to give myself permissions to the Azure Keyword itself. So this is the principal ID of my account. You can actually go on to Azure ad, so you can go on to users. You can go onto your account that’s your main account and take the object ID.
So that’s what I’ve done for my particular username. So let’s go back to all resources. Let me go back onto the key vault. If I go on to access policies, if I click on Refresh, now I can see my application and my user has access to this key vault. Now I’m going to go ahead and create a new key in the key vault that will be used for encrypting the data in the storage account. And then finally, I’ll go ahead and ensure that the key is now affiliated with our storage account. Now, once this is done, you can actually go on to the storage account. If you go on to encryption, you can now see that it’s made to use your own key. And here we have the Uri of the keyword service, right. So this marks the end of this lab.
- AZ-203/ 204 – Managed Service Identity
Hi and welcome back. Now in the subsequent chapters, we’re going to look at the manage 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 for encrypting data. Or maybe it just needs to get a password. This could be a database password. So let’s say the application connects to a database. So it needs to have 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 Keywall service again in the application, you have to mention some sort of credentials, because those credentials will be used to authorize itself to the Azure Keywall service. So this beats the entire purpose of actually having a secure environment. So even though you’re securely getting the passage from the Azure Keywall service in the application, you still have to mention something, some sort of credentials to actually authorize to get the password from the Azure Keywall service in the first place. So I said this kind of beats the entire purpose. And this is where you can use the manage service identity. So let’s say this application is running on a virtual machine. What you can do is that you can assign a system identity to this virtual machine.
You can then create an access policy in the Azure Key vault saying that please give access to this identity to maybe fetch 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 that it will get the access token via the identity. So it will use the identity authorize 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’re going to see this in. NET programs in the subsequent lapse to fully understand the full use of the managed service identity. So let’s go ahead.