<div dir="ltr"><div class="gmail_extra">On 20 November 2015 at 18:32, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 11/19/2015 06:00 AM, Lucas Alvares Gomes wrote:<br>
> Hi,<br>
><br>
>> Also keep in mind that DEBUG logging, while still should have some masking<br>
>> of data, since it is explicitly called out (or should be) as not safe for<br>
>> production, can contain some " sensitive" data. Credentials should still be<br>
>> scrubbed, but I would say the swift temp URL is something that may line up<br>
>> with this more flexible level of filtering logs.<br>
>><br>
>> Now, if the service (and I don't think ironic suffers from this issue) is<br>
>> only really runnable with debug on (because there is no useful information<br>
>> otherwise) then I would aim to fix that before putting even potentially<br>
>> sensitive data in DEBUG.<br>
>><br>
>> The simple choice is if there is even a question, don't log it (or log it in<br>
>> a way that obscures the data but still shows unique use).<br>
>><br>
><br>
> I agree with Morgan's statement here.<br>
><br>
> And just throwing an idea in the wind here, we could make use of the<br>
> python logging filters to create a filter for sensitive information.<br>
> We probably need one already to avoid having to do things like [1] in<br>
> the code.<br>
<br>
</span>We actually have a thing to do that:<br>
<a href="https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L215" rel="noreferrer" target="_blank">https://github.com/openstack/oslo.utils/blob/master/oslo_utils/strutils.py#L215</a><br>
<br>
You might need to add a new key to the list of things to mask, but I<br>
think it should be able to handle masking the log message for you.  I<br>
don't know whether configdrive is a globally sensitive key, but if not<br>
then we probably need to revisit the question of whether to allow<br>
extending the key list dynamically in the consuming application instead<br>
of having only the one hard-coded list.  More context here:<br>
<a href="https://bugs.launchpad.net/oslo.utils/+bug/1407811" rel="noreferrer" target="_blank">https://bugs.launchpad.net/oslo.utils/+bug/1407811</a><br>
<div class=""><div class="h5"><br></div></div></blockquote></div><br></div><div class="gmail_extra">The problem is that the developer WANTS to see the temporary URL, so masking it defeats the whole purpose.<div><br></div><div>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...</div><div><br></div><div>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.</div><div><br></div><div>--ruby</div></div></div>