make it easier to set up secrets

[wkloucek]

creating secrets for the oCIS chart is a manual process currently. We should aim at making this easier.

[wkloucek]

We have secrets that are just timeless, random strings. Those could be generated like this: https://itnext.io/manage-auto-generated-secrets-in-your-helm-charts-5aee48ba6918
It still has a few downsides:

• the "read and than apply" approach with helm can lead to race conditions
• https://stackoverflow.com/questions/56170052/how-not-to-overwrite-randomly-generated-secrets-in-helm-templates. It suggests a slightly different approach to also support dry-run for an install:

  # store the secret-name as var
  # in my case, the name was very long and containing a lot of fields
  # so it helps me a lot
  {{- $secret_name := "your-secret-name" -}}
  
  apiVersion: v1
  kind: Secret
  metadata:
    name: {{ $secret_name }}
  
  data:
    # try to get the old secret
    # keep in mind, that a dry-run only returns an empty map 
    {{- $old_sec := lookup "v1" "Secret" .Release.Namespace $secret_name }}
  
    # check, if a secret is already set
    {{- if or (not $old_sec) (not $old_sec.data) }}
    # if not set, then generate a new password
    db-password: {{ randAlphaNum 20 | b64enc }}
    {{ else }}
    # if set, then use the old value
    db-password: {{ index $old_sec.data "db-password" }}
    {{ end }}
  

  But a dry-run for upgrades is still not supported.

Other secrets may regularly be rotated like the ldap ca / cert secrets.

[wkloucek]

General problem is discussed at helm/helm-www#1259, while bitnami/charts#3094 show's Binamis way to deal with it.

[remram44]

Generating them from Helm, reading the old value via lookup, is limited. It will only work for what you can generate from Helm, e.g. random strings, not keys. In addition it won't work when using helm template because lookup will return null.

Another option is to create a Job that talks to the Kubernetes API via a service account to check the secret and possibly generate them. This will work with helm template and allows you to run any code you want (in the Job's container). You can also make it a post-install,post-upgrade chart hook to have it run first and re-run on updates.

[remram44]

Either way I think blaming Helm in your docs is inappropriate and should be removed. You are using Helm incorrectly and blaming them, and it's a bad look.

https://doc.owncloud.com/ocis/next/deployment/container/orchestration/orchestration.html

Helm does not support one-off generation of secrets out of the box. Certificates are also required which should expire and therefore need a certificate rotation from time to time, which is also not supported by Helm

Helm does not support one-off generation of configuration out of the box

Certificates are also required which should have an expiration date and therefore need a certificate rotation from time to time, which is also not supported by Helm

Certificates are also required which should expire and therefore need a certificate rotation from time to time, which is also not supported by Helm

All of this is supported by Helm. You just haven't written the Jobs and CronJobs that are the way to do it and works for everyone else.

[wkloucek]

Right, the wording is highly unfortunate. Especially since Helm will never do any certificate rotation and it's not the scope of Helm. For these kind of tasks we e.g. cert-manager.

Regarding secret generation / what you have been proposing in #141:

However this is false and not a limitation anyone else is running into. Chart hooks provide this functionality, you can use a post-install hook to create a job that generates the secrets. This is easy since you already have figured out the commands to generate every secret value (currently in # how to generate: comments in your example YAML files).

Do you have an example chart at that that does this secret generation with a job that is executed by the post-install hook?

[remram44]

If you don't actually rotate certificates, it looks like Helm might have all you need built-in , e.g. with genCA/genSelfSignedCert/genSignedCert

Here are a few examples I could find of using a Job, I hope that helps:

• GitLab's shared secrets: job template, script template (it's a shell script that calls kubectl and openssl), rbac
• GitLab's nginx secrets: job template, role, rolebinding
• Bitnami's Contour chart: job template, rbac (Bitnami seems to be using mostly lookup and initContainers)

[wkloucek]

Discussion with @ainmosni @Excds @d7oc :

• use the lookup "v1" "Secret" approach instead of the preinstall / Job approach
• set configRefs and secretRefs to "" (emtpy string) by default (also as a preparation for Use unique names -- include release name #140)
• the configRefs and secretRefs will internally default to the old values. Therefore we keep backwards compatibility. But we'll annex the previously user owned secrets and make them helm owned (annotation wise).
• generating only secrets that are being used, eg. the secret idpSecretRef should only be generate if no external usermanagment is used
• fail if only manual secrets are not provided (eg. notificationsSmtpSecretRef)
• Update documentation (https://doc.owncloud.com/ocis/next/deployment/container/orchestration/orchestration.html#customize-the-generic-setup)