v0.13.0-beta.0
Pre-release- EKS: Provision OIDC provider to support IAM roles for service accounts
- GKE: Enable workload identity support by default
- AKS: Use managed identities instead of service principals by default
- AKS: Add support to set the
sku_tier
- thanks @to266 - Preparations towards a stable interface to extend Kubestack with bespoke modules
- All cluster modules now provide
current_config
,current_metadata
andkubeconfig
outputs - The inheritance module now supports maps of objects not just maps of strings
- All cluster modules now provide
Upgrade Notes
Please note, Pod-managed identities, the Azure equivalent to Google workload identity and AWS IAM roles for service accounts, is only in preview and not available through the Azure Terraform provider yet. As such, this release only adds support for improved IAM integration on GKE and EKS.
EKS
Migrate to IAM roles for service accounts (IRSA)
The EKS module now provisions an OIDC provider by default to enable IAM roles for service accounts. Users that wish to not provision the OIDC provider can disable this by setting disable_openid_connect_provider = true
.
Using IRSA, in addition to the OIDC provider, requires configuring IAM roles and Kubernetes annotations. Refer to the EKS documentation for more details. This feature alone, does not prevent workloads on the cluster from assuming node roles.
GKE
Migrate to workload identities
The GKE module now by default enables workload identities support on the cluster and sets the workload metadata config for the default node pool to GKE_METADATA_SERVER
.
Terraform generates an in-place update but the migration may cause disruptions if workloads currently depend on node roles. Please refer to the GKE documentation for more information.
To retain the previous behaviour, Kubestack users can set disable_workload_identity = false
or alternatively leave workload identity enabled but set the workload metadata config explicitly, e.g. node_workload_metadata_config = "EXPOSE"
.
AKS
Migrate from service principals to managed identities
AKS requires a service principal to grant the Kubernetes control plan access to the Azure API, to e.g. provision loadbalancers. AKS has moved from manual service principals to managed identities. From the Azure documentation:
Clusters using service principals eventually reach a state in which the service principal must be renewed to keep the cluster working. Managing service principals adds complexity, which is why it's easier to use managed identities instead.
The change in Terraform triggers a destroy-and-recreate plan for the cluster and its dependencies.
Users may be able to migrate by following the Azure documentation to manually migrate from service principals to managed identities using the az
CLI, before running the Terraform apply. At the time of writing the upgrade is marked as a preview feature. Please refer to the upstream documentation but the following worked during release testing:
az extension add --name aks-preview
# needs Owner permissions
az aks update -g RESOURCE_GROUP -n CLUSTER_NAME --enable-managed-identity
az aks nodepool upgrade --cluster-name CLUSTER_NAME --name default --node-image-only --resource-group RESOURCE_GROUP
After that, a Terraform plan will merely destroy the old service principal related resources, but not recreate the cluster.
Kubestack AKS users that wish to not migrate and retain the previous configuration using manually maintained service principals can set disable_managed_identities = true
instead of doing the manual migration.