Add namespace reader RBAC for Kubernetes auth selector support

[fvrk4n]

Problem

When using bound_service_account_namespace_selector in Vault's Kubernetes auth method configuration, authentication fails with a 403 error because Vault lacks permissions to read namespace metadata.

Error Observed

I wanted to use the "Bound service account namespace selector" option as
{"matchLabels":{"vault-secrets-operator/enabled":"true"}}
After creating a "VaultStaticSecret" within a namespace containing the relevant label, I encountered the following logs in the Vault Secrets Operator "VSO" pod logs.

{
  "level": "error",
  "ts": "2026-01-24T18:23:03Z",
  "msg": "Failed to get NewClientWithLogin",
  "error": "Error making API request.\n\nURL: PUT [https://vault-active.vault.svc.cluster.local](https://vault-active.vault.svc.cluster.local):8200/v1/auth/kubernetes/login\nCode: 403. Errors:\n\n* namespace not authorized err=failed to get namespace (code 403 status namespaces \"minio\" is forbidden: User \"system:serviceaccount:vault:vault\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"minio\")"
}

Determination

kubectl auth can-i get namespaces --as=system:serviceaccount:vault:vault
Warning: resource 'namespaces' is not namespace scoped
no

Root Cause

To verify namespace labels, Vault must read namespace resources from the Kubernetes API. However, the Helm chart only creates a ClusterRoleBinding for system:auth-delegator (token review), not for namespace reading.

Solution

• ClusterRole granting get permission on namespaces resources
• Binds the ClusterRole to Vault's ServiceAccount
• Unit tests - 12 tests covering enable/disable conditions and RBAC validation

Design Decisions

• Minimal permissions: Only get verb (not list or watch) as Vault only needs to read specific namespaces
• Conditional creation: Uses serverAuthDelegator condition - only created when Kubernetes auth is enabled
• No configuration required: Automatically enabled when applicable, no values.yaml changes needed

Backwards Compatibility

Fully backwards compatible - existing deployments are unaffected.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

Furkan Akman seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA.
If you have already a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}