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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions