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.

[pr0ton11]

This also affects our deployment.

If the cluster is shared between multiple tenants, copying the token and/or service account isn't feasible as it would expose the JWT directly to users of the clusters. I also agree that cluster-wide deployment as well as the allowedNamespaces key does not make any sense with this restriction in place.

If the intention was to deploy a cluster-wide vault connection, this seems to be a bug. Otherwise please communicate the restriction so we can look for alternatives.

[mskalka]

This is also impacting our use case. For security we would rather not share the approle secret ID around to every namespace that wants to use vault and creating a new approle for each namespace is cumbersome. If the auth resource accepts a namespace allow-list it should allow full cross-namespace operation. Otherwise what's the point of configuring global auth at all? Or give us the option to deploy a static or dynamic secret in the VSO namespace that writes a secret to the target namespace. That at least we can limit with policy.