A few months back I started using Azure Tables as a quick, cheap, and simple database for a project at work. I was recently re-factoring my main Powershell script which spits data out into an Azure Table for later PowerBI reporting. Thankfully, even though it was close to midnight, my years of “ops management brain” kicked in before I pushed the “go” button on my refactored script. Thankfully it dawned on me I should be testing my updated script on a copy of my table vs. the only copy of the data I had.
Being late and me being tired, it didn’t occur to me to just try Azure Storage Explorer, which allows you to easily copy a table from one storage account to another. Instead, I turned to Powershell. What I came up with is a simple Powershell Function that creates a new empty table, reads the contents of your source table to an array and then pushes that array back into the new empty table. Using Powershell 7 batch processing, it works pretty quickly… granted my table only has like 2,000 rows. With that said, these Powershell snippets require Powershell 7, click here for install instructions.
Halloween is over but the the world is still a scary place. In a continuation of a thought from an article I wrote a few weeks back for Auditing AzureSQL Firewall Policies, I thought I would also include a short function for auditing azure storage accounts that are currently configured for “public” access.
Why are public access containers such a big deal? Simply put, anyone that knows the URL to the container and file can download that file. This is perfectly fine for public sites and public data (albeit you are paying for all the egress bandwidth associated with those outbound transfers in Azure… which you may not want to do). Any container that is marked as public access should have a documented business reason for why it is configured that way and any container that holds even the most slightly sensitive data shouldn’t be marked as public. I would go so far as to say, if there isn’t a particularly good reason for a blob container to be public, it’s better to just play it safe and mark it private. At the very least, you should be aware of it and keep tabs on this on a regular basis.
I recently overhauled a script that I wrote to take advantage of the parallel processing functionality that is included in Microsoft Powershell 7. The results have been excellent with script runtimes being reduced from over an hour down to roughly 5 minutes. Learning the ins-and-outs of using parallel processing was a bit of a chore that I will discuss in a later article, however the first hurdle that had to be mounted was simply getting Powershell 7 installed and figuring out how to make use of it. Quickly getting up and running with Powershell 7 is what this article seeks to address.
Let me start by saying, I really love Microsoft Azure and my brain is currently flooded with plenty of Azure goodness after earning my Azure Admin certification. Therefore I was surprised to find myself working on the Oracle Cloud Infrastructure (OCI) platform less than a week after passing the AZ-104. I find that my professional life is focused on Microsoft, Windows Server, Hyper-V, Powershell, IIS, Storage Spaces, etc. but the technical tinkerer in me is always working in the world of Linux. Additionally, my personal pet projects have personal pet budgets. So that means Apache, MySQL, PHP, BASH, Drupal, and WordPress.
I periodically review Azure PaaS resource edge security. As a part of that process I examine and cleanup AzureSQL firewall rules. Once you have more than a handful of subscriptions and AzureSQL databases, doing this manually starts becoming unfeasible. To that end, Azure Powershell is your friend…
As is typical, you need to install the Powershell AZ module on your workstation, after that you need to run.
Then supply your Azure credentials (preferably creds that have the ability to view and manage all of your AzureSQL databases and firewall rules, otherwise the rest is moot.