GET User logs personal infomation

[prashkre]

With respect to GDPR compliance, we should not log personal information of a person without their consent but in debug mode, keystoneclient.v3.client.users.get(user_id) logs personal information like email_id as show below. We need to let the user pass log=False to halt logging of such response body in the logs at https://github.com/openstack/keystoneauth/blob/stable/queens/keystoneauth1/session.py#L792.

2018-04-19 05:51:10.841 82215 DEBUG keystoneauth.session [req-4ac75305-aa12-4c99-8776-cee93455578e 81eadbb18f2ce0fa47108d2fcaa2d72fa62b65a8a8628e9a85c3ce99b9a02d6d f67c1b8dd2c947d0b1a309e1ad36e76f - default default] REQ: curl -g -i -X GET https://xxxxxxxx:5000/v3/users/81eadbb18f2ce0fa47108d2fcaa2d72fa62b65a8a8628e9a85c3ce99b9a02d6d -H "User-Agent: python-keystoneclient" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}3c271d109933c75bad57e8f8dab7af72c496b174" _http_log_request /usr/lib/python2.7/site-packages/keystoneauth1/session.py:372
2018-04-19 05:51:10.873 82215 DEBUG keystoneauth.session [req-4ac75305-aa12-4c99-8776-cee93455578e 81eadbb18f2ce0fa47108d2fcaa2d72fa62b65a8a8628e9a85c3ce99b9a02d6d f67c1b8dd2c947d0b1a309e1ad36e76f - default default] RESP: [200] Date: Thu, 19 Apr 2018 09:51:10 GMT Server: Apache Vary: X-Auth-Token,Accept-Encoding,User-Agent x-openstack-request-id: req-5a99cac3-82c7-4d2b-a072-19ced80c62e5 Content-Encoding: gzip Content-Length: 239 Keep-Alive: timeout=5, max=99 Connection: Keep-Alive Content-Type: application/json
RESP BODY: {"user": {"password_expires_at": null, "links": {"self": "https://xxxxxxx:5000/v3/users/81eadbb18f2ce0fa47108d2fcaa2d72fa62b65a8a8628e9a85c3ce99b9a02d6d"}, "domain_id": "default", "email": "<email address hidden>", "options": {}, "id": "81eadbb18f2ce0fa47108d2fcaa2d72fa62b65a8a8628e9a85c3ce99b9a02d6d", "name": "fake_name"}}

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/568373

[Anurag Mahanto (anurag.mahanto)]

Please provide steps, to reproduce this bug.

[Morgan Fainberg (mdrnstm)]

I commented on the patchset. Debug is meant to be used for debugging purposes. Offering this is likely to break fundamentally the use of debugging.

The response is useful.

I am marking this as opinion/won't fix.

The solution is to not use debugging where logging for the data debug out puts is not meant to be used.

[Kripa Shankar Sharma (skripa)]

@Morgan, I want to share my opinion, we need this to provide an option to users to put off the logging the response even though it logs in debug mode.
Even in debug mode, some customers doesn't want the users information to be logged in log files.

[Morgan Fainberg (mdrnstm)]

The issue here is *how* the logging is done. Unless every single service allows for toggling this bit where they consume KeystoneClient (and by proxy anything and everything logged in KeystoneAuth, which may also contain the responses in debug mode), you can't guarantee the data is or is not going to be logged.

For example, if Nova were to consume keystoneclient's get user function, it is likely it wont set this flag to false (with good reason), causing the details to be logged. It would then be required to add an option/flag/something to Nova to set this flag. It rapidly gets out of hand. The answer here really is:

Debug logging may log data that is sensitive, this data is useful for debugging. In this case short of NEVER debugging the response data, we can't guarantee it is impactful due to the way keystoneclient is consumed in outside resources. It would surprise many people if the response to user was not logged at this point.

I understand the GDPR concerns, however, my honest recommendation is to not use Keystoneclient, but to use KeystoneAuth directly and make rest calls. Keystoneclient is narrowly designed and very opinionated (at this point). SDK and direct rest is where changes like this should live long term (as that is the way forward for consumers). Keystoneclient is really only designed for server-to-server style communication (and, for the time being, openstackclient).

If you would like to propose a patch that forces keystoneclient to lean on keystoneauth and adjust how logging works (for allowing different/split logging for request/response/) that can easily configured, I'll take it.

As it stands, this change/bug here is not in the direction for keystoneclient.