This article is based on a community roundup originally sourced from msdynamicsworld.com, summarising posts from Azure practitioners Richard Hooper, Aidan Finn, Chris Pietschmann, and Karim Vaes. Original publication date: March 2020.
Securing Kubernetes API Access on AKS
Richard Hooper (Pixel Robots) wrote a practical guide on locking down access to the Kubernetes API server on an Azure Kubernetes Service (AKS) cluster. By default, an AKS API server is reachable over the public internet via HTTPS — a significant attack surface for any production workload.
Hooper noted that while role-based access control (RBAC) and Azure Active Directory (AAD) integration add meaningful layers of security, they may not satisfy every organization’s threat model. Azure Security Center will flag clusters that fall short of its security recommendations, which can serve as a useful prompt for teams that haven’t yet addressed API exposure.
Restricting API Server Access with Azure CLI
AKS supports IP-based allowlisting for the API server. Using the Azure CLI, you can update an existing cluster to accept traffic only from a defined set of CIDR ranges. After applying the change, access can be verified with a kubectl command from an allowed IP.
One important operational consideration: if you use Azure DevOps pipelines to deploy to AKS, you must include the relevant Azure DevOps agent IP ranges in your allowlist. Omitting them will cause pipeline steps that call the Kubernetes API (such as kubectl apply or Helm deployments) to fail with a connection error.
“It’s a bit of a pain, but as I am sure you are aware Security always is. I for one will be using this for all of my AKS clusters going forward and would advise you do too. Just remember if your pipeline fails due to it being unable to connect to the AKS cluster update the IP whitelist.”
— Richard Hooper, Pixel Robots
Azure Firewall Updates: What Changed in February 2020
Aidan Finn reviewed the Azure Firewall features that entered preview or general availability in February 2020, focusing on what they mean for enterprise network administrators.
Azure Firewall Manager
Firewall Manager (at the time in preview) provides a centralized control plane for managing firewall policies and firewall resources across one or more Azure regions. For organizations running identical or similar deployments in multiple regions, the parent/child policy model is particularly useful: a parent policy defines a baseline set of rules that child policies in each region can extend without duplicating configuration.
IP Groups
IP Groups let administrators create named, reusable collections of IP addresses that can be referenced in network rules. This abstraction reduces duplication and makes rule sets easier to audit and maintain. Finn also noted that the standard maximum port range applies to TCP/UDP rules (up to port 65535), which constrains how rules can be structured.
Forced Tunneling and Public IP Flexibility
Forced tunneling — routing outbound internet traffic back on-premises — is available but, in Finn’s assessment, is likely only justified for government agencies and similarly compliance-heavy organisations. A more broadly useful capability is configuring public IP ranges in private networks via PowerShell and JSON, offering greater flexibility for scenarios that don’t require full traffic hairpinning.
Microsoft Retiring MCSE, MCSD, and MCSA Certifications
Chris Pietschmann (Build5Nines) covered Microsoft’s decision to retire the MCSE, MCSD, and MCSA certification families in favour of role-based certifications. The retirement date was set for June 30, 2020, affecting 15 certifications and 42 individual exams.
Microsoft had signalled this direction as early as September 2018. The certifications being retired include:
- MCSA: BI Reporting, SQL Server (various tracks)
- MCSD: App Builder
- MCSE: Business Applications, Core Infrastructure, Productivity, Data Management and Analytics
“If you are on your path to earning these certifications, then you have until June 30, 2020 to pass the required exams to earn the certifications. After that date they will no longer be available to be earned. Once retired, these certifications will remain on your official Microsoft certification transcript… for 2 years from the June 30, 2020 date; after which they will be moved to the ‘inactive’ section of your transcript.”
— Chris Pietschmann, Build5Nines
Transitioning to Role-Based Certifications
There are no direct one-to-one replacements for the retiring certifications, but Microsoft was developing guidance for transitional learning paths. As an example, candidates holding or pursuing the MCSE: Core Infrastructure certification were pointed toward role-based alternatives such as:
- Azure Administrator Associate
- Azure Security Engineer Associate
- Azure Solutions Architect Expert
The new role-based certifications carry a two-year renewal cycle, which aligns with the two-year transcript retention window for retired credentials.
Cloud-Native Thinking: Containers, Kubernetes, and Serverless
Karim Vaes shared a reflective post on his journey migrating VMchooser toward a more serverless and container-based architecture. His observations offer a useful on-the-ground perspective for teams navigating similar decisions.
Why Containers?
Vaes developed an appreciation for containerization around 2015, valuing the portability and repeatability containers provide. He frames containers as a form of configuration management — similar in purpose to tools like Ansible or Puppet, but packaging the entire runtime environment rather than just configuration state.
Kubernetes for Hybrid and Cross-Platform Scenarios
Kubernetes earns a place in Vaes’s architecture primarily for its cross-platform capabilities and support for hybrid cloud scenarios, where workloads must run consistently across on-premises and cloud environments. For teams already invested in Kubernetes, a managed and certified Kubernetes service (such as AKS) is the pragmatic path forward.
The Case for Going Directly to Serverless
After experimenting with serverless, Vaes questioned why more teams don’t skip containers and Kubernetes entirely in favour of serverless architectures. His reasoning:
- Serverless is less infrastructure-oriented than Kubernetes, lowering operational overhead.
- Cost optimization is more straightforward — you pay per execution rather than for always-on compute.
- For applications that don’t require fine-grained orchestration, Azure App Service or Azure Container Instances may be sufficient without introducing a full Kubernetes control plane.
The practical takeaway for teams evaluating their cloud-native strategy: the right answer depends on workload requirements, team expertise, and operational maturity. Kubernetes is powerful but carries real complexity; serverless and PaaS offerings like App Service can deliver most of the benefits with less overhead for many application types.
This roundup covers community insights from March 2020. Some product features mentioned (such as Azure Firewall Manager preview) may have since reached general availability or changed. Always consult the current Azure documentation for up-to-date guidance.