I’ve been running a home Kubernetes lab for a while now, mainly to help with studying the CKA/CKS exams which I took a couple of years ago (and that I need to make sure to renew this year!). This lab has been running on a collection of Raspberry Pi 4 boards, which has worked fine however it does have some limitations. In particular, I can only run ARM 64 images, which does limit some of what I can run.
Resource groups generally aren’t something you think too much off when deploying your Azure resources. They’re essentially a folder containing your resources; once you create one, you don’t do much with it again. However, there is one concept you should think about - the location of your resource group compared to your resources and how this might impact a disaster recovery or failover scenario.
One of the purposes of a resource group is to store meta-data about the resources deployed into them, so they contain details about how that resource is configured, its current state etc.
When you are writing Infrastructure as Code, you try very hard to stick to the providers and resources available in your chosen language, but eventually, most people will hit a point where they need to do something that they can’t do directly in their IaC language - run a script, execute an application etc. Most languages offer a feature to deal with this, Terraform has local/remote exec, and Bicep/ARM has deployment scripts.
It’s time for the Azure Spring Clean. The annual event is organised by Joe Carlyle and Thomas Thornton to encourage you to look at your Azure subscriptions and see how you could manage it better.
In this year’s article, we will look at a tool called Checkov that can help you check your Bicep code for best practices and compliance. So let’s get started.
What is Checkov Checkov is an open-source tool that can be used to scan Infrastructure as Code (IaC) for best practice and compliance.
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.
