Microsoft Azure Managed Identity Deep Dive

hey everyone welcome to this video all about managed identities gonna dive into why we have them and how to use them as always this is useful please give this a like subscribe comment and share and hit that bell icon to get notified of new content so let's think about why we want this managed identity in the first place we can take a step back i can think about the big azure cloud so i've got azure and obviously in azure we can have many types of resource but for right now i'm not going to worry about the exact type of resource just that i have a resource so i have some resource running in azure this could be a virtual machine it could be a serverless function a web app doesn't really matter and the point is inside that particular resource i have an application so i have some app running and that application wants to be able to access other types of resource i can think about well there's another resource over here that i want to access now remember those resources have their own sets of role-based access control that configures well what different security principles can do what rights do they have can they read can they update certain types of actions so that's all defined in there and so to use that what do we need well that application has to have some identity it has to have been authenticated to be able to present an identity to actually get permission to something and there are different ways to achieve this but our ultimate goal when i think about managed identity i want to get rid of the pain about storing a secret storing a certificate managing the life cycle rotating rolling any of that and even when i think about azure key vault which is fantastic for storing secrets and certificates i still have to initially authenticate to the key vault to get permission to access that secret so it's not really a solution to my initial problem i get that chicken and egg problem so how did we solve this well the traditional approach is i have a service principle i can think about i have my azure active directory so we have azure ad over here and the way we would do this is i would create an application registration so in my azure id i would say okay i'm going to have this new app and i would have this app one registration now when i create an application registration i can say is it single tenant or multi-tenant in fact if we jump over really quickly if i go and look i can see my app registrations when i do a new app registration it asks me straight away hey who is going to use this is it only my directory is it multi-tenant is it multi-tenant and microsoft accounts and i have all those different options available to me but i create an app registration in my case we're going to focus on this rbac test app registration i can go and create that app registration now what that also does is the app registration is this global application id but then within my tenant what it also is going to do is for that app registration it's going to create a service principle so the service principle is a representation of an app instance just happens to be in the same tenant as that app registration itself and we can see these so if i jump over and look at some code for a second i'm going to use microsoft graph so i've already installed the microsoft graph various modules we have to connect to the microsoft graph and we have to tell it a scope i want to be able to access applications so i'll pass it the application.read all scope i've already connected i'm then going to select the beta profile gives me access to a few extra things i can see my context now the only thing i really care about here is my tenant id because when we look at the app registration we'll see it's in my home tenant i can also look at the various scopes i have enabled and one of those core ones that i requested specifically was that application dot read all this is really just some background information now what i want to do is i'm going to go ahead and look at that application so here we can see that our back test app registration that is the app registration i've made and i can see that id over here and notice the sign in audience is just azure ad my organization so it's just scoped for my tenant but there's also a service principal was created with the same name as the app registration so i'm now going to do is search for a service principal named our back test app registration and if we look at this service principle we can see sure enough i have it so i have a service principal and the app owner organization id over here remembers that ba2111 well that was my tenant id so that's mapped to my local organization so what we have right here is an app registration so i wanted some account that i could use for my application so we did an app registration that also creates a service principle which is just the instantiation of the app in my tent so that now exists now when you go and add an enterprise app it's really doing the same thing so if i think about enterprise applications there's many different types of enterprise app i can add but very commonly we'll add one from the catalog and that's just an application remember the application is globally unique that some other tenant has enabled for multi-tenant use you can see i've got hulu and netflix i have microsoft teams in here all these different applications so when i think about what is an enterprise application again it generates a service principle at this time i can think well actually there was another someone else's azure ad tenant over here so this is my azure ad tenant this is someone else's and what they did in theirs they created an app registration for their app it would have also created a service principle in their home tenant but now if i add that application to my azure id i want to light it up what it's going to do is create a service principle in my azure ad that represents that globally unique identifier and once again we can see these so if we want to look at the code again this is again just some fun background i can dump out all of the service principles and this i'm going to search for netflix or microsoft teams because i've enabled those in my organization and once again what you're going to see is hey look there's a service principle for both of those we can see the display names we can see the ids we can see the app ids but notice the app owner organization ids are different because the app is actually defined in someone else's azure id but it creates a service principle in my azure ad to represent that particular application so this all makes sense that this is the idea of okay great i can create a service principle and the point of once i have the service principle is how does my app use that service principle how does it authenticate as it so i have the service principle and i can add basically ways to authenticate with it i could add something like a secret i could use certificate based but the challenge then becomes how does the application store that secret or store that certificate in a secure way that it can then authenticate to azure id as this security principle and then pass that secret or certificate maybe i could use something in the resource that has some encrypted maybe environment variable or something else but it's really not ideal that's certainly an approach we've done in the past we would use a service principle via an app registrations that's what we used to now there are patterns that do solve this for example with kubernetes it now has native ideas of service accounts that kubernetes can give out a token to a pod and then through open id connect federation i could then take my kubernetes issued token and exchange it with azure id for an azure id issued token because now there's an oidc federation it can validate it and that is one approach to solve that problem of having to store that secret but for now let's think about managed identities so how does managed identity solve this well what i can now think about is on a resource i can just turn on an identity that azure is going to manage i can basically click a box i can say well what i'm going to do is turn on now don't worry about this phrase right now i'm going to turn on a system assigned managed identity yes i want that managed identity as soon as i do that what's actually happening is in azure ad it is now creating a service principle it's creating a service principle because it's system assigned is creating a service principle with the same name as the azure resource this would be called res1 because this resource was called res1 now because it's system assigned these now have a linked life span so this resource is now linked these are linked they have a shared life cycle when i delete the resource it would delete that service principle as well there's no secret there's no certificate i'm having to store or worry about this is now a security principle in azure id that only something running in this resource can get a token for because it is a service principle it can now be given permission to other resources so this resource too hey in its role-based access control i can now say well let's give the resource one service principle that manage identity a permission maybe i'll give it reader more likely it might be something a data plane some kind of data blame playing permission so we can actually do things that could be a vm it could be a serverless function it could be a web app there's actually a huge number of azure services that support this if we go and look at the documentation it goes through all the different azure services that support managed identity and does it support system assigned or user assigned which we're about to get to exactly what that means but the key point here is look at how many there are and you'll also notice that word azure arc in some of them as well this isn't just things running in azure it's also going to support azure arc but a crazy number of services can use this managed identity and when i think about well what can actually use it if the resource supports azure ad authentication and role-based access control i will be able to give that managed identity permission to it so it really is pretty much everything now there are two types of managed identities i've kind of alluded to already there is the system assigned the system assigned i just enable for a resource so if i think about the types available to me system assigned here i can think the idea is there's the managed identity and there's the resource they are linked together one to one a system assigned managed identity can only be used by one resource and a resource can only have one system assigned managed identity the life cycle is shared if i delete the resource that system assign managed identity will be deleted as well the other type is a user assigned with a user assigned i actually create that managed identity as a separate resource i can actually go in here and i'll say hey i'm going to add a user assigned managed identity i'll just call it user side managed identity one and what i then do is i assign it as the name suggests as a user to resources i'll say well this measure density i'm gonna let you use as well it's user assigned i might also have another resource hey i might have resource 3 down here that same user assign managed identity are going to assign to you as well so when i think about what this means so resource 1 has a system assigned and now it can have user assigned mi1 now this resource could optionally have a system assigned or maybe it only has user assigned mi1 as a managed identity so relationship now is a little bit different now i can think about this idea that okay i have multiple user assigned managed identities so i can have user assign managed identity one user assign managed identity two and the key thing here is that single managed identity i can link to multiple resources i can link it to n resources and likewise a resource can actually be linked to multiple user-assigned managed identities so it's end to end i can have multiple user assigned managed identities the benefit of the user assigned is well with the system assigned it's a one-to-one only that one resource can use it so it's useful hey i have a resource that i need to give permission to certain resources great but now imagine i have a whole set of resources that need the same permissions to a group of resources i don't want to have 10 system assignments identities and have to give the permissions 10 times it could be a farm of web servers or middle tier servers whatever that might be it's much better to create separately so this user time managed identity has its own life cycle i create that user assignment identity object it exists on its own right it's not tied to any resource i can then give it permission exactly the same way i could give it permission to okay you have permissions maybe i'm going to give you contributor or blob data reader whatever role i want but now all of the resources that have been assigned to be allowed to use that user site managed identity would now have that permission so it's far more efficient when i want to give multiple resources the same sets of permissions so that's really where i would think about using this i want to share those resources again i can have both i can have a system assigned and multiple user side managed identities and i give it some kind of scope let's have a quick look at this if we go to the portal firstly let's look at a user science if i search for managed identities now is it showing me i have a user assignment identity i've already created so i've created a managed identity what i can see from here is if i look at the properties i can see all the details about it it's resource group subscription i can see roles i've given it what i can see from here is i've given it secrets user so i can read some secrets and i can see the exact secret i have blob data reader on a certain storage account so i've given it some permissions so now any resource that's allowed to use this managed identity would have those permissions when it gets tokens as that likewise if i was going to look at a resource let's just look at my demo vm if i go and look at identity well my system assigned i just flip it to on and it now has a system assignment identity i can go to the user assign tab and i can add managed identities that a user assigned to enable for this resource it's very simple to do if i looked at a different resource hey it's system assign management identity is turned on doesn't have a user assigned but if i wanted to hey i'm going to give you permission to use this particular user assign managed identity as well and then i can give it permissions just like anything else now just to show a point if i look at azure functions for example it has exactly the same idea of identity once again i can give it the system assigned that would be the same name as the resource i could add user assigns to it and then those match identities are just service principles they are identities in azure id that can be given permission to things a simple way to look at this is storage accounts for example if i look at my containers i could pick a certain container for example i can look at my access control and i could add a data plane role but it could be a control plane as well i'm just going to add a role assignment i pick the role i want to add so i could really pick any of these it doesn't matter we'll say storage blob data contributor and then i pick the members the key point here is when i'm doing this search this would be regular users and service principles for example if i typed rbac you can see my regular service principle i have over here but when it's a managed identity i select managed identity then i hit select members and now i say well is it a managed identity that system assigned for a certain type of resource i.e if it was virtual machines i'd click vms then i would see the manage identity for vms if it's users are assigned i select user assigned and then select the user assign managed identity so it's just really a different option i select when i'm doing the assigned to but the net effect is i'm giving it role assignments if i scroll down and look over here notice reader my user assigned managed identity has the reader permission if i keep looking down i can see hey look the manage identity for my vm has storage blob data reader permission and the user assign manager identity has blob data owner permission as well sorry block data reader permission as well so i've given those managed identities permissions to resources and it really works across anything because under the hood these are just service principles there's really nothing super special about them the difference is it's not tied to an app registration if you remember a regular service principle is tied to an app registration a managed identity is not there is no app registration imagine identity is not multi-tenant it only can exist within the realm of the tenant in which it's created we can see it if we jump to our code again and take a look and this code is in the github repo in the description i i linked to all this code i did think a little bit fun i also created a markup version of the code with a little bit of extra description if you're just curious about it you can look at the md version ctrl shift v will show it in the nice markup mode in vs code but i can go and look at all of the service principles and it is a special type it's a type managed identity so if i go and do a get for all of the service principles well look here they all are i can see hey look there's my user assigned one there's that function i showed and there's my vms but i can see all the different managed identities for different resources i have in my subscription so these are just service principles i have in my environment now they are special though they are by the very name managed even if i'm a global administrator i have no permissions on these service principles i can't do anything to it it is managed by this resource provider for managed identities now you may have noticed it does have an app id so if i go and look at these slightly differently so i'm going to do now is let's look at a particular one so if i scroll down i'm going to get a list of the user assign managed identity and i want to get it for my demo vm so a system assigned so i'm going to get one user assigned and one system assigned and i'm not going to output these now i said there is no us app registration but you'll notice well john you're lying because it says app id well that is just a randomly generated good it's there to stay consistent to the app registration service principal model but it is completely randomly generated it does not exist if i try to get the application for that app id it doesn't exist it is not there so although it has a value it is just there to keep consistency with the model it does not actually exist so how is this managed what is happening behind the scenes well behind the scenes what we have is a managed identity resource provider and that managed identity resource provider is responsible for the management of all of those managed identities and what this is really going to be doing when i go and create a managed identity it is going to do the issue of the cert to the managed identity so there is a certificate it is responsible for issuing that cert to the managed identity when it's created it is also responsible for rolling the cert periodically so periodically this will go and roll the certificate that is used to authenticate to that managed identity so let's see this in action it's probably easy to understand if we can actually go and see well how does this actually work so what i've got is i'm going to use a virtual machine again virtual machine is just one type of resource that i can use for this it's a very easy one to demo but all of those different types of resources i've shown could be used for this so i'm going to head over to this virtual machine that's running in azure now first thing i'm going to do is this virtual machine is demo vm now this was the one i actually showed earlier so if i look at my virtual machines what we're focusing on here is this vm and from an identity perspective i turned on the system assigned and i gave it access to that user assigned so when we dumped out the code earlier and we looked at those managed identities these are the two that we're actually dealing with this vm has access to both of those because it is demo vm it's the name of the resource and it's been given access to mi savile tech 1. so now i'm inside that virtual machine i don't have to know any certificate or secret i'm just going to go and say hey i want to connect as my identity and it's done that and if you look at the account what you can see is it's connected as msi 50342 it has connected through let's close off the little comment at this point i could go and look at my context as well hey we can see i'm connected to there's that account again i can see my tenant id now if you don't specify an identity when connecting which is what i did right there if the resource has a system aside managed identity that is the identity it will authenticate as if it doesn't have a system assigned managed identity and has one user assigned managed identity it will authenticate as the user assigned managed identity if it does not have a system assigned but multiple user assignments identities you have to specify which identity you want it to authenticate with it won't know by default it will fail so if it has a system assigned by default it's always going to use that if it only has one user assigned and no system assigned it will authenticate as that no system assigned multiple user side i have to tell it which identity to use so let's carry on this demonstration so if we go back over here what we've got now is well firstly i can go and see that user assignment identity sorry system assigned i'm going to get the details of my resource and i've got my principal and it's showing me there's the principal id that 177c83 whatever that is that is the identity of my service principle which once again that 177 well it matches the id we have over here so for demo vm it's system assigned was that 177 we can see that is matching through so so far so good we're seeing what we would expect to see i now want to actually test well can i connect to something storage account now what i did for this storage account i showed this before is i gave that managed identity permission on the data plane if we jump over one more time super quick if we look at the storage accounts that i have in this environment and i go and look at my containers and i look at images which is where we're going to look at if we look at the access control my role assignments when we look at the data plane permissions ie storage blob data reader i gave the managed identity of that vm permission and that's what we're going to be leveraging so we're authenticated as that identity so now if we jump back over again all i'm going to do is say okay well let's create a storage context using my current connected account so i'm specifying that so i don't have to pass an identity it's going to use who i'm currently authenticated as and then what i want to do is i'm going to try and copy a file now currently if i was to look in my temp area i have no files so from here let's try and copy this file into my temp area so it says it succeeded so if i go and look it worked so as that managed identity i was able to access another resource that had role-based access control to that permission so that proves that idea now what's super common i talked about kevo earlier a very very common pattern we'll do is well i have keyboard there are some things that won't support azure ad-based role-based access control they still have a requirement that i need a secret i need some signature i need something else so what's very common is hey okay i have my azure key vault i have a secret and on that secret i'll give that managed identity the permission to read a secret or interact with it in some way so now the application inside can actually go and use that secret and once it has the secret it can go and connect to some other resource using whatever was in that maybe that signature that password whatever that might be so let's see that in action so now i can think about back over here i'm going to try and access a secret in key vault so if we go back to our look over here this time let's look at our key vault first so if we look at the key volts and remember with the new role based access control model for kivo i can give permission at a per secret level so my access policy i'm using the new azure role based access control model not the old vault access policy what that's going to let me do is add a per secret so if i look here secret one access control i have given key vault secrets user to demo vm so i can read that secret if we look at secret two well i don't have that permission i have no permissions over there for my demo vm so if we hop back over then let's try and use it so i'm now going to try and look at secret one so you can see over here i'm looking at secret one in that vault and we're just going to try and get the value okay so let's get that secret and then let's write that out and it worked my super secure secret is password fantastic now i'm doing this through the powershell you can absolutely do exactly the same things through restful apis in fact it's using that instance metadata service here i'm saying hey i need a token and i actually need a token for a particular type of resource i want a token for a particular vault i'm going to go and talk to the volt is my target so just to show you another method i'm going to go and get a token and then once i have my token i'm going to quickly get the content then i'm going to extract the token and now i'm going to invoke a restful call passing the token i got from the instance metadata service and once again you can see i could go and get the data so it's not just like powershell that this works for it's really going to work for anything that i want to do now you'll notice in that example i was directly talking to the instance metadata service to get the token and that's actually how this works for a virtual machine at different types of resource use different methods but if i think about how does this actually work behind the scenes my application wants a token my says to something or i want a token well what it's talking to for a vm is the instance metadata service and it says hey uh token please at that point what happens is this metadata service it talks to the managed identity resource provider says hey i need to go and authenticate to azure id for resource one the measure density resource provider then passes back the service principal id for resource one and the serp remember that it's the one issuing the cert and it's the one rolling the certs so it gives it to the instance metadata service the instance metadata service can now take that service principle id and the certificate and talk to azure id so it says hey here's the service principle here's the cert i all of the things i need to authenticate i want to authenticate azure id will then create me my access token give it to the instance metadata service who now has the token and gives it to the application so that's actually how this is working behind the scenes it now lets me say hey great so from a vm perspective i don't have to know anything i don't have to know my service principle i don't have to know a certificate i just say hey i need a token metadata service knows to talk to the managed identity resource provider that will give it the service principal id and the serp it will then go and talk to azure ad to authenticate on behalf of the resource gets the token and gives it to the application the application now having an access token i can now use it to get access to other things and that's the whole point of this let's carry on this is also the system assigned at this point let's try another secret now let's try and access secret two so here's secret two and again i'm just going to try and get the plain text and it fails i do not have permission because remember the permissions that i set on that key vault gave me permission to secret one but i didn't give any permissions to secret two secret two and let's look at secret two what did we do for secret two but we gave permission to the user assigned managed identity so let's use that instead because my vm has permission i granted it the ability to use user assign manage identity one remember yes i have my system assigned but i also enabled a user assigned mi savile tech 1. so let's use that instead now inside that resource what i'm going to do then is what i need to authenticate as that managed identity instead so the first thing i'm going to do is i'm now going to connect as a different identity now i have to do a few things i have to get some information about that so i know the resource group it's in i know the name of the managed identity i'm now going to get the detail of that user aside managed identity and i can just output that so there is that user assigned managed identity so now i'm going to do that connect az account identity but i'm now going to pass it the client id so that's the bit of information i would need i would need the client id of a specific user assigned managed identity i now need to tell it well which managed identity do i want to get an access token for so now i'm passing it that particular id and now if i look at my context what we now see from my account is it's different it's now this 6ft db blah blah blah which if we go back and look at our code cf4db blah blah we're over there that kind of random id so now i'm using a user assigned managed identity so let's try and access that secret again now i'm going to try and access secret two it did an error and i can see the value so now we can see that idea that i could actually go i could look at the secret x2 and it showed me the value knew a secret because i used a different managed identity and that was really the key point to how all that is functioning now once again i'm talking about the vm idea a vm or vm scale set something running on those has an instance metadata service that 169 254 169 four and it goes and talks the match identity resource provider gets the detail and goes and gets the access token and passes it back but that's just for a virtual machine other services do their own thing if i'm a functional web app there's an end point that i go and talk to there's different methods but they're all working in a very similar fashion there might be a different way to get the token there are articles about it so if i jump over here this is how to use a managed identity for a vm for example to get an access token and it talks through all of the different records i could do that hey i could use c sharp java go etc but if you go and search for functions or web apps or anything else it will show you the code to actually go and get the token now when i talk about tokens as a user we always think about like an access token and i get a refresh token because that access token is short-lived it's like an hour and i use the refresh token to go and get a new token this doesn't apply here i'm only getting an access token this is the app only token flow but it doesn't behave like a regular user because i can think about this is a azure resource in a very controlled managed environment so manage identity is doing a number of different things here that makes this more resilient and i covered all of this in my azure id resiliency talk i did a few weeks ago so i would recommend you go and see that fundamentally when i go and get tokens i'm talking to this evolved sts secure token service now that service there's different global instances of that there's the whole idea of certain gateways in front of it and that's how i go and get tokens well there are also an estr a regional version of that token service that doesn't have to go via the gateway that's in every region but only a very few number of services can use that regional version the benefit there is i'm no longer worried about the global gateways the global service i can go directly to this local regional version well managed identity uses that manage identity uses that regional ests also this token it gets is long-lived it's a day by default but what it also does is it proactively refreshes so my managed identity my app when it gets this token this token is actually a day but it will proactively refresh so once it gets to halfway left let's say 12 hours it will go and refresh it it will say hey um halfway i need a new token and it will get another token with a 24 hour life span that gives me this great resiliency if there are problems if i have an hour token and there's an azure id issue that lasts two hours i have a problem if my token always has a minimum of 12 hours of life left because of that proactive refresh halfway through that'd have to be an azurity outage of 12 hours before it would impact me and that's what management density uses so i get this fantastic resiliency from azure id problems which is why when there have been azure 80 problems management densities carry on working for those two reasons it uses the regional ests that evolved security token service but it has a long-lived token that is proactively refreshed so it always has 12 hours of spare left that's one of the huge reasons we recommend using a managed identity it's better from a security perspective i'm not trying to as the app store a secret or a certificate it's easier to use but it's far more resilient because of that regional ests that long-lived token that proactive refresh so already talked about how this works hey it's talking about identity resource provider other types of service like functions web apps they have a rest pro school to talk to an end point best practices if it's just a resource needs a set of permissions then you can use the regular system assigned manage identity as soon as i get to the pattern where i have multiple resources needing the same sets of permissions if you think i have a pool of servers all doing the same thing that need the same permissions to other resources then use a user assign managed identity because now i'm just assigning it once i define those permissions once the user assigned and then let multiple things use it additionally obviously the use of assignmental density is a separate life cycle it's it's own object that may be preferred for some circumstances where i want to go and set up those permissions in advance give it to the resource and the resource can use it straight away as opposed to having to create the resource turn on the identity then try and give the identity permissions to things it may make certain things harder to do in the overall flow so anything running in azure of all those different types i mentioned can take advantage of the managed identity now we did see in the picture it works for azure arc as well i think today it's system assigned only basically there's a hybrid instance metadata service and other resource providers that push the identities to the on-premises machines there's still a certificate that has to be managed protected but it's now handled by that arc infrastructure but it's the same end user experience so i can use this both in azure and where i'm leveraging azure arc and that's really it i mean we talked about a lot of different things but the key point here is if i'm one of those supported resources the manager identity enables me to just seamlessly have anything running inside it to go and get access tokens that are highly resilient very easy to use very secure to go and get permissions to use other things if you do have a type of resource you're trying to access that doesn't support azure id based our back that needs a password or something else well then you could integrate with key vault store that secret or something else in key vault protect the secret or the cert with our back tied to the match identity they can go and get the secret and use it for other things so that was it i really hope this was useful until next time as always take care you

Channel: John Savill's Technical Training

Views: 69,157

Keywords: azure, azure cloud, microsoft azure, microsoft, cloud, identity

Id: rC1TV0_sIrM

Length: 48min 40sec (2920 seconds)

Published: Tue Jan 18 2022