Allow sharing of VaultConnection and VaultAuth resources across namespaces

[Ahmedftw]

Is your feature request related to a problem? Please describe:
Currently, when using the Vault Secret Operator, users have to create VaultConnection and VaultAuth resources in every namespace where they need to access secrets from Vault. This leads to duplication of resources.

Describe the solution you'd like:
It would be helpful if the Vault Secret Operator allowed for the creation of VaultConnection and VaultAuth resources in a single namespace, and allowed other namespaces to reference these resources using VaultSecret CRDs. This would simplify the management of Vault resources and reduce duplication. Additionally, since the helm chart already allows the creation of default VaultConnection and VaultAuth resources, it would be great to use these resources instead of requiring users to create new ones for each namespace.

[swsharp]

From what I tested I believe this situation may already be mostly avoidable. I was having the same issue but then found that the vaultAuthRef property is optional and if it isn't specified the operators default VaultAuth resource will be used.

See the description here:

vault-secrets-operator/api/v1alpha1/vaultstaticsecret_types.go

Line 18 in 7dd98fb

VaultAuthRef string `json:"vaultAuthRef,omitempty"`

This is also the case for the vaultConnectionRef in the VaultAuth resource. If the VaultAuth resource does not specify a particular VaultConnection resource the operator's default VaultConnection is used.

vault-secrets-operator/api/v1alpha1/vaultauth_types.go

Line 59 in 7dd98fb

VaultConnectionRef string `json:"vaultConnectionRef,omitempty"`

I think the only time you would need additional VaultAuth resources across your k8s namespaces is if you're consuming secrets from multiple Vault namespaces. Because the VaultAuth resource is what references a Vault namespace.

[benashz]

It now possible for a syncable secret resource e.g VaultStaticSecret to reference a VaultAuth in an external K8s namespace, same for VaultAuth w.r.t VaultConnections.

[sumanth-tebra]

@benashz Please provide us some steps to achieve the same

[shehzadqureshi]

Agree with @sumanth-tebra ; @benashz please provide an example because this is not working right now.

Example: have VSO deployed in namespace vault-secrets-operator, with default connection and and default auth (using approle auth). then create a VaultStaticSecret object in any other namespace. This currently fails because it is expecting the secretRef for the approle to be in the same namespace.

[han-steve]

This currently fails because it is expecting the secretRef for the approle to be in the same namespace.

Same here. I also have to set allowedNamespaces: ['*'] on the vaultAuth