<p dir="ltr"><br>
On Nov 18, 2015 13:52, "Devananda van der Veen" <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, Nov 18, 2015 at 9:48 AM, Ruby Loo <<a href="mailto:rlooyahoo@gmail.com">rlooyahoo@gmail.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> I think we all agree that it isn't OK to log credentials (like passwords) in DEBUG logs. However, what about other information that might be sensitive? A patch was recently submitted to log (in debug) the SWIFT temporary URL [1]. I agree that it would be useful for debugging, but since that temporary URL could be used (by someone that has access to the logs but no admin access to ironic/glance) eg for fetching private images, is it OK?<br>
>><br>
>> Even though we say that debug shouldn't be used in production, we can't enforce what folks choose to do. And we know of at least one company that runs their production environment with the debug setting. Which isn't to say we shouldn't put things in debug, but I think it would be useful to have some guidelines as to what we can safely expose or not.<br>
>><br>
>> I took a quick look at the security web page [2] but nothing jumped out at me wrt this issue.<br>
>><br>
>> Thoughts?<br>
>><br>
>> --ruby<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/243141/">https://review.openstack.org/#/c/243141/</a><br>
>> [2] <a href="https://security.openstack.org">https://security.openstack.org</a><br>
>><br>
><br>
> In this context, the URL is a time-limited access code being used in place of a password or keystone auth token to allow an unprivileged client temporary access to a specific privileged resource, without granting that client access to any other resources. In some cases, that resource might be a public Glance image and so one might say, "oh, it's not _that_ sensitive". However, the same module being affected by [1] is also used by the iLO driver to upload a temporary image containing sensitive instance-specific data.<br>
><br>
> I agree that it's not the same risk as exposing a password, but I still consider this an access token, and therefore don't think it should be written to log files, even at DEBUG.<br>
><br>
> -Deva <br>
><br>
></p>
<p dir="ltr">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. </p>
<p dir="ltr">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. </p>
<p dir="ltr">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). </p>
<p dir="ltr">Just $0.02 on this. <br>
--Morgan<br>
</p>