[ https://issues.apache.org/jira/browse/BROOKLYN-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15325856#comment-15325856 ]
Aled Sage commented on BROOKLYN-282: ------------------------------------ See PRs: * https://github.com/apache/brooklyn-server/pull/185 * https://github.com/apache/brooklyn-ui/pull/29 * https://github.com/apache/brooklyn-server/pull/195 > 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)