Skip to content

v0.13.0-beta.0

Pre-release
Pre-release
Compare
Choose a tag to compare
@pst pst released this 07 Apr 11:57
· 320 commits to master since this release
bce1c45
  • 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 and kubeconfig outputs
    • The inheritance module now supports maps of objects not just maps of strings

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.