-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using remote namespace with VaultAuthRef doesn't work with approle secretid unless copied to local namespace #560
Comments
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
|
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 |
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.
Results in the following error:
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
The text was updated successfully, but these errors were encountered: