Skip to content

Expose --audience flag as configurable Helm value #1675

@chamsTmar1

Description

@chamsTmar1

Is your feature request related to a problem? Please describe.

I'm running Azure Workload Identity on a self-managed Kubernetes cluster and need to use a custom audience value (for example some-domain.com) instead of the default api://AzureADTokenExchange.

This is necessary because we use the same OIDC issuer for multiple cloud providers (AWS, Azure, GCP) and want a neutral audience that works across all of them.

Currently, the --audience flag exists in the webhook code under cmd/webhook/main.go but is not exposed as a configurable Helm chart value. Thus, the webhook always injects projected service account tokens with the hardcoded default audience api://AzureADTokenExchange, even when:

  • The K8s API server is configured with a custom --api-audiences value
  • The Azure federated identity credential is configured to accept the custom audience

I get Microsoft Entra ID error (invalid_client) AADSTS700212: No matching federated identity record found for presented assertion audience 'api://AzureADTokenExchange'. Please check your federated identity credential Subject, Audience and Issuer against the presented assertion which is a common error in other issues but none of those issues was related to audience (all of them set the audience to api://AzureADTokenExchange, even the Azure documentation says it is recommended to use that expected audience)

Describe the solution you'd like

Add an audience field to values.yaml that gets passed as the --audience flag to the webhook deployment (default to api://AzureADTokenExchange)

Describe alternatives you've considered

  1. Manually patching the deployment:
   kubectl edit deployment azure-wi-webhook-controller-manager -n azure-workload-identity-system
   # Manually added --audience=another-domain.com to args

It does work. However, this is a temporary solution as it will be lost on helm upgrades

  1. Manually specifying projected token volumes in each pod (in other words: not using the webhook):
   volumes:
   - name: azure-identity-token
     projected:
       sources:
       - serviceAccountToken:
           audience: another-domain.com

That defeats the purpose of using the webhook + it must be repeated in every pod spec

  1. Forking and maintaining a custom chart: That's the way to go for now, but it's still preferred to add this feature to the project so that it's maintained and others could benefit from it

Additional context

  • The charts/workload-identity-webhook README states that:

Helm chart is autogenerated from the Azure AD Workload Identity static manifest. The generator code lives under third_party/open-policy-agent/gatekeeper/helmify. To make modifications to this template, please edit kustomization.yaml, kustomize-for-helm.yaml and replacements.go under that directory and then run make manifests. Your changes will show up in the manifest_staging directory and will be promoted to the root charts directory the next time an azure-workload-identity release is cut.

  • This feature would align with similar patterns in AWS IRSA and GCP Workload Identity where audiences are configurable
  • The Azure documentation states that api://AzureADTokenExchange is recommended (didn't state it's a must). Thus, custom audiences should logically be supported as long as they match between the token and the federated credential
  • Multi-cloud environments are increasingly common and a configurable audience simplifies OIDC federation management across providers

I'm happy to submit a PR if this feature aligns with the project's goals. Otherwise, if there are reasons it is hardcoded to api://AzureADTokenExchange and this was intentional, I'm curious to know why

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions