salt-cloud prints minions private key to output

[DagW]

Description of Issue

We are running salt-cloud commands from an Orchestration via Jenkins, and saw the minions private key being printed out to the logs.
I'd rather not see this in the output!

Example output from the cloud.create command:

    "__id__": "salt-cloud-create",
    "__run_num__": 1,
    "__sls__": "orch.aws.provision-host",
    "changes": {
        "ret": {
            "instance-hostname.com-create-runner": {
                "instance-hostname.com": {
                    "deploy_kwargs": {
                        "name": "instance-hostname.com",
                        "vm_": {
                            ........
                            "priv_key": "-----BEGIN RSA PRIVATE KEY-----\n entire private key contents here",
                            .........
                        }
                    }
                }
            }
        }
    }

Setup

(Please provide relevant configs and/or SLS files (Be sure to remove sensitive info).)
Example SLS file

salt-cloud-create:
  salt.parallel_runners:
  - runners:
      instance-cloud-create-runner-1:
      - name: cloud.create
      - kwarg:
          instances:
          - instance.cloud
          provider: ec2-provider
          availability_zone: eu-central-1b
          image: ami-04cf43aca3e6f3de3
          size: t3.small
          rename_on_destroy: true
          ssh_username: centos

Steps to Reproduce Issue

(Include debug logs if possible and relevant.)
Run the following example sls file.

Versions Report

(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)

> salt-cloud -V
Salt Version:
            Salt: 2019.2.0

Dependency Versions:
 Apache Libcloud: 2.2.1
            cffi: 1.6.0
        cherrypy: 5.6.0
        dateutil: 2.6.1
       docker-py: Not Installed
           gitdb: 0.6.4
       gitpython: 1.0.1
           ioflo: Not Installed
          Jinja2: 2.7.2
         libgit2: 0.26.3
         libnacl: Not Installed
        M2Crypto: 0.31.0
            Mako: Not Installed
    msgpack-pure: Not Installed
  msgpack-python: 0.5.6
    mysql-python: Not Installed
       pycparser: 2.14
        pycrypto: 2.6.1
    pycryptodome: Not Installed
          pygit2: 0.26.4
          Python: 2.7.5 (default, Jun 20 2019, 20:27:34)
    python-gnupg: Not Installed
          PyYAML: 3.11
           PyZMQ: 15.3.0
            RAET: Not Installed
           smmap: 0.9.0
         timelib: Not Installed
         Tornado: 4.2.1
             ZMQ: 4.1.4

System Versions:
            dist: centos 7.6.1810 Core
          locale: ANSI_X3.4-1968
         machine: x86_64
         release: 3.10.0-957.21.3.el7.x86_64
          system: Linux
         version: CentOS Linux 7.6.1810 Core

[dhiltonp]

A solution might be to change your log levels!

I suspect this is an DEBUG or INFO log level message that is logging the results of all commands. Can you confirm this? Including the exact log message (deleting the private key/ip address) would be helpful for confirming what is going on.

[DagW]

Hello! The problem is that it is being printed in the result, and that is stored in our jenkins build logs. It's not being printed to logs.

We are triggering an orchestration via salt-api, and in the json formatted result we can see the private key.

[dhiltonp]

What do you think about filtering the output via a pipe prior to saving your data?

Something like: salt-cloud... | grep -v '\"priv_key\":' >> log

[DagW]

That would work if we were running the salt-cloud commands by cli,

But we are calling the salt-api from Jenkins to start an orchestration, and in the result JSON the key is present.

I guess we could filter the output from salt-api in the Jenkins pipeline, before printing the result.
Maybe there is some log level flag to the salt-api that I could use?

However I'm not sure the private key is meant to be printed out in the output.

[waynew]

This looks like it's probably a bug. I discussed with @dwoz and we both feel that private keys should simply never be displayed (if known).

However, this is probably an isolated place - we should probably be doing something like filtering in our outputters for a variety of potential keys in dictionaries so they don't actually end out getting accidentally shown.

The correct workaround for now is to filter the output, perhaps with grep as David mentioned