maskati

This script retrieves published Azure location information and transforms it into GeoJSON format, with Point features indicating Azure regions and LineString features indicating links between paired regions.

$locations=az account list-locations --query "[?metadata.regionType=='Physical']"|convertfrom-json
@{type='FeatureCollection';features=$($locations|?{$_.metadata.pairedRegion.count -eq 1}|%{$r=$_;$p=$locations|?{$_.name -eq $r.metadata.pairedRegion[0].name}|select -first 1;if($null -ne $p -and -not (($r.metadata.longitude -eq 0 -and $r.metadata.latitude -eq 0) -or ($p.metadata.longitude -eq 0 -and $p.meta

maskati

This PowerShell script streams Application Insights live metric traces to your local system and displays them in a PowerShell grid view. This is useful since the Azure Portal trace viewing experience is somewhat limited.

Warning

This script uses undocumented functionality. Exercise caution when running any scripts against your infrastructure.

To use:

1. Ensure you are logged in using Azure CLI and have selected the relevant subscription.
2. Run the script in a PowerShell terminal (tested only with PowerShell 7.3).
3. Select the relevant Application Insights resource from the first grid view. This lists all Application Insights resources in the Azure CL

maskati

Here is how you can emulate Azure managed identity on your local system by running an instance metadata service identity endpoint and simulating the token API to return an access token from Azure CLI. You can use this for example to log into SQL Server Management studio using your Azure CLI identity, or locally test code that uses the "Azure only" [ManagedIdentityCredential](https://learn

maskati

Windows

nslookup myip.opendns.com resolver1.opendns.com

Linux

dig +short myip.opendns.com @resolver1.opendns.com

maskati

Run with PowerShell 7.4 or later based on .NET 8 which includes the new IPNetwork type. Requires authenticated Azure CLI.

# e.g. ns-sb2-prod-am3-002.cloudapp.net (service bus namespace in westeurope)
$ip=[net.ipaddress]::parse("104.46.32.56")

az network list-service-tags --location westeurope | `
 convertfrom-json | `

maskati

Azure Change Analysis enhances the visibility of changes made to Azure resources. It does this by tracking these changes at the subscription level and recording them in the Azure Resource Graph's resourceschanges table.

As of March 2024, change tracking now also includes detailed information about the principal that initiated the change, the client type (e.g. Azure Portal, Azure CLI, ARM template), and the operation which resulted in the change (e.g. Microsoft.Web/sites/write). This enhancement means you no longer need to consult Azure activity logs separately to understand who initiated a change and what action they performed. Everything is conveniently available within th

maskati

Microsoft documents recommended abbreviations for Azure resource types as well as resource type specific naming rules and restrictions. Microsoft also publishes the Azure Naming Tool which happens to contain a structured repository of Azure resource type abbreviations and naming rules.

You can get a quick searchable grid of this data using PowerShell. If you prefer you can replace the Windows-only Out-GridView with the cross platform [Out-ConsoleGridView](https://github.com/PowerShell/ConsoleGuiTools/blob/main/docs/Microsoft.PowerShell.ConsoleGuiTools/Out-Console

maskati

Azure has an upcoming capability to export resource templates from the Azure Portal in Bicep format. This capability is actually already added to a new version of the Export Template REST API operation. You can test this by setting the appropriate outputFormat parameter which takes a value of either Json or Bicep from the Azure.Deployments.Core.Entities.ExportTemplateOutputFormat enumeration. Below is a PowerShell script to export a resource group as a Bicep template without local ARM decompilation.

$resourcegroup = 'MyResourceGroupName'
$groupid = az group show --name $resourcegroup --query id -o tsv
$token = az account get-access-token --query accessToken -o tsv|convertto-securestring -force -asplaintext
irm -method post -authentication bearer -token $token -uri "https://management.azure.com${groupid}/exportTemplate?api-version=2024-06-01-preview" -contenttype 'application/json' -body (@{resources=@('*')

maskati

Key Vault secrets can be set through:

• The data plane (Key Vault REST API) using the Set Secret operation.
• The management plane (ARM) by deploying a Microsoft.KeyVault/vaults/secrets resource.

There is a notable difference between these methods with regards to adhering to the Key Vault network security and access model configurations.

• Key Vaults with network restrictions will verify data plane operations against network access rules, and you will not be able to add or update a secret from the public Internet to a private Key Vault.
• Key Vaults authorized with access policies or Key Vau

maskati

You can use WeTTY to create a web based interactive terminal for a shell running in the context of your GitHub Actions workflow, and combine that with Microsoft dev tunnels to open a secure and authenticated connection into that shell. The default dev tunnels security model secures access by requiring authentication with the same account used to host the tunnel (in the below example a GitHub account).

You can use this to investigate issues with your workflow scripts in the context of the actual runner. Here is an example of htop running on a GitHub hosted agent.

The below workflow step:

1. Installs Dev tunnels and WeTTY (due to a know issue we install version 2.5).
2. Starts WeTTY to host a bash shell over a web interface.
3. Auth