brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <>
Subject [jira] [Resolved] (BROOKLYN-282) Avoid showing secret effector parameters
Date Wed, 15 Jun 2016 15:42:09 GMT


Aled Sage resolved BROOKLYN-282.
       Resolution: Fixed
    Fix Version/s: 0.10.0

> Avoid showing secret effector parameters
> ----------------------------------------
>                 Key: BROOKLYN-282
>                 URL:
>             Project: Brooklyn
>          Issue Type: Improvement
>    Affects Versions: 0.9.0
>            Reporter: Aled Sage
>             Fix For: 0.10.0
> 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

View raw message