Bug 979092

Summary: openstack-keystone: please review support data collection
Product: Red Hat OpenStack Reporter: Bryn M. Reeves <bmr>
Component: sos-plugins-openstackAssignee: Jeremy Agee <jagee>
Status: CLOSED ERRATA QA Contact: Jeremy Agee <jagee>
Severity: medium Docs Contact:
Priority: urgent    
Version: unspecifiedCC: apevec, ayoung, bmr, jagee, jkt, kbanerje, lhh, mlopes, pbrady
Target Milestone: rc   
Target Release: 4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: sos-plugins-openstack-2013.2-1.el6ost Doc Type: Enhancement
Doc Text:
OpenStack plugins are now available for the sosreport tool. The additional plugins are available in the 'sos-plugins-openstack' package, and gather support data from OpenStack deployments.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-12-20 00:12:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 840057    

Description Bryn M. Reeves 2013-06-27 15:01:14 UTC
Description of problem:
As part of support readiness preparations for OpenStack please review the data proposed to be collected for support purposes by the sos tool:

        "/etc/keystone/"
        "/var/log/keystone/"

Please verify that this set of information is complete and sufficient for support of this component and confirm either that no secrets (passwords, private keys, etc.) are collected or list any secrets that may be included.

This information is needed to create path exclusion and search/replace rules to remove this data from generated reports.

We are aware of the following possibly confidential items in this component's collected data:

        /etc/keystone/ketstone.conf:
        #ca_password = None
        # password = None

        #keyfile = /etc/keystone/ssl/private/keystonekey.pem
        #keyfile = /etc/keystone/ssl/private/signing_key.pem

Please provide feedback on these items via this bug - once the review has taken place the bug may be closed.

Comment 3 Adam Young 2013-07-26 01:26:06 UTC
In addition to the values above, the SQL Connection and the LDAP connection both can potentially have passwords in them.

The two keyfile values are merely paths, and should be left in the data.

The admin_token value is like a password and should be removed.  If the value is present, however, it indicates a misconfigured system, so a marker that it was set should be included.

Comment 4 Perry Myers 2013-08-13 22:36:57 UTC
Bryn, any additional data needed for this one?

Comment 5 Adam Young 2013-09-03 20:33:22 UTC
Jeremy is working on the SOS report for this.

Comment 6 Jeremy Agee 2013-09-05 15:55:35 UTC
new pull request submitted and can be tracked at BZ999657.

We are currently only collecting default_catalog.templates,keystone.conf,logging.conf, and policy.json from /etc/keystone so we dont copy private ssl keys.

in keystone.conf we are replacing the passowd string with ***** in the settings ca_password,password,admin_token, and the password portion of the sql connection string.

Comment 10 Jeremy Agee 2013-11-18 15:47:01 UTC
This was accepted upstream and is in the main github branch.

https://github.com/sosreport/sosreport/blob/master/sos/plugins/openstack_keystone.py

For RHEL6 this had to be backported to sos 2.2 and is not in the main sos package.  It can be found in the package sos-plugins-openstack.

For testing the sos and sos-plugins-openstack packages should be installed and run on a system with keystone installed.  The sos tarball should contain the 4 keystone config files from the setup self.add_copy_specs call and should also capture the logs from /var/log/keystone.  The /etc/keystone/keystone.conf file should also have passwords scrubbed in the postproc step.

Comment 11 Jeremy Agee 2013-11-19 14:40:48 UTC
tested and works as expected, see test plan.

Comment 14 errata-xmlrpc 2013-12-20 00:12:12 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1859.html