[vault-secrets-webhook] Incorrect audience for JWT tokens

[adisong]

Describe the bug:
bank-vaults/bank-vaults#1752 added new feature that creates SA JWT tokens using api-server if they are not created automatically, which is now the default behaviour for k8s 1.24. When this token is created it is given explicit/hardcoded audience claim which makes this token invalid when it's used to authenticate with k8s api-server. Vault kubernetes auth backend can either use it's own JWT to create token reviews or it can use token presented by client. In the latter case this now fails because audience does not match.

Expected behaviour:
Tokens created by vault-secrets-webhook should not have audience claim specified or at least this claim should be configurable using annotations.

Steps to reproduce the bug:

• configure Vault kubernetes backend with empty token_reviewer_jwt so it uses token
  presented on login to create token reviews
• create ServiceAccount on k8s 1.24
• use that ServiceAccount for Secret mutation with vault-secrets-webhook

Additional context:

When kubernetes auth fails vault gives this error log. It tries to use token created by vault-secrets-webhook to lookup JWT with tokenReview API but fails because this JWT is unauthorized due to invalid audience:

vault 2023-05-10T09:25:28.811Z [DEBUG] auth.kubernetes.auth_kubernetes_304be248: login unauthorized: err="lookup failed: service account unauthorized; this could mean it has been deleted or recreated with a new token"

Environment details:

• Kubernetes version (e.g. v1.10.2): v1.24.10
• Cloud-provider/provisioner (e.g. AKS, GKE, EKS, PKE etc): GKE
• bank-vaults version (e.g. 0.4.17): 1.9.0
• Install method (e.g. helm or static manifests): helm
• Logs from the misbehaving component (and any other relevant logs):
• Resource definition (possibly in YAML format) that caused the issue, without sensitive data:

/kind bug

[github-actions]

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 20 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.