azure: Add Workload Identity support

The primary data-model change is the addition of WorkloadIdentityClientID string to the AzureSpec struct in the internal API (componentconfig.go) and both versioned API packages (v1alpha2, v1alpha3); all three definitions carry identical JSON tags and doc-comments, which is the correct pattern for kops' multi-version API.

The auto-generated conversion files (zz_generated.conversion.go) are updated in both directions for each API version, ensuring the field round-trips without loss when a cluster object is read from or written to any supported API version — this is critical for backwards compatibility.

AzureNetworkSecurityGroupName() is refactored to delegate to the new AzureNetworkName() helper rather than containing its own copy of the NetworkID-or-cluster-name logic; this eliminates a subtle duplication risk where the two functions could drift apart in future changes.

AzureWorkloadIdentityName() centralises the name derivation rule ("wi-" + strings.ReplaceAll(c.Name, ".", "-")) so that both the pre-flight check in apply_cluster.go and the task-graph entry in azuremodel are guaranteed to produce the same string — previously any inline derivation at two call sites was a correctness hazard.

The naming transformation in AzureWorkloadIdentityName() replaces dots with hyphens, which is important because Azure resource names generally do not allow dots, but the rule is applied only to dots; other characters that are valid in Kubernetes cluster names (e.g. underscores, colons) are not sanitised, which could be a latent issue for non-standard cluster names.

This piece introduces the armmsi v1.3.0 library as a direct dependency in go.mod, placed alongside other Azure SDK resource manager packages in the require block, keeping the dependency list consistently organized.

The corresponding go.sum entries (both the module zip hash and the go.mod hash) are added, ensuring Go's module authentication mechanism can verify the integrity and authenticity of the downloaded package.

The vendor directory is also updated to include the vendored source of the library, which is consistent with the project's apparent use of go mod vendor — meaning the code is checked into the repo and no network access is needed at build time.

The version v1.3.0 is a stable release of the armmsi SDK, so there are no pre-release or beta stability concerns unlike, for example, the armauthorization/v3 v3.0.0-beta.2 already present in the file.

This change is purely additive and infrastructural — it does not alter any existing code paths, making the risk of regression very low.

The ManagedIdentity task follows the standard kops fi.Task pattern: Find queries Azure and returns an existing-state object, CheckChanges validates immutable fields, and RenderAzure performs the actual create-or-update.

A key design choice in ManagedIdentity.Find is that it writes ClientID and PrincipalID back onto the expected task (m) in addition to the returned actual object — this mirrors the VMScaleSet.Find convention and ensures dependent tasks (RoleAssignment, cloud config generation) can read these server-generated IDs even when the UAMI hasn't changed and RenderAzure is never called.

FederatedIdentityCredential holds a pointer to ManagedIdentity and uses its name (not ID) as an API key — the armmsi API scopes federated credentials by resource group + UAMI name + credential name, so the task naturally expresses this three-part ownership.

The RoleAssignment refactor introduces principalID() to cleanly abstract over two possible principal sources, removing the hard dependency on VMScaleSet.PrincipalID and making the Find early-exit logic (nil PID → skip) work for both cases.

The VMSS list-and-search logic in RoleAssignment.Find is now gated behind r.VMScaleSet != nil, so ManagedIdentity-backed role assignments avoid an unnecessary and potentially expensive list API call.

In createNewRoleAssignment, e.VMScaleSet.PrincipalID is replaced with e.principalID(), completing the abstraction so the same assignment creation path serves both principal types without duplication.

The core addition is two new methods on AzureBlobPath in azureblob.go. GetHTTPsUrl() assembles the canonical blob HTTPS URL using the well-known Azure Blob endpoint pattern (<account>.blob.core.windows.net/<container>/<key>), relying on the AZURE_STORAGE_ACCOUNT environment variable for the account name — a piece of information not stored on the path struct itself.

IsBucketPublic() uses the existing getClient() helper to obtain an Azure SDK client, then calls GetProperties on the container. The check is simple: Azure SDK represents a private container by leaving BlobPublicAccess nil, so any non-nil pointer value means public access is enabled at some level (blob or container). Importantly, the comment explicitly states that kops does not manage the ACL itself — callers must pre-configure the container.

In validation/legacy.go, the new case *vfs.AzureBlobPath is inserted into the existing type switch, which is the minimum change needed to stop rejecting Azure Blob paths. The error message on the default branch is also updated to accurately reflect which VFS types are now supported.

In discovery.go, the BuildOptions method's type switch gains the analogous case *vfs.AzureBlobPath that calls base.GetHTTPsUrl() and assigns the result to serviceAccountIssuer, exactly mirroring the GCS path handling pattern already in place.

The three changes together form a complete, coherent feature: the VFS layer knows how to produce the public URL and check container publicity, validation accepts the new type, and the options builder uses the URL as the OIDC issuer.

The Build method uses a type switch on the discoveryStore VFS path to handle each storage backend differently.

For Azure Blob, unlike S3 or GCS which support per-object ACLs, Azure enforces access at the container level (Private / Blob / Container modes), so kops cannot programmatically set a public ACL on individual blobs after upload.

The new case *vfs.AzureBlobPath block calls discoveryStore.IsBucketPublic(ctx) to check whether the container was pre-configured for anonymous "Blob" access by the user.

If the container is not public, Build returns a descriptive error immediately, preventing silent failures where OIDC discovery documents would be uploaded but be inaccessible to AAD token exchange.

