If you have ever deployed an AKS Cluster, you know that a Service principal is a prerequisite. The portal kind of hid this away because in the first step, it would actually create one for you and then just use that to create the cluster. This actually ended up being kind of a mess because you would end up with service principals names like myclusterNameSP-20190724103212
.
A better way was to create the Service Principal first as a separate step either in the portal or in your Terraform template. This still was a bit annoying because if you were using a 1 year or 2 year expiration (you shouldn’t use SP’s that don’t expire!) because you would need to update the cluster credentials on a regular basis.
Enter Managed Identity
Early last month, Managed Identity for AKS finally went GA! A managed identity is a wrapper around a Service Principal. All credentials are managed internally and the resources that are configured to use that identity, operate as it.
With the release of the 2.5.0
version of the azurerm
provider, managed identity is a first class citizen but you might not find it unless you know what you are looking for.
Under the azurerm_kubernetes_cluster
, you just need to add a new identity section
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks1"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
dns_prefix = "exampleaks1"
default_node_pool {
name = "default"
node_count = 1
vm_size = "Standard_D2_v2"
}
identity {
type = "SystemAssigned"
}
tags = {
Environment = "Production"
}
}
You will also want to make sure that you are not specifying a service_principal
section anymore as well. I will also note that changing from a service principal to managed identity will cause an existing cluster to be recreated so use caution!
Changing from a service principal to a managed identity will cause an existing cluster to be recreated!
Once you create your new cluster, you will also have a new managed identity that you can now reference. Its name will be the name of your AKS cluster plus -agentpool
appended to the end.
If you need to now give this identity access to resources, you can use azurerm_user_assigned_identity
like this.
data "azurerm_user_assigned_identity" "test" {
name = "${azurerm_kubernetes_cluster.example.name}-agentpool"
resource_group_name = azurerm_kubernetes_cluster.example.node_resource_group
}
A common use case for permissions is to grant image pull to a container registry for your AKS Cluster. You can configure that like this.
resource "azurerm_container_registry" "acr" {
name = "aksmiexampleregistry"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
sku = "Standard"
admin_enabled = false
}
resource "azurerm_role_assignment" "acrpull_role" {
scope = azurerm_container_registry.acr.id
role_definition_name = "AcrPull"
principal_id = data.azurerm_user_assigned_identity.test.principal_id
skip_service_principal_aad_check = true
}
Managed Identity is definitely a very powerful tool and it’s great to see it finally available for AKS! I hope this post helps you configure Managed Identity with AKS. If you have any questions please leave a comment below!
For a full example, see this gist.
Comments