<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2012313439098820&amp;ev=PageView&amp;noscript=1">
Posted by Mike Racine

How to Restrict Network Access to Azure Key Vault Using Firewalls & vNets


Azure Key Vault is an amazing place to keep the secrets keeping your infrastructure going, but what keeps out the dark? Of course, Microsoft’s already thought of that, and in today’s episode of #KnowOps Dana shows us how to lock the gates to Key Vault from the outside world.

Need to brush up on your Azure Key Vault basics?

Show Transcript

So I got a DM on LinkedIn this week from someone who recently watched my episode on Azure Key Vault basics, worried that his secrets could be directly accessible from the violent villany on the internet. It's a reasonable concern but there are security controls that you can apply to lock down access to your Key Vault. Let me show you how.

Dana Epp here, welcome to the channel that helps aspiring Azure administrators like you and me to KnowOps and well, master the Microsoft Cloud, I'm glad you're here. If you haven't yet, smash the subscribe button so you can be notified when I release new videos each week.

Okay, so it's true, by default, you can connect directly to a Key Vault resource from the internet if you know its URL, but being able to connect to it and access it are entirely different things. First off, the access policy has to be applied to grant someone authority to get the secrets. Secondly, that identity has to request an access token to use it with Key Vault and finally, that access token has to still be valid when used which means it's properly scoped and hasn't expired yet.

But let's assume for a moment that an attacker got over those hurdles and stole a token, maybe even an architectural design flaw that exposes it, what can you do about it? This is where the philosophy assume breach comes to play. What can we do to reduce the damage potential? Thankfully, Azure Key Vault has network security controls for this. Let's jump into the Azure portal and I'll show you how to apply the safeguards to restrict access to your Key Vault.

Okay, so let's recap what this KnowOps demo environment has. We have a Key Vault called kopskv which is accessible by a managed identity called kopsUAMI in a Linux VM called kopsvm. We also have a logic app called mylogicapp that talks to Key Vault using a built-in connector set up within the logic app's designer. Right now everything works, in the actual Linux VM, I can get the secrets just fine using that script I wrote in the last episode. As we run that, we can see that we can get the secrets directly out of there. And we can also get those from that logic app. And we can see that the logic app was able to get the password as well.

If this is all new to you, check out the episode I previously did on Azure Key Vault basics, I'll leave a link in the show notes below but right now, anyone with a valid access token can talk to the Key Vault and get that secret. In fact, let me show you how I can use something like Postman locally on my desktop here in Western Canada to access this just as well.

So if I was to go back to that Linux VM and run that getToken command, you can see this access token here. And if I was to take this token and then jump over to Postman. Now, if you're new to Postman, it's really just a dev tool that makes it easy to interact with back-end APIs like what Azure uses. That's how I'm gonna directly talk to Key Vault right now. So all I have to do is set up what's called a bearer token and take that access token that was in that VM and basically use it here on the other side of the country. And if everything goes right, there is the password taken from the Key Vault.

Okay, so now we wanna kinda prevent this sort of attack vector. We wanna make it possible so that I can't use things like Postman across the country outside of the network and be able to access these credentials directly from the internet. So the way that we can do this is by going into Key Vault, we have the ability to control some of this stuff. And this is all done in the networking blade. So you can see, by default, the firewalls and virtual networks is set up to allow all networks and that's why this allows me to access it directly from the internet. So all I'm gonna do here is I'm gonna set the private endpoints up and I'm just gonna save it. I haven't actually configured any private networks, I haven't set up any firewall rules but by simply doing that one thing, if I go and try doing things like run that same logic app, you'll now see it fails. Why is that?

Well, because right now, it's unauthorized. Operation has failed 'cause it does not have permissions to prompt this call, okay? So behind the scenes, there are some things that we can do here, this is preventing everything from being able to access that Key Vault right now and I want to adjust it to allow things to talk to it. So it just so happens that I've already set up an Azure virtual network that allows resources in KnowOps to talk to each other and this is kinda useful so like when we're sitting over, let's say this VM, if I was to run that get secret again, you'll see it's not right now because I have not authorized Key Vault to be able to talk with the VMs that are in here. There's a reason for that. So let's first start by going back to that Key Vault for a second and I'm gonna add an existing virtual network.

So it ends up that I already have on here called KnowOpsVNet and I have a subnet here. Now you'll notice something is popping up right now. It is telling me that hey, you know what? This VNet does not have authority to be able to talk to Key Vault and for a moment here, I'm going to say do not configure 'cause I wanna go show you why this is important because if you have an existing VNet already set up on this, this step will actually screw you up later. So I'm gonna hit add and then I'm gonna hit save. And now, if I go back and try to run it, we're gonna get that same error, it's still gonna give me a null, it's gonna tell me it can't access it and the reason is, is that by default, even when you have a VNet set up on here, being able to access it, especially when doing it inside the VM and trying to access it through the reserve service endpoint for the access tokens is unauthorized unless you enable the service endpoint. So I'm gonna go back, I wanna show you this directly.

