Since this is targeted for RHOS 4.0 (havana), where "quantum" has been renamed to "neutron", we need to use /etc/neutron/ and /var/log/neutron/ instead of /etc/quantum/ and /var/log/quantum/. 

The contents certain files in /etc/sysconfig/network-scripts/ are also often useful. Should these be included?

There are passwords in neutron config files, and there may be other secrets in log files that should be excluded. I have not tried to identify these, and some details may not be available until at least the upstream H-3 release since new functionality is still be implemented.

Debugging neutron issues often requires additional information such as output from:

* ovs-vsctl show and various ovs-ofctl commands if using OVS
* brctl show
* various ip commands
* various iptables commands

Should any of the above be addressed here?

> Since this is targeted for RHOS 4.0 (havana), where "quantum" has been renamed
> to "neutron", we need to use /etc/neutron/ and /var/log/neutron/ instead of 
> /etc/quantum/ and /var/log/quantum/. 

Are there any shipping/supported versions using the old names? We will need to support both if that is the case since we cannot depend on users having everything up to date.

> The contents certain files in /etc/sysconfig/network-scripts/ are also often 
> useful. Should these be included?

Not in anything openstack related: these are handled by the existing networking plug-in.

> * brctl show
> * various ip commands
> * various iptables commands

Ditto: this kind of generic system data does not belong in any product or application specific plug-in (again: these are already collected by the generic networking support).

We can make exceptions where things have very specialised needs but this is something we try hard to avoid and it doesn't appear justified here.

> ovs-vsctl show and various ovs-ofctl commands if using OVS

What is OVS? If it's optional it sounds like it should have its own plug-in.

> There are passwords in neutron config files, and there may be other secrets 
> in log files that should be excluded. I have not tried to identify these, and 
> some details may not be available until at least the upstream H-3 release 
> since new functionality is still be implemented.

I can't put this into RHEL until we have that information; if we release stuff that gathers secrets we are asking for CVEs against the sos package.

When do you expect the H-3 release to be finalised?

(In reply to Bryn M. Reeves from comment #4)
> > Since this is targeted for RHOS 4.0 (havana), where "quantum" has been renamed
> > to "neutron", we need to use /etc/neutron/ and /var/log/neutron/ instead of 
> > /etc/quantum/ and /var/log/quantum/. 
> 
> Are there any shipping/supported versions using the old names? We will need
> to support both if that is the case since we cannot depend on users having
> everything up to date.
> 
> > The contents certain files in /etc/sysconfig/network-scripts/ are also often 
> > useful. Should these be included?
> 
> Not in anything openstack related: these are handled by the existing
> networking plug-in.

That helps!

> 
> > * brctl show
> > * various ip commands
> > * various iptables commands
> 
> Ditto: this kind of generic system data does not belong in any product or
> application specific plug-in (again: these are already collected by the
> generic networking support).
> 
> We can make exceptions where things have very specialised needs but this is
> something we try hard to avoid and it doesn't appear justified here.

Agreed.

> 
> > ovs-vsctl show and various ovs-ofctl commands if using OVS
> 
> What is OVS? If it's optional it sounds like it should have its own plug-in.

OVS is Open vSwitch, the openvswitch package. Its an advanced software network switch. It seems it should have its own sos plug-in.

> 
> > There are passwords in neutron config files, and there may be other secrets 
> > in log files that should be excluded. I have not tried to identify these, and 
> > some details may not be available until at least the upstream H-3 release 
> > since new functionality is still be implemented.
> 
> I can't put this into RHEL until we have that information; if we release
> stuff that gathers secrets we are asking for CVEs against the sos package.

I'm working on this right now, for both grizzly (RHOS 3) and havana (RHOS 4). I should have the lists by the end of the day. 

Note that I'm just identifying the config item names and their groups, not the specific files they can appear in (since the config file names aren't really baked-in). Will sos be able to filter all the files under /etc/quantum (RHOS 3) or /etc/neutron (RHOS 4) based on the group and item names?

> 
> When do you expect the H-3 release to be finalised?

The Neutron feature freeze for Havana is 8/23, so changes are likely until then, but things can change any time.

I noticed that the oslo.config facility used in OpenStack has the ability to declare items secret. It appears this is intended to prevent those configuration items' values from being logged (they get replaced by a string of *'s of the same length). Unfortunately, it is not used very consistently, at least in neutron. It seems that the ideal long term approach would be to make sure all config items that should be are declared secret in the code, and then use some tool to extract this info for sos.

Since the neutron programs log all the config values in effect at startup (at DEBUG level) and the secret marking is not used consistently, the log files under /var/log/neutron or /var/log/quantum also need to be sanitized for these same items. In the log files, they are formatted:

item = value

or

group.item = value

whereas in the config files they are formatted:

item = value

or 

[group]
item = value

So, specific secrets from config files in /etc/quantum that I see are:

api-paste.ini:admin_password=password

metadata_agent.ini:admin_password = password
metadata_agent.ini:metadata_proxy_shared_secret =password

plugin.ini:sql_connection = mysql://quantum:password.102.222/ovs_quantum

quantum.conf:qpid_password = guest
quantum.conf:admin_password = password

Also:
plugins/openvswitch directory
ovs_quantum_plugin.ini:sql_connection = mysql://quantum:password.102.222/ovs_quantum

These would need to be scrubbed from the sosreport

The challenge of course is that arbitrary other plugins will be in this /etc directory, some of which not even shipped by Red Hat (3rd party Quantum Plugins)

But perhaps each of the plugins will similarly have sql_connection, so you could just always filter out that particular key/value

Here are the grizzly (RHOS 3) config secrets I found:

CLUSTER:*.nvp_controller_connection ***
DATABASE.sql_connection
DEFAULT.admin_password
DEFAULT.metadata_proxy_shared_secret
DEFAULT.qpid_password
DEFAULT.rabbit_password
MIDONET.password
PLUMgridNOS.password
PROXY.admin_password
RESTPROXY.server_auth
SWITCH.password
matchmaker_redis.password ***

and here are the havana (RHOS 4) config secrets I found:

CLUSTER:*.nvp_controller_connection ***
DEFAULT.admin_password
DEFAULT.database.connection
DEFAULT.metadata_proxy_shared_secret
DEFAULT.nvp_password
DEFAULT.qpid_password
DEFAULT.rabbit_password
DEFAULT.sql_connection (deprecated)
MIDONET.password
PLUMgridDirector.password
PROXY.admin_password
RESTPROXY.server_auth
SWITCH.password
database.slave_connection
matchmaker_redis.password ***

In the config files, the group name is in in brackets before the items in that group. 

In the log files, they would be printed as shown, except that the DEFAULT group does not include the "DEFAULT." prefix.

The config items with "***" are not marked secret in the code, and will therefore not be automatically sanitized in the log files. The other items should all be sanitized as they are written to the log files.

Bryn,

What exactly is needed from me at this point? Is there something I should review?

-Bob

Closing this bug as it seems like the information needed was provided and there are no further AI on engineering.