Open Stack

On Mon, 2015-11-23 at 11:43 -0500, Ruby Loo wrote:
> On 20 November 2015 at 18:32, Ben Nemec <openstack at 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/stru
> > tils.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.


Exactly. The sad thing here is that anyone who tries to use Ironic IPA
w/ Temp URLs is could to get their configuration wrong initially... and
they may very well end up adding the same log statement for the temp
URL (I was just trying to be generally helpful to the next person that
tries this). In my case... the actual URL was the only thing that if
logged would be helpful. Next best thing is just read the python code
yourself I guess...

> 
> 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...

I thought this was what DEBUG was for :). It isn't like the upstream
projects enable by default or anything.

I'm of the belief that you shouldn't have to enable DEBUG in production
and I feel like OpenStack "installers" (my own company included) get it
wrong when they started trending towards defaulting their installations
to enable DEBUG by default.

So yeah. If there is no channel safe for "developer only logs" (DEBUG)
I guess we might should bail on this one.

> 
> 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-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev