-
Notifications
You must be signed in to change notification settings - Fork 25
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
Support pre-existing kubernetes secrets #61
Comments
We use the external secrets operator to manage our kubernetes secrets. The reference of existing secrets would help us. |
Workaround for pre-existing secrets: nameOverride: nexus-ha
secret:
license:
name: license.lic
licenseSecret:
mountPath: /etc/nexus-license/
statefulset:
additionalVolumes:
- name: nexus-pro-license
secret:
secretName: nexus-pro-license
additionalVolumeMounts:
- name: nexus-pro-license
mountPath: /etc/nexus-license/
readOnly: true Create the secrets |
We have some work in progress to support external-secret operator: #66 |
This is of great interest to me as well. Also it would be really useful to just specify a preexisting secret name for DB creds, as we have an operator that spins up the DB and creates a secret with all the necessary creds. |
I agree to support preexisting secret names is a real need we use bitnami sealed secrets and install a secret store is not an urgent need so this is a complete blockage from chart adoption. As it is the options available are between:
|
If you keep you values files in git for ArgoCD to consume, you cannot have any secret in the values files. |
I've opened this PR to fix these problems: #99 |
Currently, two option exist for referencing the License-File and DB-/Admin-credentials:
It would be helpful to introduce a third option where a pre-existing Kubernetes secret can be referenced. This would be beneficial when other Azure Key-Vault synchronization mechanisms are in use, like akv2k8s (https://akv2k8s.io/).
The text was updated successfully, but these errors were encountered: