![](https://azurefeeds.com/wp-content/uploads/2024/07/Figure-1-onyx-sleet-attack-chain-150x150.webp)
Onyx Sleet uses array of malware to gather intelligence for North Korea
July 26, 2024![](https://azurefeeds.com/wp-content/uploads/2024/06/cropped-microsoft_logo_element-150x150-1.png)
We’re committed to offering the best and most diverse selection of models to meet customers’ unique cost, latency, and design needs. This past week alone, we’ve brought the latest from OpenAI, Meta, and others to Azure AI, along with updates to our own Phi-3 family of small language models.
July 26, 2024If you are reading this post then you have probably at some point had to perform maintenance on an access control list (ACL). A list of allowed (whitelisted) or blocked (blacklisted) public IP addresses controlling access to a particular resource or set of resources.
We come across these in Azure quite a bit. Firewalls policies, NSGs, PaaS service firewall rules etc. Naturally, over time IP addresses will need to be added, changed or removed and depending on the exact use case, I’ve seen these kind of lists grow to hundreds of IP addresses over a period of years. Usually at some point a big clean up needs to be done and in my experience it’s not unusual to discover that quite a number of edits need to be made to the list.
Now of course, if you are following DevOps principles here, this will go through a full change control process and the ACLs can be updated in code format and pushed out pretty painlessly. In reality however, many deployments were not set up this way and quite often one person in house has the responsibility of making these changes via the Azure portal.
For anyone who has experience with creating or maintaining vast ACL lists through the Azure portal you will know that this is a slow and monotonous process. However, usually we just suck it up and just go through the motions as it’s a known procedure albeit a slow one.
Is there an alternative?
You may have wondered, outside of infrastructure as code or writing a script that will do all of this work for me, is there any way that I could just get at those settings without all that clicking? Perhaps some way to copy and paste directly into the ARM backend?
Well, yes in fact there is and it might surprise you to hear that this tool has been around since as far back as 2015! It’s so old that I wonder if Microsoft themselves have forgotten about it as it never got out of preview!
Azure Resource Explorer
Assuming you have sufficient RBAC access, this web-based tool allows you to have full CRUD (Create, Read, Update, Delete) control over your Azure resources through the ARM REST API. This means that you can use this tool to get at all of those settings without needing to go near any code, you can just update the property values directly.
Note:
A word of caution here, this tool should be used carefully as there are no safeguards or data validation like you might have with the Azure portal. This is also another reason why access control is so important. If you have permissions to create, update or delete resources then you could really do some damage to your environments if you are not very careful here.
A use case example
First thing’s first, you will find this service not in the Azure portal although this does have a similar tool but that only provides you with read only access. If you want to make changes to your resources then you will need to go to https://resources.azure.com.
If you already signed in and authenticated, then you will be able to select any Azure subscriptions in scope and your RBAC permissions will be enforced for this portal.
![](https://azurefeeds.com/wp-content/uploads/2024/07/image-12.png)
From there, you can browse through your resource groups and resource providers and view all of the various configurations that are available. You may find some interesting items just by having a look around!
In my use case, I wanted to update the access control list of an Azure App Service and modify the allowed IP addresses in the ACL.
The below is just some dummy data but as you can see from the Azure portal I have a number of allowed addresses added already.
![](https://azurealan.ie/wp-content/uploads/2024/07/image-4.png?w=1024)
Adding, editing or removing rules via the Azure portal must be done individually, rule by rule. Not fun.
![](https://azurealan.ie/wp-content/uploads/2024/07/image-5.png?w=294)
In the Azure Resource Explorer, I was able to browse to the resource group where my App Service was deployed, click into the web app itself and then have a look at the config/web settings.
![](https://azurealan.ie/wp-content/uploads/2024/07/image-13.png?w=1024)
Scrolling down through the properties I can find the ACL settings represented in JSON format under a property called ipSecurityRestrictions.
![](https://azurealan.ie/wp-content/uploads/2024/07/image-6.png?w=975)
Let’s see how easy it is now to change these here.
Firstly, we need to scroll up to the top of the page and click on the Read/Write button shown below (it should be set to Read Only by default). Then we click on the Edit button beneath that so that we can get access to the PUT and PATCH API commands that allow us to update the environment.
![](https://azurealan.ie/wp-content/uploads/2024/07/image-8.png?w=533)
I can now make any required changes directly in the editor. Below I have added some additional rules but I could just as easily remove rules or change existing ones as well.
![](https://azurealan.ie/wp-content/uploads/2024/07/image-9.png?w=450)
When you are ready to commit the changes, scroll back up to the top of the page and click on either the PATCH or the PUT button to commit the changes.
![](https://azurealan.ie/wp-content/uploads/2024/07/image-10.png?w=227)
A quick note on this, PATCH is intended to be used when you simply want to update a particular property of the resource which is the case here. PUT is used for updating the entire resource. In general, with Azure resources when deploying with IaC you are updating an entire resource and a PUT action is idempotent. This means that making the same request multiple times will have the same effect as making it once, which is a good thing.
For this specific example, either option should be fine as idempotency isn’t crucial and we are just updating a single property so the PATCH method is fine.
When I do a refresh of the Azure portal it shows that my changes are now present on the Azure resource, saving me all that clicking!
![](https://azurealan.ie/wp-content/uploads/2024/07/image-11.png?w=1024)
Conclusion
The purpose of this post is to highlight an old but useful tool that I suspect many have forgotten. It is not something that I myself have used regularly but I believe it does still have some use cases and it could be a real timesaver for certain tasks such as my example here.
If using this tool however, please do be cautious as although you are only limited to whatever privileges your account has, it could be very easy to make a mistake here and edit the wrong resource or worse still bring down your environment.
Bonus Tip
This tool can also be useful for exporting properties. In this example, the only way to document the ACL lists in the Azure portal was by taking screenshots, there is no export option. By using the Azure Resource Explorer, you can easily grab the list in a JSON/text format and document it yourself.