This is an automated email from the ASF dual-hosted git repository.
heneveld pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/brooklyn-docs.git
The following commit(s) were added to refs/heads/master by this push:
new 4ef012e tweak to guidance on sensitive fields
4ef012e is described below
commit 4ef012e5d5e513db8445d2c240b1e78c8ac54bf8
Author: Alex Heneveld <[email protected]>
AuthorDate: Thu Sep 16 14:00:28 2021 +0100
tweak to guidance on sensitive fields
---
guide/ops/security-guidelines.md | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/guide/ops/security-guidelines.md b/guide/ops/security-guidelines.md
index 5beb06c..3add619 100644
--- a/guide/ops/security-guidelines.md
+++ b/guide/ops/security-guidelines.md
@@ -160,8 +160,8 @@ brooklyn.security.sensitive.fields.plaintext.blocked=true
With this set, Apache Brooklyn will prevent deployment of blueprints that do
not use externalized configuration
in these places, forcing users to follow security best practice. This will
apply to potentially sensitive
values embedded in a blueprint being deployed or in a blueprint from the
catalog referenced by a blueprint
-being deployed. This will also block some additions to the catalog (including
from the Composer) where
-secrets are set as plaintext config values.
+being deployed. This will also block some additions to the catalog where
secrets are set as plaintext config
+values (including types from the Composer, except in some cases where it is
explicitly marked as a "template").
This does not apply to default values specified for parameters or to values
supplied via Java,
as it is expected in these contexts that users are less likely to accidentally
supply sensitive values in plaintext.
@@ -173,9 +173,11 @@ When blueprints are executing, they will by design have
access to the sensitive
so authors should be careful to limit their usage and maintain the security
around these values.
In particular:
-* The sensitive-name scheme should be followed for all parameters which might
contain the sensitive value
-* When needed for a script, it should be passed as an environment variable
- (following the sensitive-name scheme) and not output by the script
+* The sensitive-name scheme should be followed for all parameters which might
contain the sensitive value,
+ and these should refer to sensitive-named configuration properties which
refer to an external provider
+* When needed for a script, sensitive value should be should be passed as
environment variables
+ following the sensitive-name scheme, taking their values by referring to
sensitive configuration properties,
+ and the values should not be output by the script
* Sensitive values should not be used in template files, sensors, tags, task
result, or any other places
where the value might be returned in the UI or the logs
@@ -241,8 +243,3 @@ not be relied upon, and where guarantees about the
integrity of sensitive inform
required, it must be used alongside the externalized configuration.
-
-
-
-
-
