Aled Sage created BROOKLYN-282:
----------------------------------
Summary: 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)
