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

[harbor] Allow providing all secrets out-of-band #25399

Closed
meln5674 opened this issue Apr 26, 2024 · 3 comments · May be fixed by #25453
Closed

[harbor] Allow providing all secrets out-of-band #25399

meln5674 opened this issue Apr 26, 2024 · 3 comments · May be fixed by #25453
Assignees
Labels
feature-request harbor solved stale 15 days without activity triage Triage is needed

Comments

@meln5674
Copy link
Contributor

Name and Version

bitnami/harbor 21.1.1

What is the problem this feature will solve?

Presently, some Secrets in the harbor chart are "baked into", that is, they require providing sensitive values in the values.yaml, which is not secure when using GitOps.

What is the feature you are proposing to solve the problem?

The following changes should allow for zero secrets to be created by the chart, if desired:

  1. Add a trivy.existingEnvVarsSecret field that will point to a secret currently created by trivy/trivy-secret-envvars.yaml, do not create the secret if it is provided
  2. Move the redis URL from jobservice/jobservice-config-secret.yaml at config.yaml's worker_pool.redis_url to jobservice/jobservice-secret-envvars.yaml at a separate key JOB_SERVICE_POOL_REDIS_URL which the jobservice respects (see https://github.com/goharbor/harbor/blob/main/src/jobservice/config/config.go#L40C42-L40C68)
  3. Change jobservice/jobservice-config-secret.yaml from a Secret to a ConfigMap, now that the only sensitive value has been removed
  4. Add a jobservice.existingEnvVarsSecret field that will point to a secret currently created by jobservice/jobservice-secret-envvars.yaml, do not create if provided
  5. Do not create core/core-secret.yaml if the data section would be empty (i.e. if both core.existingSecret and core.secretName are both provided).

With these changes made, all Secrets are within an if-block, meaning it is possible to configure the chart to emit no Secrets.

I have these changes working in a local copy. I am happy to update the docs and submit a PR if these would be accepted as-is or with minor modifications.

What alternatives have you considered?

Using a different chart.

@carrodher
Copy link
Member

Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

Copy link

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

@github-actions github-actions bot added the stale 15 days without activity label May 12, 2024
Copy link

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

@bitnami-bot bitnami-bot closed this as not planned Won't fix, can't repro, duplicate, stale May 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request harbor solved stale 15 days without activity triage Triage is needed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants