Description of problem: Customer noticed that Heat, when in DEBUG, creates a log entry containing private key when creating a keypair. 2018-05-08 09:49:13.198 742250 DEBUG novaclient.v2.client [req-12f8d12d-c94f-4d05-afd1-95dd16824dfd - crf - - -] RESP: [200] Content-Length: 2324 Content-Type: applica tion/json Openstack-Api-Version: compute 2.1 X-Openstack-Nova-Api-Version: 2.1 Vary: OpenStack-API-Version, X-OpenStack-Nova-API-Version X-Compute-Request-Id: req-947a b50d-b915-4396-803e-55bf66a5f1e0 Date: Tue, 08 May 2018 06:49:13 GMT RESP BODY: {"keypair": {"public_key": "ssh-rsa ... Generated-by-Nova", "private_key": "-----BEGIN RSA PRIVATE KEY-----\n ... In my opinion, this is fine, since it happens during DEBUG only. I mean that is the DEBUG's purpose, right? Customer brought this up because of the recent events with twitter leaking plain text passwords in the logs [1] and asked us at least consider whether we should do something about this or not. Thank you. Regards. [1] https://www.bleepingcomputer.com/news/security/twitter-admits-recording-plaintext-passwords-in-internal-logs-just-like-github/
Getting Nova to generate a keypair is a fairly insecure way of doing things no matter how you look at it (since the private key gets stored unencrypted in Heat's DB, and is accessible through the API). The only secure method is to create the keypair locally and upload only the public key to Nova. That said, it is definitely not OK to log the private key in my opinion, logging private keys is most definitely not the purpose of DEBUG-level logging, and practically all operators run heat with debug logging enabled.
Changing component to python-novaclient, since that's where it needs to be sanitised. It's likely that e.g. Horizon and Mistral could also be affected in the same way that Heat is.
Following this, the offending log is actually in keystoneclient's Session._http_log_response().
I think this needs to be fixed in oslo.utils' mask_password. Specifically we should additionally mask "private_key": "...".
The fix has now merged upstream.
Submitted a backport for upstream Ocata: https://review.openstack.org/568557
I requested Release oslo.utils 3.22.3 of Ocata: https://review.openstack.org/#/c/572379/
python-oslo-utils-3.22.1-2.el7ost is now ready for tests.
OSP11 is now EOL. This fix is in progress for OSP12 and newer.