Posted by Mike Racine
How to use Managed Identities to access Azure resources securely
Having a crisis of Azure identity? You’d be surprised all the places in Azure where you can make use of Microsoft’s identity tools. In this episode of #KnowOps, Dana shows us the magic of Azure Managed Identities, as well as how to use them to safely use secrets inside of a Linux instance.
So in last week's episode, I showed how to protect your cloud secrets with Azure Key Vault. As part of that video, I demonstrated how to access your secret safely across all your Azure resources using managed identities from Azure Active Directory. Some of the feedback I got was that managed identities were new to many of you. Sebastian even called me out and said, while, this works great for pod services, he didn't know how this could work with IS, especially in things like custom Linux VMs. You can. Let me show you how.
Dana Epp here. Welcome to the channel that helps aspiring Azure administrators like you and me to know OPS and well master the Microsoft Cloud. I'm glad you're here. If you haven't yet, smash the subscribe button so that you can be notified when I release new videos each week.
So a common challenge when working in the cloud is managing credentials, so resources can talk to each other safely. Keeping credentials secure is an important task when it comes to authentication. And no one wants password cruft just lying around. Microsoft solved this with a feature in Azure Active Directory called managed identities. It provides a way for Azure resources to request access from the system without you needing to worry about the backplane of credential management. Behind the scenes, a managed identity is nothing more than a special type of service principle in Azure AD. Deep down, it takes care of the authentication portion using certificates. But you don't have to worry about this as it takes care of all of it for you.
There are two types of managed identities. The first is a system-assigned one, which is enabled directly on an Azure resource. When enabled, it creates a new service principle and its credentials. And when the Azure resource is deleted, Azure AD will destroy the identity and its credentials for you. That's the whole point of a system-assigned managed identity.
The second type is a user-assigned managed identity. It is in itself a standalone Azure resource. It is still provisioned as a service principle, but can be assigned to multiple Azure resources at the same time. And the lifecycle of the identity is managed independently from the resources it's assigned to. This way, you can share a managed identity across related resources. It's really useful when you have ephemeral resources that keep coming up and down all the time and you want a consistent set of identity access controls on the resource.
Why don't we jump into the Azure portal, and I'll show you all this in action.
Okay, to get started here, let's just kinda walk through what this demo is. So I happen to have created a resource group called KnowOps. Inside of that I have a Linux based virtual machine, which I've called kopsvm, and of course everything that goes with it, it's disks and all of its normal stuff, networks and everything. I also have this Key Vault called kopskv. And inside that Key Vault, we can see that there's no special access policies right now, other than myself as a user. And I have a secret in here, this one secret, which is called MySecretPass, okay?
Now what I wanna do is I want to demonstrate how to get that secret out of Key Vault from within a Linux based VM, using a user-assigned managed identity. So there's a couple ways we could do this. The first one obviously, would be, we can just create a new resource and just go, managed identity. And there's a user-assigned managed identity, and I could go through the process of creating that. But I don't wanna do it. What I'm gonna do is do this in the Azure CLI. And if I was to just go and type az identity, I have the ability to create in that group called KnowOps, a new identity which I'm gonna call kops user-assigned managed identity, or kopsUAMI. And we just let that run.
So you can see it in this created that identity for me, it has a client ID, the URL to the client secret it relates to the certificates, it's behind the scenes, principal id, the tenant id, everything that's there, which is useful. If I go back to the portal and look at my all resources, do a refresh. We can see it right there. And so one of the interesting things to know is where a system-assigned managed identity is attached to the resource itself, there is no way of seeing that resource because it's attached directly and managed through Azure Active Directory.
When you create this user-assigned one though, it is in itself its own resource and it can then be reused and applied. And, applying it's not that hard, we can just simply go into the virtual machine, then go into the identity blade. And we can make a decision if you wanna use a system-assigned or user-assigned identity. But I don't actually wanna do that just yet because I want to demonstrate that when I'm inside the virtual machine, I don't have access to the Key Vault and I can't do anything until I get an access token issued to me from Azure Active Directory, which can only happen once I have some sort of principle that authorizes me to have that.
So if we jump back over into here, and we start maybe just by taking a look at the VM and seeing that nothing's assigned to it, I can do that by going az vm identity show. And we call that VM kopsvm. And it will return nothing because there is no managed identity assigned to it yet. Now, let's go jump into that VM itself. I'm gonna ssh over to it. Now, just to speed things up, I've actually created two scripts here. The first one's called getToken and the second one's called getSecret. And the idea here is I want to be able to get the token directly from Azure Active Directory.
Now it ends up that through the built in backplane, Microsoft has something called the Azure Instance Metadata Service, which allows us to have a non-routable ip that we can call into to get access to the Identity Service. So if I was to just edit this script I wrote, you can see how it works. I'm just going to curl or I'm going to go fetch from a service at 169.254.169.254, which is that Azure Instance Metadata Service. I wanna go to the metadata identity oauth2 token endpoint. And I want to ask for a token for the resource, in this case vault.azure.net.
So I wanna basically get an access token authorizing me to talk to the Key Vault. And to do that, I need to have the managed ID's client ID. So we can get that back over here. You saw when it first created that managed identity, there was a whole bunch of data that popped out, but you can always go get it later. az identity show, minus n kopsUAMI. And I'm just gonna pipe this to a little tool that does parsing of JSON, which is how that comes back normally, and I wanna just grab the client ID. And there it is. So this is the dedicated client ID for that managed identity. And I'm going to go put that in the script. And if I run that script now, in itself, this should allow me to go and fetch a token, right? Well, let's watch what happens.
See, it's not, no identity was found, we haven't actually assigned an identity to the VM. And so it's not gonna quite work. But that's okay, we can easily just go and assign that identity. So again, if we go back, we were already here. If we go to user assigned, and we say add, there is that kops user-assigned managed identity. And now that the VM has that managed identity assigned to it, if we go back and try running that again, well, I now have that access token. Let's make that a little cleaner.
So this access token would allow me to talk to the Key Vault since that's what I'm asking for access to the resource. Now, this isn't actually going to work. Now, let me show you why. If I was to... The other script I have was one called getSecret. What this is gonna do is go directly to that Key Vault, kopskv.vault.azure.net, to the secret called MySecretPass, and I'm passing in for a header, the Authorization token, that's an access token to the system. Now this would normally work except that remember, I haven't authorized that managed identity access to the Key Vault yet. So if I was to run this, and I need to pass in the access token.
So what I'm gonna do here is just do a little bash foo here, and I'm gonna call into that getToken. And we're going to kinda parse that access token out. So now we're going to be sending the access token to getSecret, we're gonna go fetch it. But, it's not gonna get us the secret we want. And watch what happens. Gives us a no. And that makes sense, because we're not actually authorized to do that. Behind the scenes, there is an event that has been written to the Key Vault telling you that access was not authorized for this identity. Now, let's jump into that Key Vault. Let's take that managed identity and give it an access.
Now, we've given that user assigned managed identity access to read secrets for this Key Vault. And, without needing a password, without needing to worry about certificates, by simply having access to the Azure Instance Metadata Service inside of that Linux VM. I got my password, in my case here or there.
So there you go Sebastian. Secure access to secrets and Key Vault without needing an unknown password can all be done in a Linux VM by using managed identities. Isn't that pretty sweet? Hope that helps you. I hope I've opened your eyes to the power of managed identities. Give it a try yourself with your own Azure resources and see what you can do.
What do you think? Was this helpful? Let me know by hitting the like button. And if you haven't yet, smash the subscribe button so that you can be notified as I publish new content each week. Until then, thanks for watching, and keep the feedback coming. Who knows, your comments may be featured in an upcoming episode. We'll see you in the next one.
Having a crisis of Azure identity? You’d be surprised all the places in Azure where you can make use of Microsoft’s identity tools. #knowops @auditwolf