Add support to config schema for marking objects or properties as 'sensitive'

Problem/Motivation

There are many contrib modules that require having access to credentials or that create and store credentials themselves. For example mail modules contain SMTP data, OpenID Connect contains outgoing client secrets, consumers contains incoming client secrets, and so forth.

This data is usually stored in config because it's configuration that's specific to the platform. There are various ways to ensure that config isn't in the database (e.g. by using environment variables and overrides in your settings.php; as long since done by Platform.sh for example). However, in some cases these settings can not be provided externally. This happens when the credentials are created as part of normal operations (e.g. when registering an OAuth client is part of your product).

Within Drupal there's currently no concept of "sensitive config" which means that if this data is stored in the database then it also shows up in things like configuration imports and exports. This could cause these credentials to be accidentally moved outside of the production environment, compromising their security.

Contrib has various ways to ignore configuration being exported, but this is usually a process that's manual for the site builder (e.g. through more configuration). Especially on large platforms it can be difficult to keep track of all the configuration objects that exist and be sure to exclude all the ones that might contain sensitive information. Module maintainers in contrast are usually in a position to know exactly which values should be considered sensitive. So ideally there'd be a way for module maintainers to share that information that downstream tooling can use.

Steps to reproduce

Proposed resolution

Provide a sensitive property which is optional and defaults to false. This property can be set anywhere in the schema definition.

This property can be used by (contrib) modules that deal with configuration (exports) to decide on a more secure approach for handling these values.

Some possible examples of using this information:

• drush cex and drush cim might be configured to ignore config objects with sensitive values entirely
• drush cget might sensor the sensitive value in the output, showing that something is set but not the value itself. This allows inspecting config without leaking the value
• Forms that manage the config might allow entering a new value of the secret but not show the existing value

Remaining tasks

• Agree on the name of the property
• Document how contrib modules might access this information about config, to validate that this indeed enables the use-cases
• Implement the new property in the schema system
• Write tests
• Add a change record

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet