More secure installation by default, with more guidance

[chulkilee]

First of all, thank you for the helm chart! I'm testing harbor with helm, and it works great!

Having some default credentials in values.yaml may lead to expose harbor unintentionally, even the doc "suggests" to change them... so here are a few suggestions.

Having security section in the README

There are critical credentials, which exposes data - but the doc doesn't clearly say it must be set.

For example:

registry.credentials.password: The password for accessing the registry instance, which is hosted by htpasswd auth mode. More details see official docs. It is suggested you update this value before installation.

I think it should be MUST, mentioned in own section, not buried in the config table.

Generate all secrets if not given

Here are lists of secrets already being generated automatically

• core.secret
• core.xsrfKey
• jobservice.secret
• registry.secret
• notary.secretName

And there are WIP

• Security hardening: generate password for internal database #766
  • database.internal.password
• Generate more values, protect them for the upgrade #762
  • harborAdminPassword
  • secretKey

And followings are not in work:

• registry.credentials.password (and registry.credentials.htpasswd)

Are there any other secrets? Also it would be nice for the chart maintainer if the two PR uses the similar approach.

Do not use default values for secrets

Until all secrets are automatically generated by the chart... it would be better to fail if any secrets are not given.

Accept reference to Secret

It would be nice all secrets can take the reference (probably name and key) to k8s Secret. I know there are some challenges (e.g. what should happen when the referenced Secrets changes outside helm..) - but this chart is already accepting some Secret references (e.g. CA, TLS, ...)

[bbockelm]

I'd like to second the last item! We keep all our configs in git and have a separate system for secret management -- we can't keep secrets in helm charts. The goal is to treat all our ConfigMap objects as if they were leaked publicly.

It's fairly achievable in the end -- here's an example technique to inject a secret into a config file, combining a ConfigMap and Secret with an initContainer:

https://www.magalix.com/blog/the-configuration-template-pattern

[dajudge]

Is this (at least partially) a duplicate of #189?