If the container is public, the code falls through naturally to whatever downstream publishing logic already exists (shared after the switch), mirroring the S3 and GCS cases without duplicating upload logic.

The Build method is guarded by UseServiceAccountExternalPermissions(), so it short-circuits and is a no-op for clusters that do not use OIDC-based workload identity — this is the correct escape hatch.

It then validates that ServiceAccountIssuer is non-empty, since the issuer URL is the OIDC endpoint that Azure AD must trust for token exchange; without it the federated credentials would be meaningless.

The UAMI task is added first and stored in a local variable (uami), which is then referenced directly by both the RoleAssignment and FederatedIdentityCredential tasks — this establishes implicit task ordering in the kops dependency graph without explicit GetDependencies wiring.

The Contributor role is assigned at the resource-group scope using a hardcoded well-known Azure built-in role definition GUID (b24988ac-6180-42a0-ab88-20f7382dd24c), and the role assignment name is hardcoded to "wi-uami-contributor", which will collide if multiple clusters share the same resource group.

Two federated identity credentials are registered — one for cloud-controller-manager and one for csi-azuredisk-controller-sa, both in kube-system — using the standard Kubernetes service account subject format (system:serviceaccount:<ns>:<sa>).

The audience is hardcoded to api://AzureADTokenExchange, which is the correct and expected value for Azure AD workload identity federation, so this is intentional and correct.

Notably, there is no federated identity credential for other Azure-dependent components (e.g., external-dns, cluster-autoscaler), which may be a conscious MVP scope decision but could surface as a gap for adopters.

The change introduces a binary branching strategy inside both YAML templates: when UseServiceAccountExternalPermissions is true the components use Azure Workload Identity (OIDC federation), and when false they fall back to the existing Managed Identity / host-path approach, ensuring backwards compatibility for clusters that don't opt in.

For the CCM, the Workload Identity path emits a new Secret/azure-cloud-provider at the very top of the template (before the ServiceAccount) with the cloud-config JSON baked in; it sets useFederatedWorkloadIdentityExtension: true, aadFederatedTokenFile to the projected token path, and aadClientID to the workload identity client ID obtained via AzureWorkloadIdentityClientID.

The CCM Deployment's volumeMounts section then branches: under Workload Identity, /etc/kubernetes is served from the Secret (key cloud-config → azure.json), and the MSI host-path mount is suppressed; under legacy, the original hostPath mounts for /etc/kubernetes and /var/lib/waagent/ManagedIdentity-Settings are retained unchanged.

The azure-identity-token projected volume (audience api://AzureADTokenExchange, 3600s expiry) already existed in the CCM template before this PR and is kept unconditionally — only its corresponding volumeMount is now made conditional on Workload Identity, which raises a question about whether the volume definition should also be gated.

For the azuredisk-csi controller, the change is purely additive: a new projected serviceAccountToken volume and mount are injected only when UseServiceAccountExternalPermissions is true, using the same audience and expiration settings as the CCM, allowing the CSI driver to also exchange tokens with Azure AD via OIDC.

The CSI driver's existing azure-cred volume (a hostPath to /etc/kubernetes/) is left untouched in both paths, implying it still carries a cloud-config file on the node — this may still reference MSI or client-secret settings depending on how the node is provisioned, so reviewers should verify that the CSI driver actually reads the token file when Workload Identity is active and ignores the legacy credentials in azure-cred.

The test wires into the existing integration-test framework via newIntegrationTest("minimal-azure.example.com", "minimal_azure_wi").withVersion("v1alpha3").runTestTerraformAzure(t), which drives kops update cluster against an in-memory store, serialises all produced Terraform resources, and diffs them against the golden files under tests/integration/update_cluster/minimal_azure_wi/data/.

The core behavioural difference from TestMinimalAzure is the cluster spec field iam.useServiceAccountExternalPermissions: true, which activates the Workload Identity rendering path; the completed spec golden file confirms serviceAccountIssuer and serviceAccountJWKSURI are set, and apiAudiences includes kubernetes.svc.default.

The CCM addon golden file (azurerm_storage_blob_minimal-azure.example.com-addons-azure-cloud-controller.addons.k8s.io-k8s-1.31_source) is the most important WI-specific artifact: it shows useFederatedWorkloadIdentityExtension: true, aadFederatedTokenFile: /var/run/secrets/azure/tokens/azure-identity-token, and aadClientID: "" — confirming no client-secret is injected — plus a projected serviceAccountToken volume with audience api://AzureADTokenExchange on the CCM Deployment.

Similarly, the CSI controller Deployment golden file carries the same azure-identity-token projected volume mount on the azuredisk container, locking in that both the CCM and the azuredisk-csi controller use WI token projection rather than a client credential Secret.

The OIDC golden files (discovery.json and keys.json) capture the issuer URL https://discovery.example.com/minimal-azure.example.com and the two test RSA public keys, ensuring the OIDC discovery document and JWKS blob are rendered correctly when WI is active.

The user-data scripts for both the control-plane and node VMSS are essentially identical to the non-WI scenario (bootstrapping nodeup via kube_env.yaml), which is expected because WI only affects in-cluster addon configuration, not the node bootstrap process itself.

The etcd-manager pod manifests and healthcheck sidecar are also captured, so any accidental collateral changes to those resources will be caught even though they are unrelated to WI.