🐇This blog post is also a contribution to Azure Spring Clean 2023 where during 5 weekdays of March, 13th-17th, community contributors share learning resources that highlight best practices, lessons learned, and help with some of the more difficult topics of Azure Management. You’re welcome to check out all the contributions here: Azure Spring Clean 2023 As you may know already, Kubernetes doesn’t come with 100% built-in security by default. The same applies for managed Kubernetes service offerings like Azure Kubernetes Service (AKS). Some cloud providers offer more hardened default configuration for a managed Kubernetes service, some offer less hardened and more beginner-friendly default configuration, but the fact stays the fact - cloud services are a shared responsibility. It means that you’re responsible to properly harden and secure Kubernetes clusters that you’re provisioning in the cloud, also in Azure. ...

I was recently working on automating some manual actions related to my tech blog and discovered an interesting use case that I thought was worth sharing with the community 😊 Did you know that it is possible to trigger a GitHub workflow that resides in a different repository? Let me show you how!😼 There are multiple approaches to how you can implement this but I have found following approach to be most preferrable. Let’s say that you have repository A and repository B, and you want to trigger a GitHub workflow in repository B once workflow in repository A succeeds. ...

Recently a new property became available in Azure Portal when creating a new Azure Kubernetes Service instance: Have you seen it and do you know what it actually is? Wait, does AKS have pricing tiers?! I thought that the only price we need to pay was based on the chosen VM SKU for AKS Nodes….right?🤨 Well, the answer is yes and no.😺 By default AKS is a free service and you only pay for the virtual machines you choose for your Nodes, plus associated storage and networking resources. There are nevertheless some additional billed capabilities that can be enabled, like Uptime SLA, which is now more streamlined with visibility in Azure Portal. ...

A thought struck me one day when I was working with onboarding machines to Azure Arc. If you want to onboard multiple servers at scale to Azure Arc, you would need a Service Principal with Azure Connected Machine Onboarding role in the respective subscription or resource group where you want to create Azure Arc-enabled servers. An interesting thing here is: what if you would like to re-use the same service principal in order to onboard more Azure Arc resources but to another subscription and/or another resource group? ...

Introduction of the issue [Update July 2023] This issue has been resolved and you should be able to create a Kubernetes resource targeting Azure Kubernetes Service in Azure DevOps Environments in the same way as before. Official documentation has been updated with additional details: Kubernetes resource With release of Kubernetes version 1.24 a new feature gate has come to life which is called LegacyServiceAccountTokenNoAutoGeneration, and it is enabled by default. What this feature does is that Secret API objects containing service account tokens are no longer auto-generated for every ServiceAccount. You can read more details about this change in release notes: CHANGELOG-1.24 ...