[
https://issues.apache.org/jira/browse/BROOKLYN-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15331376#comment-15331376
]
Aled Sage commented on BROOKLYN-282:
------------------------------------
Note that with 0.10.0 and later, it will be important to always run with
{{org.apache.cxf}} logging above debug. Otherwise, you will likely get log
messages like that below:
{noformat}
brooklyn.debug.log:2016-06-14 21:43:28,862 DEBUG o.a.c.s.i.AbstractInvoker
[brooklyn-jetty-server-8082-qtp1970185138-38]: Invoking method public
javax.ws.rs.core.Response
org.apache.brooklyn.rest.resources.EffectorResource.invoke(java.lang.String,java.lang.String,java.lang.String,java.lang.String,java.util.Map)
on object org.apache.brooklyn.rest.resources.EffectorResource@3c64f630 with
params [l4p6u3phln, iletlkpn4a, resetPassword, 0, {newPassword=mypassword,
secretPin=1234567}].
{noformat}
The default logging level should be right since
https://github.com/apache/brooklyn-server/pull/198 was merged, which changed
{{logging/logback-includes/src/main/resources/brooklyn/logback-logger-excludes.xml}}
to add:
{noformat}
<logger name="org.apache.cxf" level="ERROR"/>
{noformat}
> Avoid showing secret effector parameters
> ----------------------------------------
>
> Key: BROOKLYN-282
> URL: https://issues.apache.org/jira/browse/BROOKLYN-282
> Project: Brooklyn
> Issue Type: Improvement
> Affects Versions: 0.9.0
> Reporter: Aled Sage
>
> A customer has an effector that takes sensitive data as a parameter (e.g. a
> password).
> There are three places where the value would currently be visible:
> 1. When entering the value (if invoking the effector from the web-console).
> 2. When showing the activity info (in the activity view of the web-console).
> 3. In the logs.
> Elsewhere (e.g. in config and attributes), the default is to infer if it is a
> secret from its config name. This is based on whether it contains any of:
> password, passwd, credential, secret, private, access.cert or access.key. The
> {{org.apache.brooklyn.core.config.Sanitizer}} is used to replace these values
> with "xxxxxxxx". We are careful to call {{Sanitizer.sanitize()}} before
> logging.
> The web-console (i.e. in JavaScript) does something similar for blurring the
> config key values for secrets.
> As a first pass, we could apply the same logic to effector parameters. When
> entering the value, we would mask it out as it was entered. And we would
> subsequently use the {{Sanitizer}} before generating the activity info or
> logging.
> ---
> Longer term, we could also add to ConfigKey (and Sensor) a method
> {{Optional<Boolean> isSecret()}}. If absent, it means no explicit info has
> been given so we can fall back to our inference logic.
> The problem with the {{isSecret()}} method is that the Sanitizer sometimes
> works with a map of string keys. In that context, we don't have the strongly
> typed config key any more so we can't query it to check if a given key is
> secret. We'd need to carefully review the effector parameter usage to see if
> we are ever trying to log (or generate activity info) when only working with
> a map of string keys.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
