feat(credential-provider): support k8s service account token

[mainred]

What type of PR is this?

/kind feature

What this PR does / why we need it:

kubernetes/enhancements#4412

Which issue(s) this PR fixes:

Fixes #8837

Tests I have been done

On a 1.33.0 cluster, I enabled workload identity on AKS cluster, and granted the identity, linked to the service account, permission to acrpull access.
I used the projected service account token azure-identity-token and get access token successfully

echo "{\"kind\":\"CredentialProviderRequest\",\"apiVersion\":\"credentialprovider.kubelet.k8s.io/v1\",\"image\":\"qingchuanhao.azurecr.io/nginx:v1\",\"serviceAccountToken\":\"<azure-identity-token>\",\"serviceAccountAnnotations\":{\"azure.workload.identity/client-id\": \"a202f4e5-8b33-48ec-8c0d-f1d25e8b4290\", \"azure.workload.identity/tenant-id\": \"72f988bf-86f1-41af-91ab-2d7cd011db47\"}}"| /var/lib/kubelet/credential-provider/acr-credential-provider /etc/kubernetes/azure.json

{"kind":"CredentialProviderResponse","apiVersion":"credentialprovider.kubelet.k8s.io/v1","cacheKeyType":"Registry","cacheDuration":"5m0s","auth":{"*.azurecr.*":{"username":"","password":""},"qingchuanhao.azurecr.io":{"username":"00000000-0000-0000-0000-000000000000","password":"<acces token>"}}}

I then use the token the login the acr and pull the acr image successfully

docker login qingchuanhao.azurecr.io -u 00000000-0000-0000-0000-000000000000 -p <access-tokn>

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
  - name: acr-credential-provider
    matchImages:
      - "*.azurecr.io"
      - "*.azurecr.cn"
      - "*.azurecr.de"
      - "*.azurecr.us"
    defaultCacheDuration: "10m"
    apiVersion: credentialprovider.kubelet.k8s.io/v1
    tokenAttributes:
      serviceAccountTokenAudience: api://AzureADTokenExchange
      # requireServiceAccount is set to true, so the plugin will only be invoked if the pod has a service account
      requireServiceAccount: true
      requiredServiceAccountAnnotationKeys:
      - azure.workload.identity/client-id
    args:
      - /etc/kubernetes/azure.json

Special notes for your reviewer:

Does this PR introduce a user-facing change?

feat(credential-provider): support k8s service account token

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mainred
Once this PR has been reviewed and has the lgtm label, please assign nilo19 for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[aramase]

@mainred any update on this PR?

[mainred]

@aramase, I have updated the PR description with my test and setup.
I think we need only client ID annotation, for the other information, we can get config file. cross-tenant is not supported before this change.
I tried to skip passing config file but considering 1. config file must be there for other node components like kubelet, 2 we may need the authority host from the config, I keep using config file as a managed solution. We can provide all the required info in the pod annotations though, but not sure how we'll add these annotations from another component like azure-workload-identity webhook?

[coveralls]

coverage: 74.425% (-0.2%) from 74.648%
when pulling b7fedab on mainred:ksa-token-credential-provider
into c811ba8 on kubernetes-sigs:master.