Using remote namespace with VaultAuthRef doesn't work with approle secretid unless copied to local namespace

[MyCodeIsSchmidt]

Describe the bug

Not sure if this is a bug report or feature request, or if its even possible.

When using vauthAuthRef to point to a VaultAuth in an external namespace, it is unable to reference the approle secretid when stored in a kubernetes secret.

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: test-vault-sync
  namespace: notvault
spec:
  type: kv-v2
  mount: prod
  path: test/config
  destination:
    name: testsecret1
    create: true
  refreshAfter: 30s
  vaultAuthRef: vault/static-auth

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultAuth
metadata:
  name: static-auth
  namespace: vault
spec:
  method: appRole
  mount: vault-secrets-operator-approle
  vaultConnectionRef: vault/default
  allowedNamespaces:
    - "*"
  appRole:
    roleId: 'xxxx'
    secretRef: vault-secrets-operator-approlesecret

Results in the following error:

Failed to get cacheKey from obj, err=Secret "vault-secrets-operator-approlesecret" not found    {"type": "Warning", "object": {"kind":"VaultStaticSecret","namespace":"notvault
","name":"test-vault-sync","uid":"xxxx","apiVersion":"secrets.hashicorp.com/v1beta1","resourceVersion":"1062772150"}, "reason": "Unrecoverable"}

Failed to get Vault auth login: Secret "vault-secrets-operator-approlesecret" not found    {"type": "Warning", "object": {"kind":"VaultStaticSecret","namespace":"notvault","na
me":"test-vault-sync","uid":"xxxx","apiVersion":"secrets.hashicorp.com/v1beta1","resourceVersion":"1062772150"}, "reason": "VaultClientConfigError"}

As soon as I add the kube secret 'vault-secrets-operator-approlesecret' to the 'notvault' namespace as well, it starts to work again.

Obviously it is not ideal to have to copy the secretid into every namespace that requires it, as rotating that secret would now become costly in an environment with dozens of namespaces. Is there a better way to do this? Or am I asking for something that just isn't possible? Thank you.

Expected behavior

VaultStaticSecret in a namespace outside of the VaultAuth object, but referenced with refVaultAuth, is able to use the secrets referenced in VaultAuth without copying them to the local namespace.

Environment

• Kubernetes version: GKE 1.26
• vault-secrets-operator version: 0.4.3

[AlexanderK46]

Hi!. We also encountered this problem.

The VaultAuth resource containing the reference to the AppRole secret and the Secret resource containing the AppRole SecretID were created in the operator namespace. They are managed by the infrastructure team.

VaultStaticSecret resources have been created in the product namespace. They contain references to the VaultAuth resource with an explicitly specified operator namespace. They are managed by the product team.

The infrastructure team, as the owner of the AppRole SecretID, does not share it with the product team.

We expect that the operator will be able to create Secrets in the product namespace if this namespace is included in the list of allowed ones in the VaultAuth, and we do not need to duplicate the Secret resource containing the AppRole SecretId in the product namespace.

Environment

• Kubernetes version: 1.25.6
• vault-secrets-operator version: 0.5.2

[TJM]

Suggestion: Use Kubernetes Auth. Approle is little more than a username/password, if you use kubernetes auth, you can specify a list of service accounts, in a list of namespaces (hint: '*' works here). You could then avoid having to manage the approle secret in the first place, you just need a kubernetes service account and the VaultAuth

[JustChasti]

Have the same issue

I can't use alternative methods such as kubernetes login and jwt Maybe some of you were able to solve this problem, if so, please share your experience

as I saw even in the chart-values said that

"SecretID, and must exist in the namespace of any consuming VaultSecret CR."

Environment

• VSO version: 0.8.1
• Kubernetes version: 1.28.8