On 20 November 2015 at 18:32, Ben Nemec <openst...@nemebean.com> wrote:
> On 11/19/2015 06:00 AM, Lucas Alvares Gomes wrote: > > Hi, > > > >> Also keep in mind that DEBUG logging, while still should have some > masking > >> of data, since it is explicitly called out (or should be) as not safe > for > >> production, can contain some " sensitive" data. Credentials should > still be > >> scrubbed, but I would say the swift temp URL is something that may line > up > >> with this more flexible level of filtering logs. > >> > >> Now, if the service (and I don't think ironic suffers from this issue) > is > >> only really runnable with debug on (because there is no useful > information > >> otherwise) then I would aim to fix that before putting even potentially > >> sensitive data in DEBUG. > >> > >> The simple choice is if there is even a question, don't log it (or log > it in > >> a way that obscures the data but still shows unique use). > >> > > > > I agree with Morgan's statement here. > > > > And just throwing an idea in the wind here, we could make use of the > > python logging filters to create a filter for sensitive information. > > We probably need one already to avoid having to do things like [1] in > > the code. > > We actually have a thing to do that: > > https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L215 > > You might need to add a new key to the list of things to mask, but I > think it should be able to handle masking the log message for you. I > don't know whether configdrive is a globally sensitive key, but if not > then we probably need to revisit the question of whether to allow > extending the key list dynamically in the consuming application instead > of having only the one hard-coded list. More context here: > https://bugs.launchpad.net/oslo.utils/+bug/1407811 > > The problem is that the developer WANTS to see the temporary URL, so masking it defeats the whole purpose. The only thing I was thinking of (besides the developer modifying their code to spit it out) is to have some additional level of debugging that doesn't filter anything sensitive and/or add a config in ironic to log 'only-in-non-production-environments-shows-sensitive-info' with some big warning... My take on this (thanks everyone) is that it is a potential security risk to expose the URL in the logging, so we shouldn't allow it without some other way (besides expecting/documenting INFO level or higher) to prevent it from showing up in production. --ruby
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev