Hello and welcome to the let's talk. Azure podcast with your host Sam Foote and Ann Armstrong. If you're new here, we're a pair of Azure and Microsoft 365 focused it security professionals.
It's episode 23 of season five. Sam and I had a recent discussion around improving programmatic access using managed identities for Azure resources. Here are a few things we what is programmatic access? What methods are usually used for programmatic access in Azure? And what are Maj identities for Azure resources and how can they be used?
We've noticed that a large number of you aren't subscribed. If you do enjoy the podcast, please do consider subscribing. It would mean a lot to us for you to show your support to the show. It's a very great episode, so let's dive in. Hey, Alan, how are you this week? Hey, Sam. Not doing too bad. How are you? Yeah, not too bad. What happened to our upload last week? We had some technical issues, didn't we? When we were just, when we were just about to record.
We got bit by laziness meets DRM, I believe. Technical issues, yes, technical issues. Sorry. Yes, yes. Professional. Professional. Technical issues. No, yeah, apologies. No upload last week. Some of the software that we use. We didn't renew licensing of. No, sorry, I didn't renew the licensing of. And it was very confusing working out the DRM and why things weren't working. So, yeah, we spent a whole night debugging different things. So, yeah, it wasn't obvious it was DRM, was it?
No, exactly. So, yeah, no, we just decided, you know what, the universe is blocking us this week, so, yeah, we decided just to shift, shift out a week. Yeah. But it does break our, it does break our, um, our combo streak, Alan, you know? Yeah, maybe we'll have to do two episodes, one week. Yeah, it's all good. But this week's been all right. It's been hot. It's very hot right now, recording this episode. So might be short and sweet to get out of this.
I think it's, I think it's really funny because whenever in the UK it's really warm, you obviously, people from the UK generally start talking about the weather. And then when you talk to people in other places, like somebody we work with is over in Dubai at the moment and it's like 48, 50 degrees. I don't know what the humidity is, but. Yeah, it's like top trump, basically. So. No, but yes, unusually warm, which is good. Yeah, it's different heat over there. Of course it is.
Yeah, of course it is. Right, Alan, what are we talking about this week? Yeah, so we're going to talk about managed entities in azure and programmatic access to Azure.
Yeah, nice. I know this is, I don't know, I would say it's quite an advanced topic, I would say. I don't know if it's fair to say that, but I kind of feel like a lot of quick starts and guides and learning materials just push people down to shared tokens, passwords, connection strings, those types of things, instead of actually utilizing managed identities. I don't know, maybe that's just how I started to approach the cloud when I first started.
Yeah, it's definitely something. I mean, they are reasonably new, I guess, over the last year or two, so. Okay. You know, it's, it's, if you've always done it one way and didn't realize you could do it another, you know, like our last episode, you know, it's been out for a year. Improve you.
Yeah, exactly. Yeah, yeah. You definitely shouldn't come to me if you're, you're wanting to know about like the age of any sort of solution or. Yeah, but no, I think I know about managed identities, but I'm sure we'll get through some of this anyway. Right. So, Alan? Yeah? Should we just start off with why they exist and what programmatic access is?
Yeah, so programmatic access at a very high level is just using scripts and background, I suppose, background access to or ClI, you know, access to, to resources or an application kind of thing. So I suppose programmatic, programmatic access could be to APIs and things like that, so, or to services in the background. So yeah, it's normally within an application like, you know, a script and it's to run a process against that resource. So maybe it's against programmatic access against a SQL database or maybe into azure to build resources or remove them infrastructure's code. We'll be using programmatic access to do those things. So from a very high level, that's what programmatic access is. I suppose most people might see that as kind of like we said it would be in applications to talk to different services, but also it might be a Powershell script to run stuff against active directory or ad or anything there. So probably that is at high level. And to gain access to these resources programmatically you have to do some form of authentication. Sometimes you don't, but, you know, 90% of the time now you do now need to do some authentication, be that shared keys, service principles with secrets or certificates and kind of thing so, so.
Yeah, okay, should we, can you just give us a brief overview of like the different types of ways that you do gain access, you know, programmatic access to resources.
Yeah, so probably just, yeah, tying on from what I was just saying. So in effect you could have the authentication process to be able to gain that programmatic access might be just username password, you know, typing it in probably with Azure and Microsoft entra. That won't be as simple as just username password. That will be a mon, authentication against Etra. So you have to do MFA and things like that. Now if you're required by conditional access. But the other ways you can do it with enter, in effect, is with a service principle, an app registration. Within the app registration you can specify within 365 or graph, you specify the permissions that you want on that, or within Azure, you assign it to the resources and the role that you want it to have there. With the app registration. To authenticate, you can use a secret. So you generate a secret which lasts x months, x years. That's quite very sensitive because if someone else gets two parts of it, then they technically have access and they can use whatever permissions that has. Kind of like, I suppose it's kind of like username password, but not quite the same. The other way is to use a certificate. So you generate a certificate from a PKR, from a. Yeah, for a public key provider, and then you deploy it to that. You deploy the, the trusted certificate to the app registration. So any tokens that you generate using stiff cut can then be validated in proven that you can go to it. So that's a couple of the reasons. And of course you can now use managed entities, which we'll talk about in a bit, in a bit, in a minute. But you know, to use these, to use the methods I've kind of talked about, you have to store them somewhere, you know, you have to be within your application or your different IaaS or PaaS services to be able to, you use them and access resources. So within azure you generally put the, the secrets into the key vault. Kind of makes sense. You store it there. You know, your service or your service was ironic because actually technically you'd probably use imagined entity to go and get the secret now, but that's how we would do it now. But you could use, instead of identity, I think you use access keys to access key vault and things like that. So you'd use that, which means again, if someone gets that key, they can have access to the full key vault kind of thing. So it all can be secure, but there's just risks there of those keys and connection strings. Things like that will get grabbed. However method where it's in your application because you're storing it or you're processing it and there's a bug vulnerability that maybe someone can reverse it and see that information. So that's kind of how we would use them as well for azure resources.
In that scenario you mentioned putting your database connection string into a key vault and then using an access key to then access that key vault as an example. Are you just kicking the can down the road at that point? Are you just adding layers of obfuscation? You know, because at the end of the day that access key has to be stored somewhere. You know, is that embedded in your app, config your code or, you know, there needs to be a finite store somewhere.
Yeah, I mean the good thing about it being in key vault is that multiple applications can then use it. So it's a good place to, it's stored there and if you need to replace it, change it, update the secret, et cetera, it's done in one place and then the other application can then use it and then it's just communication between the key vault and the service that you even need to keep updating individually or not. So you're right though, it is kind of kicking it down the road a little bit. You're just moving it. Yeah. Security for you. Obscurity. Yeah. Moving the problem somewhere else kind of thing. Yeah.
So do you want to, I definitely see, you know, some risks there and how those more traditional ways might not be, you know, perfect end to end. Do you want to talk about, you know, what, you know, managed identities are and, and what sort of benefits they bring?
Yeah, sure. So a managed identity is in effect a app registration in its own form, but within Azure you can actually assign it to. There's two different types there. So there's a system managed identity and a user assigned identity, managed entity. One is based on a, a resource having an identity, you know, an entry id identity in effect at registration solely for itself. Or you can have a user assigned managed entities where you can use them in multiple places. So it might be that if you have a cluster, a bunch of logic apps that are doing accessing all the same resources, you might just want to use one managed identity there across the group rather than having individual ones to manage. So there's different scenarios for both them. But because that managed entity is in effect assigned to a resource that allows that resource to then have permissions to other resources without needing to have a secret or a certificate. So it means that if you need to access a key vault to get something, you know, something out of it, like a connection string, you can now use the manager density for the service to then communicate with it. And in effect you can specify exactly what it can do within that access. So it makes it really simple to manage because also you don't have to worry about rotating the keys, you don't have to forget that. And all of a sudden half your application starts failing because you haven't rotated your key or it's expired, you know, expired keys, expired certificates, which can be quite key, you know, it's like DRM and things like that. So, yeah, and it's really, really simple to set up and like I said, it just starts that communication really easily. You know, one thing I think we've seen at you, Sam, is in app reg service where you can have a key vault connection as one of your, is it configuration items or your, is it configuration items that.
Yep. The parameters things, isn't it? Yeah, configuration items, you combine them to a key vault. Yeah. It's all integrated.
Yeah. So literally all you do in the, in the service there at the, you know, the, you know, the azure portal side or at least the app service level is you type in the URL to the key and then it uses the system identity from the, from the app service to then go to that key vault and get the key. So storing them securely in another place is brilliant because then from a management perspective, the dev, the app service administrator doesn't have to know what the key is or they know where it is because it's been specifying the key in the URL because then I think those configuration arms then just appear as the value doesn't, if I'm right in your app. So there's no connection or anything.
They're just environment variables. So they get presented as environment variables. So you just go environment env and then you can just access it via its key name. And the developer, they don't need to manage any connections or anything like that, they just reference their environment variables and away they go. It's all handled further up the chain for them. Yeah.
So yeah, makes it really simple, do that communication. We've used it in our day to day to talk to API manager, to other semi secure logic apps between each other. And this is consumption ones, not standard ones where that's quite simple to do, but also talking to potentially graph or dataverse using managed identities. So we don't have to worry about sorting all that sort of stuff out. So there's lots of benefits. And like I said, it's really the key one is it's simple to do. You can easily see where they are. They're tied in effect, to your tenant. There is something called identity Federation, which we can talk about sort of later, but in effect it means that, you know, someone can't steal it. They have to be able to authenticate against your, you know, your entra with it. So at least you can see that as well. And to be fair, it has to be attached to a resource and in your subscription and things like that. So it can't even be taken out, you know, someone can't run it on their own. So you got that massive security thing that it's ring fence in effect, to your tenant, to your, to your subscriptions and things like that. It literally has to be used in your environment, not taken away. And use, well, what can they steal? There's nothing to steal apart from a client id.
Yeah, exactly. And essentially they could just assign it to another resource in your environment. Right. You need to get access to something else. But I think then, because you can really disconnect developer related roles with security Administration tasks as well. If you do have a development team that are building in Azure, you also have a cybersecurity on infosec team devsecops. You can separate those roles out quite nicely. You say to your developers, give me the environment variables, because you want me to expose these values to, or these resources or connection strings on, you manage that all yourself and the developers don't even need to have access to it. Because I'm not saying that developers inherently don't follow best practice or don't do the right thing or have the best intentions. But when you are building and your role is to get through your backlog as quickly as possible, it's very tempting to use a connection string, shared access key, open authentication up. I think these types of tools, once you've got your head around them, they're not insanely complex, I wouldn't say, especially if you're mainly using them via the portal and not trying to do anything too clever with them. It's a relatively simple concept and it can add really, really good security controls to your application stacks.
Yeah, I think as well, it does simplify. I think you kind of might have said this, but it does simplify the process because, you know, you, let's talk about how you deploy them. You go into azure, if it's a system management entity, you go to your resource and if it supports it, you go turn it on. 20 seconds later it's got a system management entity which then you can give access to what it needs kind of thing. If it's a user assigned, you go into managed entities and create one, give it a name, it's done.
Yeah. The only thing I will say is it's a shift from more traditional methods because traditionally if you had a web app you want a backend API or something and you wanted to talk to your SQL database, you would have a connection string and you'd manage that yourself. You wouldn't check it into git, you would put it in different places and sort of protect it yourself if that makes sense. So this is sort of handing over some of that responsibility to the platform and it is an Azure specific thing, if that makes sense. Right. But I wholly agree with you. Once you're utilizing it, it is incredibly easy and the user experience is, yeah. Is absolutely great.
Yeah. I mean, the other thing I've seen is a virtual machine and having a measured entity and then storing its encryption, its Bitlocker keys and stuff going into a key vault and things like that that's used there because then the system's able to retrieve them and everything. But the other one I've seen is access to an Azure SQL database because instead of you giving it a user account to use, you give it the identity of the system in effect and say, well this machine's allowed to talk to it and it's got this permission so it doesn't matter what, you know, what role you've got. Only this machine can talk to it in that sense. So you've got that ease as well. You know, I assume I've not actually done it myself, seen someone or seen it in action kind of thing, but not, I see the config but I think they were almost like, yeah, signing in with, I think even the, maybe the connector or whatever might actually say, you know, connecting using your mag density, go as machine, go bang boom, connected.
Yeah. And the least you have to manage the less you can lose or misplace or, you know, because you're essentially, and I know you do have to have trust in these systems, right. But I assume if you don't have trust in managed identities you probably shouldn't even be an azure in some respects, right? Because like the veil of, you know, security is, you know, probably not up there for you, but it just makes your life so much easier, you know. All I would say is there are some edge cases. I would say if it's all supported in the portal and you can do some crazy stuff with managed identities, right. You can oauth with them, you can pass them through in different ways and there's no point going into it now, but there's different ways that you can access it and it can become, if you're not used to that type of authentication, it can be a little bit, not confusing, but there is a little bit of a learning curve there. But I do honestly think that the investment of time to get there is going to pay dividends in not just security risk reduction, but also efficiency going forward.
Yeah, I think, I think as well you might find. What I found at least is that you, you kind of use it and then you're like, this is great, you know, I want to use it for everything. Yeah.
Not everything does support it. And then you hit that war and you're like, use a key, look after something somewhere. You know, because I've had it with logic apps, you know, because we used to talk to the various resources, like I said, cosmos, yeah, Cosmos, DB and various other things and some of that was absolutely fine. But when you want to talk to something else, I think it used to be like Azure monitor log analytics. That was like, nope, give me a key, please. And I'm like, please.
They have JSON generate. Yeah. And then you've got a user managed identity to create a token. Right. Which you can then use via what, like an API or something. Do you see what I mean? I think when you get into those scenarios, I think you just need to understand authentication in entra and azure a little bit more because if you don't have that base knowledge, if you are just copy and pasting connection strings today you are going to want to know about generating tokens with Azure, how to oauth into entrance, basically modern authentication techniques, you know, but if you are building these types of solutions today, you know, that's probably something that you're going to want to want to know anyway, just as part of your day to day, to be totally honest with you.
Yeah. And you can build them using templates, terraform, the open source version of it coming what's called an open tofu. Yeah. And various other things, you know, to push them out. You know, we've done that quite heavily in the past. You know, I've got a new app I'm building, I'm pushing out merged entity and then that's communicating with everything and I can just use it in one hit. Don't have to worry about a secret or anything. Yeah, just rewrite when it comes to that.
Yeah, it's great. Yeah, 100%. You spoke about that workload identity Federation, what's that?
Okay, so it's pretty new to me, but actually colleague of ours has tested it, but in effect what you can do is you can actually put an oauth or an, is it an OIDC token or. Yeah, is a token that basically you can trust. So it means that if that is authenticated against that client id or a, yeah, a token is brought along using that, you know, that measured entity sort of client id, it will trust it, which means that you can use resources outside of Azure to communicate with Azure resources using a measure identity. So you don't have to use secrets and things like that either. You can use, yeah, that, that other services maybe equivalent of Azure identity to then say I'm going to authenticate using the mazur entity in Azure. And Azure knows to trust the other managed entity in effect, or the other service or secret whatever it might be, which makes it really powerful because in effect it means that you can have cross cloud workloads communicating. So some of the supported ones are if you've got kubernetes in AWS or the Kubernetes engine in Google, you could do a trust relationship between the user assigned managed entity and the app registration and the Kubernetes workload and then it's able to communicate. Another one which our colleague Chris was playing with was he was able to get DevOps pipeline and the service there to actually be terraforms, make, use it as a terraform as authenticating against it, not needing a key anymore. So in fact use the manage identity to then you know, push out your resources and not need to renew the keys, which was quite interesting. So he's been doing some testing with that as he was sort of renewing the client, the client secrets. He's like oh, I was talking to him about, about this and he said I'll go and try out. So that's quite interesting itself. Yeah. GitHub actions figure a trust between your user assigned identity and application and the repo Google cloud. Yeah, trust between that, yeah, Ada as I said. Yeah, it basically affects the, says anything outside of, of Azure you could do as long as you do an API call into the Microsoft ecosystem and you provide a JWT token in effect to it and it will then trust it.
Nice.
Yes, that kind of opens it up a bit more at least. So at least then from your azure build you can keep it quite secure, you can use it there and then you'll. Within the, within entra, then you then say I, you know, I then trust authentication from this other identity outside of, you know, outside of my resource. So you're still limiting what can not say impersonate but use that identity's permissions and things like that. So yeah I think that's quite, that's quite good. I think that's quite new as well. So.
And it's probably a year old Alan.
Yeah, probably, probably. I'm not going to go and check on myself, of course, but I won't either as far as I'm aware as well. You can look at like, because obviously these are kind of authenticating without any keys, things like that. You can, you know, buy there's a workload ID SKU in entra which means you can, you know, do extra monitoring on it and things like that and see all the sort of activity as well so that, you know, these can still be monitored because they are just authenticating against enter and things like that. But you'd upgrade your skew to understand exactly what it's doing kind of thing.
Following on from that. How much do they cost? What is the licensing sort of approach for them? Well I mean it's really. They are quite expensive, you know that. They're really expensive. I mean they're, they're free. What? Free from Microsoft? It's a security thing. What? Just, I say just. But they are just an identity, you know, you don't pay for app registrations, do you? So. True. Yeah true.
I mean, you know, I suppose technically you could have entra, basic free version to do this in Azure. You don't have to have the security, you know, the other skews there to protect. I think you might have that in place to protect your identity going into there to manage it. But yeah, you're like administrative role identity.
But yeah, there's no cost. I think the thing, there might be a limit on how many you can have in a region or in a subscription, things like that. But it's quite high numbers sort of thing. So like 15,000 managed entities or something. Yeah, it's probably the limit on entry for app registrations or something, you know. Somebody with a terraform script just testing the limits. Right, brilliant.
But yeah, I mean it's fairly, fairly simple, quite important at the same time, but, and like you said, it is a bit of a change on how you do your authentication because you expect to do all those other bits to do that authentication, but yeah, but also simplifies your theory, simplifies your authentication code process, whatever you're sort of doing in that, in that part. So. So yeah.
Yeah. Nice. Well, anything that is, I'll call it, I won't call it no cost. I'll call it included in the price of azure. Yeah, that is true. You use it against, as your resources, so you can't have.
Yeah, exactly. So, but yeah, it's, it's good that we've got a modern and, you know, we're supported and I think it's pretty unfair to say we're supported, really. I don't really like saying that because it is supported in so many places and I think as you've mentioned, it's only a matter of time that it sort of proliferates everywhere, if that makes sense, and sort of spreads across all the different types of resources. So, you know, I think it's a great approach and it's the right way to move and if you can use it, then, yeah, I would definitely advocate at least reviewing it and see if it can work for your, for your use case.
Yeah. So, yes, there wasn't anything, anything else to talk about. It was anything to sort of call out kind of thing. So, yeah, I think that's, that's, that's us sort of done with it. Nice. Good job. And yeah, so, so next episode would have been Sam, but isn't anymore because it's now going to be 1st. 1st week of the month. It's going to be news. Yeah.
Right. Well, we're not going to tell them what the next episode is. A bit of tension. If anybody, if anybody's made it this far. Yes, news. Next news next month. I've got a feeling there's going to be a lot. I haven't looked at the list, but my, my ex feed is alive with updates and changes so I've got to. I don't know. Well, you don't, you don't think they slowed down from, from the other stuff?
No, I don't think so. I think, I think it just. Yeah. Continues and goes. So. So, yeah. So let's do news next time. Great. Cool. Okay. So if you did enjoy this episode, please do consider leaving us a review on Apple and Spotify. If you do have any feedback or suggestions on some of our episodes, we have a link in our show notes to get in contact with us. Yeah. And if you've made it this far, thanks ever so much for listening and we'll catch you on the next one. Yeah, thanks. All.