Azure

Secure Your VNets with Private Subnets

Secure Your VNets with Private Subnets

A couple of weeks ago we talked about how Microsoft is deprecating default internet access for VMs](https://samcogan.com/retiring-default-internet-access-for-vms/) in September 2025. This change is being done because it doesn’t meet Microsoft’s “secure by design” approach. However, you don’t need to wait till 2025 if you want to get ahead of the game and secure your outbound traffic due to the introduction of private subnets. By declaring your subnet as private you disable default outbound access and out of the box any VMs in that subnet will not have access to the internet.
Multitenant, Multi-App Consent with Azure AD (Entra ID)

Multitenant, Multi-App Consent with Azure AD (Entra ID)

Multitenant applications in what is now called Entra ID, but what I am sure I will continue to call Azure AD (AAD) for some time, are a way for developers to create Azure AD-backed applications that are managed in the developer tenant but allow users to log in and manage users from their tenant. They are a very common way for SaaS developers to manage application authentication whilst leaving the user management to the client.
Retiring Default Internet Access for VMs

Retiring Default Internet Access for VMs

There’s a big change coming to Azure VM networking in September 2025. Yes, that’s a way off, but it will pay to plan for this now. VM networking in Azure has differed from AWS for a long time, in that Azure VMs are automatically able to make outbound connections to the internet, with no configuration required from the user. AWS on the other hand, takes the opposite approach. By default, AWS VMs have no internet access, and you have to explicitly configure it if you need it, through something like a NAT Gateway.
Passwordless Azure Deployments with Workload Identity In Azure DevOps

Passwordless Azure Deployments with Workload Identity In Azure DevOps

If you are using Azure DevOps to deploy resources to Azure then you probably know the pain of using service principles for your service connection. Using a service principle involves storing the credentials for this in Azure DevOps. Assuming you’re following good security principles and having an expiry on the service principle secret you’re probably going to forget to renew it at least once, and your deployments will grind to a halt.
Bicep Parameter Files Are Here And You Should Switch

Bicep Parameter Files Are Here And You Should Switch

Whilst we’ve been using Bicep files for a while now to create infrastructure as code, we’ve been stuck using the same JSON parameter files we had been using with ARM templates to be able to pass in parameters to our Bicep code. Well, no more! We now have a Bicep parameter file, the .bicepparam file, which allows us to use Bicep syntax and offers several benefits. All of that said, the JSON parameter files still work, so why should you switch?
Backing up Unraid to Azure Storage with Rclone

Backing up Unraid to Azure Storage with Rclone

I run a small server at home for storing documents, photos, and media and running some applications that are used at home. This server is running Unraid, which is a Linux Server operating system that allows you to get a level of disk resilience without the need for a full-blown RAID array and multiple redundant disks. It’s a great OS for a home server, and the way it provides resilience using a parity drive has saved me more than once when I had a hardware failure.
Automating Deployment to an AKS Cluster with Local Auth Disabled Using

Automating Deployment to an AKS Cluster with Local Auth Disabled Using

One of the benefits of using a multi-cloud Infrastructure as Code tool like Pulumi or Terraform is that you can easily transition between layers in different providers. For example, you can deploy a Kubernetes cluster in Azure with AKS, and then using the same IaC deploy pods and services into that cluster. To do this, the IaC tool needs to retrieve some credentials in the form of a Kubeconfig file, from the cluster it has just deployed.
Upgrade to Version 2 of the Pulumi Azure Native Provider

Upgrade to Version 2 of the Pulumi Azure Native Provider

Pulumi recently announced the beta release of their Azure Native provider. This provider allows the creation of Azure infrastructure using Pulumi, with the native part meaning that this is auto-generated from the Azure APIs, rather than hand-crafted like some of the Terraform-based providers. Upgrading to v2 should be a fairly easy process, there are no huge tasks to undertake, but there are some things to be aware of, which we will look at in this article.
Getting Rid of Passwords for Deployment with Pulumi OIDC Support

Getting Rid of Passwords for Deployment with Pulumi OIDC Support

Pulumi recently announced support for using OIDC to authenticate to Azure when deploying your resources. This is separate from the Pulumi service supporting this, which it has done for a while, and means you can use OIDC from any supported deployment mechanism, you don’t have to use the Pulumi service to get this. Let’s take a look at what that means and how to do it. Why use OIDC? When you deploy resources to Azure, you need to provide some sort of credential to do the deployment.
Azure Container Apps Updates and Improvements

Azure Container Apps Updates and Improvements

Azure Container Apps is the Microsoft solution for PaaS Kubernetes, abstracting away the Kubernetes layer to allow the user to focus on delivering their container-based applications. It’s a relatively new service, released last year, and has a few missing features or areas where things could be added. Over the last couple of months, there have been several announcements and updates for ACA that fix some of these, culminating in last week’s Build conference where we saw quite a few announcements.