Environment / Credential injection for SNMP Generator

[cameronkerrnz]

Host operating system: output of uname -a

Host: Red Hat Enterprise Linux Server release 7.6 (Maipo)
Docker: version 1.13.1
Container images: docker.io/prom/snmp-generator:master 8925d142d366 8 days ago

snmp_exporter version: output of snmp_exporter -version

This relates to the generator; there is no version, and only 'master'. The docker image has image 8925d142d366, and is currently the latest available.

Feature Request

generator.yml produces snmp.yml, and both contains credentials (in plain-text) that are passwords (in SNMPv3 at least they are properly considered passwords or shared keys).

As a deployer of Prometheus I want to use automate the deployment using tools such as Docker (in this particular case, docker-compose).

I need a way to safely inject credentials into the execution of the generator so I don't end up with credentials leaking into Git.

To illustrate, I'm working on the following:

modules:
  fortinet_fortianalyzer_production:
    auth:
      username: snmp_faz
      security_level: authPriv
      auth_protocol: MD5
      priv_protocol: AES
      password: XXX
      priv_password: XXX
    walk:
      - 1.3.6.1.4.1.12356.103.0.1.3  # FORTINET-FORTIMANAGER-FORTIANALYZER-MIB::fmLogRate
      - 1.3.6.1.4.1.12356.103.2.1.1  # FORTINET-FORTIMANAGER-FORTIANALYZER-MIB::fmSysCpuUsage
      - 1.3.6.1.4.1.12356.103.2.1.2  # FORTINET-FORTIMANAGER-FORTIANALYZER-MIB::fmSysMemUsed
      - 1.3.6.1.4.1.12356.103.2.1.3  # FORTINET-FORTIMANAGER-FORTIANALYZER-MIB::fmSysMemCapacity
      - 1.3.6.1.4.1.12356.103.2.1.4  # FORTINET-FORTIMANAGER-FORTIANALYZER-MIB::fmSysDiskUsage
      - 1.3.6.1.4.1.12356.103.2.1.5  # FORTINET-FORTIMANAGER-FORTIANALYZER-MIB::fmSysDiskCapacity
      - 1.3.6.1.4.1.12356.103.7.1.2  # FORTINET-FORTIMANAGER-FORTIANALYZER-MIB::fmRaidState

One useful and generalisable method would be allowing environment variables to be interpolated in the YAML and I can therefore inject the credentials using already established patterns for credential injection.

Risks of implementing

There is a small risk that introducing an interpolation layer could lead to some unexpected behaviour, but the liklihood seems very slim. That could be mitigated by disabling such intepolation by default.

Risks of not implementing

Credentials would likely leak into git history. While SNMP is generally never exposed on the internet, and typically access-controlled within a LAN, this would still not be appropriate, particularly if the access level were to grant R/W access.

You could easily imagine someone writing an interpolation tool for themselves, but this could open issues due to bad coding practices (eg. using the Python YAML 'load' instead of 'safe_load')

Potential Solutions

1. Create an interpolation layer within the generator interpolating environment variables (cf. https://grafana.com/docs/installation/docker/)
2. Create an interpolation layer within the generator interpolating some template language (I almost suggested Jinja, but this is Go, so..... text/template ? (I'm not a Go programmer)
3. Create an interpolation or templating tool that would produce generate.yml. This would be the most flexible solution, allowing for solutions such as CMDB integration, etc. But it does make it harder to get started.

I would suggest that the generator would benefit most by simple environment variable interpolation, and anything more complex should be achieved with an external tool (eg. Ansible deployment).

Workarounds

Currently I'm just having the generator produce snmp-new.yml, which I then manually edit to produce snmp.yml. I just need to ensure that snmp.yml doesn't get captured into git.

Thanks,
Cameron

[cameronkerrnz]

Actually, templating would be useful for the likes of Docker Secrets; rather than just supporting environment variables.

https://grafana.com/docs/installation/docker/#reading-secrets-from-files-support-for-docker-secrets

[brian-brazil]

Environment variables are not a good way to handle secrets. In general this sort of thing is best done by changing snmp.yml before it's deployed, and is not something to handle within the generator/exporter themselves.

[elongstreet88]

Working example of this here:
https://github.com/Dairy-Farmers-of-America/snmp_exporter

I disagree, having creds in plaintext with no way to inject is bad.

[SuperQ]

https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/

[elongstreet88]

https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/

Most of us aren't passing in plain text.
That article is from 2017. Kubernetes secrets to env variable is pretty normal and common and relatively safe:
https://kubernetes.io/docs/concepts/configuration/secret/

Env vars in memory vs plaintext pw in files is always immensely safer.

[SuperQ]

From the Kubernetes Secrets documentation:

As files in a volume mounted on one or more of its containers.

This is the safest and most supported mode of Kubernetes Secrets.

I am going to lock this thread, as it's not productive and this not a policy we are going to change.