Support running the sidecar injector alongside EKS Pod Identities

[RyanW8]

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

• If applicable, I've documented the impact of any changes to security controls.

  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

We're running into an issue when using the Vault sidecar injector alongside EKS Pod Identities. Given a container in a pod with the following volumeMounts:

volumeMounts:
  - mountPath: /var/run/secrets/pods.eks.amazonaws.com/serviceaccount
    name: eks-pod-identity-token
    readOnly: true
  - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
    name: kube-api-access-cfjv5
    readOnly: true

The serviceaccount function (https://github.com/hashicorp/vault-k8s/blob/main/agent-inject/agent/agent.go#L778) by default looks for any volumemount where the mountPath contains serviceAccount, and in this scenario means that the vault sidecar injector picks the eks-pod-identity-token volume mount when building the VAULT_CONFIG environment var that gets injected into the pod/containers, which results in:

a lot of config below has been ommited for brevity
{
  "auto_auth": {
    "method": {
      "config": {
        "role": "...",
        "token_path": "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/token"
      }
    },
  },
}

So when the vault-agent-init container starts up we get the below logs:

2025-10-13T11:51:36.002Z [ERROR] agent.auth.handler: error getting path or data from method: error="error reading JWT with Kubernetes Auth: open /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/token: no such file or directory" backoff=4m48.51s

as the container is using the wrong path to load the SA token from which is used to authenticate with Vault.

In this PR I've added a new annotation vault.hashicorp.com/agent-service-account-token-volume-name-pattern. Similar to the existing vault.hashicorp.com/agent-service-account-token-volume-name pattern but it allows us to pattern/glob match the volume name that contains the projected SA token. Since v1.22 Kubernetes has automatically added (enabled by default) a projected volume to all pods named kube-api-access-<random-suffix> which contains the SA token, ca cert and namespace. This change allows us to use this volume in conjunction with EKS Pod Identities by setting:

metadata:
  annotations:
    vault.hashicorp.com/agent-service-account-token-volume-name-pattern: "kube-api-access*"

which will assist the sidecar injector in selecting the correct volume containing the SA token

[hashicorp-cla-app]

All committers have signed the CLA.

[RyanW8]

@tvoran can we get reviews please?