Skip to content
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

Open
renesch-de opened this issue Feb 12, 2024 · 7 comments
Open

Support pre-existing kubernetes secrets #61

renesch-de opened this issue Feb 12, 2024 · 7 comments

Comments

@renesch-de
Copy link
Contributor

Currently, two option exist for referencing the License-File and DB-/Admin-credentials:

  1. Via the secrets-store.csi.x-k8s.io/v1 API.
  2. As a Kubernetes secret, directly created by the Helm-Chart.

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/).

@snakebyte91
Copy link

We use the external secrets operator to manage our kubernetes secrets. The reference of existing secrets would help us.

@snakebyte91
Copy link

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 nexus-ha-adminsecret and nexus-ha-dbsecret. This could be done by a tool of your choice or manually. The prefix nexus-ha is taken from nameOverride.

@bobotimi
Copy link
Contributor

We have some work in progress to support external-secret operator: #66

@mpsOxygen
Copy link

mpsOxygen commented Aug 19, 2024

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.

@sinaure
Copy link

sinaure commented Sep 9, 2024

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:

  • use a secret store (Via the secrets-store.csi.x-k8s.io/v1 API.)
  • have zero protection exposing secrets in values : complete non sense in my opinion (As a Kubernetes secret, directly created by the Helm-Chart.)

@mpsOxygen
Copy link

If you keep you values files in git for ArgoCD to consume, you cannot have any secret in the values files.

@mpsOxygen
Copy link

I've opened this PR to fix these problems: #99

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants