Microsoft Azure pros share their insights on AKS cluster deployments with managed identity, a new AD Connect bug fix and validating Terraform code during a pull request.
Deploying an AKS cluster with managed identity
Daniel Neumann, writing on Daniel’s Tech Blog described a recent experience updating a Terraform AKS module, switching from Azure Active Directory service principal to managed identity while simultaneously switching from AD v1 to v2, which is managed. In its latest round of updates, Microsoft added improvements such as private cluster support, managed control plane SKU tier support, Windows node pool support, node labels support and a parameterized add-on profile section.
For users, the big benefit of the shift to managed identity is less regular credential support. He shared code samples to give fellow users a sense of what to expect when deploying the new module. Users should be aware that RBAC role assignment for managed identity is different than with service principal. He wrote:
For the necessary permissions on the Virtual Network subnet you use the AKS cluster managed identity. Allowing the AKS cluster to pull images from your Azure Container Registry you use another managed identity that got created for all node pools called kubelet identity. Beside that when you enable the add-ons Azure Monitor for containers and Azure Policy for AKS, each add-on gets its own managed identity.
Looking into AD Connect version 1.5.45.0
Microsoft MVP Sander Berkouwer, writing on The Things That Are Better Left Unspoken took a look at the recent release of AD Connect version 1.5.45.0. The new release represents a bug fix, fitting into an overall pattern of small hotfixes that usually come out after a big release. For users, this new hotfix resolves a number of minor issues.
Admins were having trouble enabling single sign-on if an AZUREADSSOACC computer account was present, as well as encountering incorrect import of disabled rules and issues with delta import actions.
Validating Terraform code during a pull request
Thomas Thornton demonstrated how to create a branch policy that runs a CI pipeline to validate Terraform code. He focused on a scenario involving a pull request in Azure DevOps with a YAML CI pipeline. For development teams, branch policies are an important way to protect branches of development and play a significant role in safeguarding a team’s code quality. He wrote:
Depending on how you create and test your Terraform code; you will probably be doing this type of test locally but during a pull-request it gives a piece of mind to the reviewer(s) that the Terraform pull-request has successfully been validated along with a plan that can be reviewed.
To get started, Thornton created a CI Pipeline in Azure DevOps and selected a repository, after first setting up a Storage Account, Resource Group, and container. The pipeline contains two stages: Validate, in which code is validated, and Plan, which moves to the next phase that results in a Terraform Plan being outputted. He shared a YAML pipeline and detailed how to apply a branch policy. Lastly, users will need to review the pipeline and the Terraform plan as part of a final pull request.
