@jstewart612 thank you for raising this issue. Could you please point to an example/documentation/tutorial for the solution you are describing?

Note: We have also very briefly looked at helm-secrets+sops but it is adding a new dependency to the chart.

@banzo most of your problem is your approach to blocks like these:

https://github.com/cetic/helm-nifi/blob/master/templates/statefulset.yaml#L116-L369

You tell the Helm chart, inline in a StatefulSet, to render a giant template string invoked by bash -ce. As a result, when you render the Helm chart, the password renders in plaintext in the object definition in Kubernetes / as a result of helm template commands, etc. You could go with numerous approaches to address this. My suggestion would be to never render a sensitive piece of data outside of a Secret. I'd move the entirety of these script generation blocks into a Secret, then simply tell your StatefulSet to load the script or file located at x, and have a volume and volumeMount from that SecretRef.

https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod

Once you can do that, it's a fairly easy hop, skip, and a jump, to wrap the rendering of the secret behind the truthiness of another key.

if existingSecret key defined -> do not render this secret

Granted, you're doing a lot of interpretation for people, so if they chose to use this existingSecret model, they'd lose a lot of the convenience functions... but that's a choice I'd argue the user should have.

At a minimum, exfiltrating these giant blocks of text with passwords in them out of the StatefulSet and into Secrets, and then just having all these commands simply reference a file loaded from a secretRef, with an option to specify an existingSecret and then not render that Secret at all, would be a huge win. Then, you don't have to be opinionated on which secrets protection mechanism the end user employs. They can make those decisions for themselves.

Let me know if you have any other questions. I may personally try my hand at a PR demonstrating what I mean, as well.

@jstewart612 thank you for the explanation.

I may personally try my hand at a PR demonstrating what I mean, as well.

That would be most excellent.

@banzo I've created a pull request to set an example of how this could be done.
Helm either creates a secret using the helm value or allows for an existingSecret.
I chose the easier option of not rewriting the whole container 'command:' section, but just having that script read the secret as a file using $(cat ).

Ideally the file would be created using the Secret Store CSI driver directly and no k8s Secret is created at all, but not all users would want to use that method, and it would be messy to have that option.

Using this method, I'd have one secret/mount per optional block. For blocks with multiple secrets, use one Secret and many keys. Each get using the simple mount method (ie no subPath), it automatically creates a file per key within the folder.
Thus singleUser secret has key1: username, key2: password.

apiVersion: v1
kind: Secret
metadata:
  name: {{ template "apache-nifi.fullname" . }}-singleuser
...
data:
  username: {{ .Values.auth.singleUser.username | b64enc }}
  password: {{ .Values.auth.singleUser.passowrd | b64enc }}

kind: Statefulset
...
    volumeMount:
     - name: singleuser-secret
        mountPath: /mnt/secrets/singleUser
       readOnly: true
  volume:
        - name: singleuser-secret
          secret:
            {{- if not .Values.auth.singleUser.existingSecret }}
            secretName: {{ template "apache-nifi.fullname" . }}-singleuser
            {{- else }}
            secretName: {{ .Values.auth.singleUser.existingSecret  }}
            {{- end }}

creates:

/mnt/secrets/singleUser/username
/mnt/secrets/singleUser/password

which can then be individually used:
prop_replace ... $(cat /mnt/secrets/singleUser/username)
Putting them in their own /mnt/secrets/ folder allows for multiple sets of secrets.

@jstewart612 is #303 in line with what you proposed?