Azure recently added Azure Workload Identities (see https://github.com/Azure/azure-workload-identity and https://azure.github.io/azure-workload-identity/docs/) to AKS. Officially the functionality is still in Preview, but the approach is quite stable and we are already using it in various production situations.

AWI is essentially the equivalent of AWS's IAM Roles for Service Accounts and works the same. I.e, your cluster becomes an OIDC identity provider and a specific service account in a specific namespace can be designated as federated principal to which Azure IAM roles can be attached. This is significantly more secure than using credentials (i.e. Service Principals with client secrets) or Managed Service Identities (for which the whole Node is able to assume the identity).

Also similarly to IRSA, AWI works by annotating a Service Account, as follows:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-dns
  namespace: external-dns
  labels:
    azure.workload.identity/use: 'true'
  annotations:
    azure.workload.identity/client-id: bbbbbbbb-xxx-yyyyy-mmmm-rrrrrrrrrr
    azure.workload.identity/service-account-token-expiration: '86400'
    azure.workload.identity/tenant-id: yyyyyyy-xxx-zzzz-xxxx-rrrrrrrrrrrrr

By attaching this ServiceAccount to a Pod, we get the following env vars in the Pod:

AZURE_AUTHORITY_HOST: https://login.microsoftonline.com/
AZURE_CLIENT_ID: bbbbbbbb-xxx-yyyyy-mmmm-rrrrrrrrrr
AZURE_FEDERATED_TOKEN_FILE: /var/run/secrets/azure/tokens/azure-identity-token
AZURE_TENANT_ID: yyyyyyy-xxx-zzzz-xxxx-rrrrrrrrrrrrr

At the location AZURE_FEDERATED_TOKEN_FILE a temporary token is mounted. To be able to use this we would just need to configure Azure authentication to use the AZURE_FEDERATED_TOKEN_FILE for login.

I would really love to see this supported in cert-manager.

/kind feature