Closed plafosse-orange closed 4 years ago
There are two things. First, about the security. It is an example, you can pass the value from a secret using valueFrom: secretKeyRef: instead of value: The object type is k8s.io/api/core/v1/EnvVar and you can easy secure it as all env values used
Secondly, if you want to use a value using an env variable, and you want this value to be valued, the right form is $(env) instead of ${env}
You have the solution that works. It would be appropriate for the example to integrate this solution.
metric:
image: prom/mysqld-exporter:v0.12.1
env:
- name: EXPORTER_PWD
valueFrom:
secretKeyRef:
name: galera-secret
key: exporter-password
- name: DATA_SOURCE_NAME
# value: exporter:export@(localhost:3306)/
value: exporter:$(EXPORTER_PWD)@(localhost:3306)/
it's not much but it can help
In the example file
40-GALERA.yaml
, it is proposed to reconstitute the variableDATA_SOURCE_NAME
by passing the password of the userEXPORTER
via an environment variable.With this method, the password is not valued when the mysqld-exporter program uses the variable
DATA_SOURCE_NAME
. It would be a shame to be forced to supply the variableDATA_SOURCE_NAME
with the password in clear when it is encrypted in the "secret" file.