Pod Sandboxing has just been announced for AKS, allowing you to better isolate your container workloads. Let’s take a look at what this is, how it works and whether you want to use it.

Nearly every Infrastructure as Code deployment will need some element of configuration data. Some of that will be unique and specific to that deployment, but there will generally be some element of configuration that you use in many different implementations. Some examples of this include: Resource naming conventions On-premises IP ranges for resource firewalls Groups for RBAC roles You can store this configuration data in your template or pass it as parameters, but you’re going to have to create this data for many different deployments.

One thing that has frustrated me for some time with Azure Service Bus is that the network security features, such as Private Endpoints and Service Endpoints, are locked behind the premium SKU, which has a significant extra cost. I believe security features should not be locked behind expensive SKUs and should be available to anyone using the service, as they are with most other Azure services. This results in either paying extra for the premium SKU just for these features or running the cheaper SKU without the additional security features.

When you first start with Infrastructure as Code, it can be tempting to create one template to rule them all™ where you can deploy your whole infrastructure in a single deployment. If you’re only deploying a few resources, then this can be fine, but once you get beyond that and are deploying complex sets of infrastructure, it’s important to consider your blast radius. So what do we mean by blast radius?

If you use Azure AD Multi-Factor authentication, then you should be aware that as of 27th February 2023, Microsoft will begin enforcing number matching with MFA requests using the authenticator app. So what does this mean? What is Number Matching If you’ve used Azure AD MFA push notifications using the authenticator app, you’ll be familiar with the popup you get when logging in, asking you to confirm your request. The problem with this approach is MFA fatigue.

One of the Infrastructure as Code tools I often talk about on this blog is Pulumi. I’m a fan of its ability to use real programming languages toe define infrastructure and the flexibility this brings to what you can do during a deployment. The benefits of Pulumi for developers who need to deploy infrastructure are clear, but for IT Pros, who maybe don’t have so much experience in using programming languages, it can be intimidating.

Azure firewall has a new basic SKU that offers a cut price firewall but with several limitations.

Pulumi allows you to use real development languages to create your Infrastructure as Code. Because of this, you will usually need several prerequisites and libraries installed in your development environment, depending on which language you are using. You can set these up on your development PC, but one alternative approach is to use GitHub Codespaces. GitHub Codespaces allows you to quickly deploy a pre-configured development environment, along with your code running as a cloud service.

As you probably know, I talk quite a bit about Bicep. Invariably when I do, I get a comment or question like “why would I switch from Terraform to Bicep” or “This is pointless, Terraform already does all this”. Well, here’s the secret: if you’re using Terraform and are happy with it, then Bicep isn’t aimed at you! Microsoft’s primary goal when creating the Bicep language was to remove the barrier of entry when using Infrastructure as Code in Azure.

Azure Container Apps now supports IP restrictions in preview allow you to lock down access to your apps to specific IP ranges.