Secrets separation and RBAC support

[Mrkazik99]

For now all secrets are being spreaded all over namespace and in final cluster as well. We should avoid having secrets accessible by other pods than we want. That means we need to prepare RBACs and most likely service accounts for each component, and also adjust secrets gathering from values file.

[dsonck92]

As I guess this is the major overhaul for secrets, I propose the following structure:

concept:
  existingSecret: xyz
  userKey: CONCEPT_USER
  passwordKey: CONCEPT_PASSWORD

• concept is something like s3, db, search, redis.
• existingSecret is undefined by default, which causes the helm managed Secret to be generated and substituted instead
• userKey and passwordKey default to whatever the generated secret creates, and maps these to the right environment variable by using the env.valueFrom.secretKeyRef.

The idea of using secretKeyRef is to give the user maximum amount of freedom supplying their own secrets. We cannot assume they can supply their secrets in our format, maybe it's some kind of dynamically generated secret.

[dsonck92]

Also, I think secret separation and rbac are two separate features, so I would split these up. Having separated secrets is a very nice to have, and I don't want that to block on RBAC. Once the secret separation is done, for me, I can migrate over to the new helm chart