- 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. (upbeat music) 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. (soft music)
Just wanted to say I like your video. Keep up the good work.
Would it kill you to smile, Dana?
If he smiles Dana’m gonna cry lol
Nothing wrong with this video but it's crazy most of these MSI examples use Key Vault and only very rare few actually show how to use MSI for calling your own services.
There things get really shady with having to create roles by directly editing the Enterprise Reg manifest JSON and only being able to add the client apps via CLI since the UI only lets you authorize users and groups.