Open Stack

On 09/27/2017 06:38 AM, Bhor, Dinesh wrote:
>
> Hi Team,
>
>  
>
> There are four solutions to fix the below bug:
>
> https://bugs.launchpad.net/keystoneauth/+bug/1638978
>
>  
>
> 1) Carry a copy of mask_password() method to keystoneauth from
> oslo_utils [1]:
>
> *Pros:*
>
> A. keystoneauth will use already tested and used version of mask_password.
>
>                
>
> *Cons:*
>
> A. keystoneauth will have to keep the version of mask_password()
> method sync with oslo_utils version.
>
>      If there are any new "_SANITIZE_KEYS" added to oslo_utils
> mask_password then those should be added in keystoneauth mask_password
> also.
>
> B. Copying the "mask_password" will also require to copy its
> supporting code [2] which is huge.
>
>  
>

I'm having flashbacks of the oslo-incubator days...

>  
>
> 2) Use Oslo.utils mask_password() method in keystoneauth:
>
> *Pros:*
>
> A) No synching issue as described in solution #1. keystoneauth will
> directly use mask_password() method from Oslo.utils.
>
>                
>
> *Cons:*
>
> A) You will need oslo.utils library to use keystoneauth.
>
> Objection by community:
>
> - keystoneauth community don't want any dependency on any of OpenStack
> common oslo libraries.
>
> Please refer to the comment from Morgan:
> https://bugs.launchpad.net/keystoneauth/+bug/1700751/comments/3
>
>  
>
>  
>
> 3) Add a custom logging filter in oslo logger
>
> Please refer to POC sample here:
> http://paste.openstack.org/show/617093/
> <http://paste.openstack.org/show/617093/>
>
> OpenStack core services using any OpenStack individual python-*client
> (for e.g python-cinderclient used in nova service) will need to pass
> oslo_logger object during it’s
>
> initialization which will do the work of masking sensitive information.
>
> Note: In nova, oslo.logger object is not passed during cinder client
> initialization
> (https://github.com/openstack/nova/blob/master/nova/volume/cinder.py#L135-L141),
>
>
> In this case, sensitive information will not be masked as it isn’t
> using Oslo.logger.
>
>                
>
> *Pros:*
>
> A) No changes required in oslo.logger or any OpenStack services if
> mask_password method is modified in oslo.utils.
>
>                
>
> *Cons:*
>
> A) Every log message will be scanned for certain password fields
> degrading the performance.
>
> B) If consumer of keystoneauth doesn’t use oslo_logger, then the
> sensitive information will not be masked.
>
> C) Will need to make changes wherever applicable to the OpenStack core
> services to pass oslo.logger object during python-novaclient
> initialization.
>
>  
>
>  
>
> 4) Add mask_password formatter parameter in oslo_log:
>
> Add "mask_password" formatter to sanitize sensitive data and pass it
> as a keyword argument to the log statement.
>
> If the mask_password is set, then only the sensitive information will
> be masked at the time of logging.
>
> The log statement will look like below:
>
>  
>
> logger.debug("'adminPass': 'Now you see me'"), mask_password=True)
>
>  
>
> Please refer to the POC code here:
> http://paste.openstack.org/show/618019/
> <http://paste.openstack.org/show/618019/>
>
>                
>
> *Pros:      *
>
> A) No changes required in oslo.logger or any OpenStack services if
> mask_password method is modified in oslo.utils.
>
>  
>
> *Cons:*
>
> A) If consumer of keystoneauth doesn’t use oslo_logger, then the
> sensitive information will not be masked.
>
> B) If you forget to pass mask_password=True for logging messages where
> sensitive information is present, then those fields won't be masked
> with ***.
>
>      But this can be clearly documented as suggested by Morgan and Lance.
>
> C) This solution requires you to add a below check in keystoneauth to
> avoid from an exception being raised in case logger is pure python
> Logger as it
>
>       doesn’t accept mask_password keyword argument.
>
>  
>
> if isinstance(logger, logging.Logger):
>
>     logger.debug(' '.join(string_parts))
>
> else:
>
>     logger.debug(' '.join(string_parts), mask_password=True)
>
>                                
>
> This check assumes that the logger instance will be oslo_log only if
> it is not of python default logging.Logger.
>
> Keystoneauth community is not ready to have any dependency on any
> oslo-* lib, so it seems this solution has low acceptance chances.
>

Options 2, 3, and 4 all require dependencies on oslo in order to work,
which is a non-starter according to Morgan's comment in the bug [0].
Options 3 and 4 will require a refactor to get keystoneauth to use
oslo.log (today it uses the logging module from Python's standard library).

[0] https://bugs.launchpad.net/keystoneauth/+bug/1700751/comments/3

>  
>
> Please let me know your opinions about the above four approaches.
> Which one should we adopt?
>
>  
>
> [1]
> https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L248-L313
>
> [2]
> https://github.com/openstack/oslo.utils/blob/6e04f882c4308ff64fa199d1b127ad225e0a30c4/oslo_utils/strutils.py#L56-L96
>
>  
>
> Thanks and Regards,
>
> *Dinesh Bhor*| App. Software Dev. Cnslt.**
>
> _dinesh.bhor at nttdata.com <mailto:dinesh.bhor at nttdata.com>_*| VOIP.
> 8833.8395I *| nttdata.com/americas <http://nttdata.com/americas>
>
> *NTT DATA, Inc.*
>
> Consulting | Digital | Managed Services | Industry Solutions
>
> Learn more:
>
> Description: Description: cid:image005.jpg at 01D193F0.F70B44C0
> <http://americas.nttdata.com/>
>
> 	
>
> Description: Description: cid:image009.jpg at 01D193F0.F70B44C0
> <http://www.linkedin.com/company/ntt-data-americas>
>
> 	
>
> Description: Description: cid:image010.jpg at 01D193F0.F70B44C0
> <https://twitter.com/NTTDATAAmericas>
>
> 	
>
> Description: Description: cid:image011.jpg at 01D193F0.F70B44C0
> <https://www.facebook.com/NTTDATAAmericas>
>
>  
>
>
> ______________________________________________________________________
> Disclaimer: This email and any attachments are sent in strictest
> confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then
> delete
> and destroy this email and any attachments without any further use,
> copying
> or forwarding.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/efe881b5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 940 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/efe881b5/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 840 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/efe881b5/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 828 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/efe881b5/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 779 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/efe881b5/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170929/efe881b5/attachment.sig>