The May update of AKS on Azure Stack HCI and Windows Server is now available!
This is primarily a security and quality update, however, we did add the ability to update no_proxy configurations and have improved cert management . While not a product change, we published guidance for integrating AAD role based access controls (RBAC) with kubernetes RBAC.
As always, you can try AKS on AzureStack HCI or Windows Server any time by registering here. If you do not have the hardware handy to evaluate AKS on physical hardware you can use an Azure VM: https://aka.ms/aks-hci-evalonazure.
Here are some of the changes you'll see in this update:
Update proxy exclusion list (no-proxy settings) without needing to redeploy using PowerShell
If you want to change the proxy exclusion list for your AKS deployment (which may happen if you have trusted components outside your corporate environment), we now offer the ability to change that proxy exclusion list post deployment using PowerShell. Previously, you'd need to redeploy in order to change your proxy exclusion settings. Once the list has been updated, changes will take effect at the next AKS update.
For example, running `Set-AksHciProxySetting -noProxy constoso.azurecr.io` adds the URL to the proxy exclusion list for your AKS deployment. Read more.
Guidance for using Azure AD (AAD) for Kubernetes role based access control (RBAC)
Kubernetes has many tools for configuring role-based access controls (RBAC), many of which are based on tokens. Managing certs and tokens is annoying over time deferred maintenance can lead to an insecure Kubernetes deployment. This is why I'm so excited to share that we now have guidance for AKS cluster administrators to configure Kubernetes RBAC roles using Azure Active Directory (Azure AD) for user authentication!
In this configuration, AKS cluster administrators can use the built-in Kubernetes role-based access control (Kubernetes RBAC) or make custom RBAC roles to manage access to namespaces and cluster resources based on a user's identity or group membership in Azure AD.
Clusters users simply have to login to Azure and use Azure Arc to access the cluster namespace from anywhere. For more information and a step-by-step guide, read more in the docs.
Improved our certificate management and added instructions for repairing expired internal certificates
Now that AKS on HCI and Windows Server has been in market for a year (!) we're beginning to run into cert lifecycle issues based on cert lifecycle and rotation both with our internal certificates and the certificates people add so that Kubernetes can run in your own unique IT environment.
We have done several things to help with certificate lifecycle:
We strategically modified the lifecycle of our internal certs to span 2 releases incase folks skip an update.
We're introducing new certificate repair cmdlets.
Security and reliability improvements
Updated versions of underling components:
New Mariner kernel version with too many CVEs fixed to list. Read more about the May Mariner Update.
Updated to CAPI v0.4.8
Updated ContainerD to 1.5.9
Updated Calico versions to match between Windows and Linux nodes
CAPH pod had been failing to renew its certificate, causing the certificate to expire - we have fixed this so certs renew appropriately.
We published a of new documentation this month from new docs supporting AAD RBAC, no-proxy changes, more troubleshooting guides, and some language changes.
While largely clerical, this month includes a language shift from "AKS on HCI" to "AKS on HCI or Windows Server" throughout our docs. We were finding that the service name (AKS-HCI) was leading to confusion about Windows Server support. This should be much less confusing with the latest round of doc changes.
Last but not least, we also published new troubleshooting guides:
Once you have downloaded and installed the AKS on Azure Stack HCI April Update – you can report any issues you encounter and track future feature work on our GitHub Project at https://github.com/Azure/aks-hci.