defaultAuth not working with approle

[shehzadqureshi]

Describe the bug
I have configured VSO helm chart to have a default connection and default auth. Default auth is using appRole mount, with a secret that has the id key in the same namespace as the operator.

When trying to create a VaultStaticSecret that should reference the default connection and auth, i'm getting errors saying it cannot find the approle secret referenced above.

{"level":"error","ts":"2025-01-09T00:28:49Z","msg":"Failed to get secret","controller":"vaultstaticsecret","controllerGroup":"secrets.hashicorp.com","controllerKind":"VaultStaticSecret","VaultStaticSecret":{"name":"gitlab-pull-secret","namespace":"gitlab"},"namespace":"gitlab","name":"gitlab-pull-secret","reconcileID":"fcfd47a3-bdb1-4e10-bb10-9bea37a09893","secret_name":"vault-approle-credentials","error":"secrets \"vault-approle-credentials\" not found"}
{"level":"error","ts":"2025-01-09T00:28:49Z","logger":"cachingClientFactory","msg":"Failed to get cacheKey from obj","controller":"vaultstaticsecret","controllerGroup":"secrets.hashicorp.com","controllerKind":"VaultStaticSecret","VaultStaticSecret":{"name":"gitlab-pull-secret","namespace":"gitlab"},"namespace":"gitlab","name":"gitlab-pull-secret","reconcileID":"fcfd47a3-bdb1-4e10-bb10-9bea37a09893","error":"secrets \"vault-approle-credentials\" not found"}

To Reproduce
Steps to reproduce the behavior:

1. Deploy VSO helm chart with default connection and default auth using approle.
2. Manually define approle secret id in a secret ref and specify that above in the helm chart for defaultAuthMethod.appRole.secretRef
3. Try to create a VaultStaticSecret in any other namespace without specifying vaultAuthRef.
4. See error (vault-secrets-operator logs)
5. Try to create VaultStaticSecret and specify vaultAuthRef=some-namespace/default.
6. See error.

Application deployment:
Helm deployment (v0.9.1).

  defaultVaultConnection:
      address: ...
      enabled: true
      caCertSecret: ...
    controller:
      replicas: 2
      strategy:
        rollingUpdate:
          maxSurge: 1
          maxUnavailable: 0
        type: RollingUpdate
    defaultAuthMethod:
      enabled: true
      allowedNamespaces:
        - '*'
      method: appRole
      mount: approle
      namespace: ...
      appRole:
        roleId: ...
        secretRef: <secret-name-to-be-used>

The secret clearly exists

~ kb get secret -n vault-secrets-operator vault-approle-credentials
NAME                        TYPE     DATA   AGE
vault-approle-credentials   Opaque   1      85d

Expected behavior
The expectation is that the static secret will use the default auth when not specified.

Environment

• Kubernetes version:
  • Distribution or cloud vendor (OpenShift, EKS, GKE, AKS, etc.): 1.30
  • Other configuration options or runtime services (istio, etc.): n/a
• vault-secrets-operator version: 0.9.1 helm release

[freimer]

The secret must be in the namespace where the VaultStaticSecret is / VSO will deploy the Kubernetes Secret. You can't use a cluster-wide secret for all namespaces. This is documented. See: https://developer.hashicorp.com/vault/docs/platform/k8s/vso/api-reference#vaultauthconfigapprole

SecretRef is the name of a Kubernetes secret in the consumer's (VDS/VSS/PKI) namespace which provides the AppRole Role's SecretID. The secret must have a key named id which holds the AppRole Role's secretID.

Note the reference to the consumer's namespace.

[shehzadqureshi]

I'm not sure I understand... are you saying that the consumer is whoever needs to use the default auth? if so, then that consumer can technically be in any namespace and makes the default auth set up moot.

You can't use a cluster-wide secret for all namespaces

The Secrets are namespaced. If the secret can only be used in a single namespace - where VSS is being defined - then what is the purpose of allowedNamespaces? I don't really see how that can be used effectively.

My goal here is to avoid duplicating the default vault auth secret in every namespace that needs it.