[jira] [Commented] (BROOKLYN-10) Dumping sensitive information in the debug log

["Alex Heneveld (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/BROOKLYN-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352868#comment-14352868 ] 

Alex Heneveld commented on BROOKLYN-10:
---------------------------------------

Agree that the default logging should not show sensitive information. A few thoughts on this:

* It would be nice to have a way to disable all log sanitizing, either a {{BrooklynServerConfig}} or a special logger.
* Note that many things call to {{Entities.sanitize(Map)}} (or {{ConfigBag}}), which uses a simplistic built-in strategy
* We've discussed elsewhere (on ML) the prospect of a {{Sensitivity}} field on config keys which would be a more principled and extensive way to do this, but currently the holes are probably lower-level
* jclouds does a pretty good job, unless wire log level is turned on of course (see below); however our location code in particular sometimes logs more info to make machines easier to use, particular note should be paid here
* We should treat our ssh wire log similarly to jclouds wire log (particularly since this is available in the API now we can make this an opt-in feature)
* When we log root brooklyn properties and built-in locations I don't think they are sanitized
* If something points at a file it probably should *not* be sanitized (e.g. i think {{privateKeyFile}} *will* currently be sanitized; that should *not* be the case, so exclude private+file from the sanitize filter?)
* Where we sanitize something, if possible display some kind of one-way hash so the value can be validated if someone knows what it should be
* if a credential is included in a URL it will be too hard to sanitize that; suggest we treat it as a separate piece of work to support an injectable URL credentials scheme

Things to document:
* "Brooklyn makes best effort not to write sensitive information to the log or render it in the GUI where it might be accidentally revealed to others. In the GUI, you can click on an obscured item to reveal the value when it is needed. For the logs, you can configure logging to include sensitive information through a BrooklynServerConfig config key (or whatever mechanism) ..."
* If a jclouds or ssh wire log is enabled, that will almost always include sensitive information
* A crib sheet for generating a hash to validate sensitive information (e.g. what is our hash function, how can someone easily generate that; and what do the hashes that jclouds reports mean ... that's something i've wondered when trying to confirm keys but haven't felt enough pain to research how to generate a hash from my key; if there are a few references we can point to for that this would be quite useful)


> Dumping sensitive information in the debug log
> ----------------------------------------------
>
>                 Key: BROOKLYN-10
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-10
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Svetoslav Neykov
>
> Brooklyn dumps sensitive information in the debug log like passwords and private keys. I tracked it (at least) to the following locations
>   * brooklyn.entity.software.MachineLifecycleEffectorTasks. provisionAsync(MachineProvisioningLocation<?>) (current line is 239)
> Entities.sanitize goes just one level deep, leaving deeper info untouched (in this case the config object)
>   * brooklyn.location.basic.BasicLocationRegistry.updateDefinedLocations() (current line is 153)
> definedLocations.values() is not sanitized at all, leaving all the info from the properties file visible



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)