In the service endpoints here on your VNet, you need to just go in and add at the time whatever service endpoints you want. So specifically here, we're gonna use Key Vault but this is also useful for other things like if you wanna access Azure ED or Cosmos dB, Event Hub, Service Bus, Storage, any kind of critical service endpoint that you wanna have exposed, this is the way that you would end up doing it. Now, luckily, Key Vault is smart enough, it'll tell you you're missing this but I purposely said not to set that up 'cause I wanted to show you where this is in your VNets so that you know it's all there. Now, theoretically, once this gets added, this may take a few moments.

Now all right, so now that the Key Vault has actually been authorized to work in that VNet and we've set up the VNet support over here, now that VM again has access. So now the outside world so if I was to steal a new token and try doing this again through Postman, you'll now see it's forbidden and this is exactly the intention that we want. We want to allow our private VNet to have access to Key Vault, allowing our services to be able to access it safely but not allow the internet to directly do it. So there we go, now we're all set for that but let's talk about that logic app for a moment.

By default, logic apps don't have the same ability to be able to do this because you cannot configure a logic app to be able to take advantage of using VNet unless of course, you're using something called Integration Service Environment or ISE which is really an advanced topic which we'll cover on another day. Out of the box, most logic apps are not configured this way. So to allow a logic app to be able to talk to Key Vault, you're going to need to adjust the firewall to allow IP addresses that belong to your logic app. Now, there's a couple ways that you can get access to find out which IP addresses are actually authorized for this, it ends up that IP ranges are unique to every single region for logic apps but you can get to them if you were to go look at the properties. And if you scroll down, there will be a section here about the runtime outgoing IP addresses but more importantly, the connector outgoing IP addresses and you'll see a whole bunch of ranges here that have the different areas, so in my case , Canada Central, these are all the IPs that you'd need to be able to permit through Key Vault to be able to allow it to access.

Now there's another way we could get to this if we really needed to and I'm gonna kind of just cheat here. I'm just gonna jump on over 'cause if you remember in the last episode where we were talking about Key Vault, we said one of the things you should probably do is consider setting up a log analytics workspace and turning on the diagnostics so you can track access controls as things are happening. So if I go into the logs now, I can kinda cheat here and be able to just kinda go and look for any kind of failures. And if I take a look at the audit events, I'll be able to see that there's different sets of IPs that are accessing it and it ends up that things like this one here,, if we go look at that logic app, it'll be in here somewhere, right there.

So we can kinda cheat here just to make our life a little easier. We'll go into the networking and we'll set up this IP. Now what you would normally do in this scenario is you'd go and then add all of those IPs and that would allow for all the different areas to be able to do that but in our case here since we know this is the one or at least we think it's the one, if we now go to that logic app, and we run it and there you go. So what you've been able to see is that by using the combination of things like under the networking blade, being able to control the virtual networks that your services can all talk to in your private net, in your VNet or being able to set it up via firewall rules to authorize specific IP addresses, you have the ability to control the network flow to only allow those that need to to have access.

Now remember, by adding these ranges of IPs, you are also slightly increasing the attack surface of your Key Vault but an attacker would still need to have your access token and use it from the same region from within that logic app on that same infrastructure. So it's a pretty low risk all considering but it's something to consider. At the end of the day when you're accessing these resources, you need to understand what exposure you are providing on there but by applying these network rules, these security controls will make it much harder for people to access those secrets, okay?

Now there's one last thing, there's an artifact of all of this that you need to understand and that is that when you're actually applying these type of controls, this will actually affect things like the Azure portal as well. So while we can access the management plane to be able to configure things and change things, we can't access the data plane.

So if I was to go into these secrets right now, even I can't access this information because this browser hasn't been authorized by an IP address to be allowed to query Key Vault to be able to extract that information. But I think that's a reasonable trade off and I think that's something that we can consider when we're setting this stuff up.

When it comes to network access, managing cloud IT should follow many of the same principles of a healthy and secured network environment on premises. Use least privilege and restrict the flow of data through network isolation, access controls and your firewalls. It's not that hard to do with many of the cloud resources available to you in Azure, including Key Vault.

What do you think? Was this helpful? Let me know by hitting the like button. It really does help and if you haven't yet, smash the subscribe button so you can be notified when I publish new content each week. Until then, thanks for watching, stay safe out there. We'll see you in the next episode.



Azure Key Vault is an amazing place to keep the secrets keeping your infrastructure going, but what keeps out the dark? #knowops @auditwolf https://hubs.ly/H0mVw-q0






Topics: Cloud Operations (CloudOps), KnowOps