Closed jack1902 closed 2 years ago
Hello
I belive you can achieve your goal with existing chart functionality
extraEnv
in values.yaml to expose secret data as environmental variables.extraArgs
to setup basic auth config using exposed env vars.Could you confirm this ?
Also, passing secret data via values file is insecure too, since the values of installed helm chart can be inspected via helm get values
Was hoping to be able to create everything needed using the chart rather than having to create a larger chart which creates the secret and has this chart as a dependency (I'm creating the namespace which this belongs in via helm upgrade -i --create-namespace
, but I can see why you might not want to include the basic-auth piece if it is already possible.
helm get values
reads secrets which means you have more than read
permissions on the cluster which is the main thing I am safeguarding against as users might have a reader
role but nothing else, so they can see things in the cluster without being able to read secrets (which helm get values
relies upon).
Dear @jack1902
I've asked smth different, repeating my question once again
Hello
I belive you can achieve your goal with existing chart functionality
- create a secret with basic auth credentials.
- use
extraEnv
in values.yaml to expose secret data as environmental variables.- use
extraArgs
to setup basic auth config using exposed env vars.Could you confirm this ?
Dear @eshepelyuk
Yes, that does appear possible, which I alluded to at the end of my first response around why you might not wish to include basic-auth
within the chart because CMAK itself has many configuration options and this pins the chart to one such auth mechanism which others might wish to extend upon in the future.
Would it be better suited to potentially extend the secret
manifest in the chart so that it would be easier to make use of extra*
settings without needing to pre-create a secret or wrap this chart up into a larger chart? I'm merely trying to make this chart more usable without needing to wrap it up into a larger chart or fork it.
Again
I've asked you to confirm this, i.e. go and test and ensure it works.
Can you please do it since you raised this issue ??
If you confirm that it is possible to achieve this in a proposed way - we can continue on designing the simplification.
So having tried to use env
vars, it appears I would need to set the entrypoint
(Dockerfile) or command (k8s-manifest) via the values since the current one is /cmak/bin/cmak
, no shell env var substitution takes place meaning the following:
cmak-operator:
ui:
# enable basic auth on the UI
extraArgs:
- -DbasicAuthentication.enabled=true
- -DbasicAuthentication.username=admin
- -DbasicAuthentication.password=${CMAK_PASSWORD}
extraEnv:
- name: CMAK_PASSWORD
valueFrom:
secretKeyRef:
name: cmak-password
key: password
sets the password as ${CMAK_PASSWORD}
rather than the value defined within the secret.
Unfortunately, this means that even though extraEnv and extraArgs exist, it appears combining the two currently isn't possible.
I believe this is the Dockerfile used to power the UI container https://github.com/eshepelyuk/cmak-docker/blob/master/cmak/Dockerfile
Hello
But, look https://github.com/yahoo/CMAK/blob/master/conf/application.conf#L68 CMAK by default read basic auth from env vars. You should just use proper names.
Using KAFKA_MANAGER_PASSWORD
works when used within the extraEnv
Currently, in order to enable authentication on
cmak
with this chart, you can do the following:This results in the password being stored on the manifest within the cluster, which enables anyone with
read
access to get the manifest AND the password for cmak. It would be ideal if something similar to the below could be allowed such that the chart was extended in capabilities like so:I'll open a PR to show this as I really want to avoid exposing a secret via a manifest