config-schema shouldn't log sensitive data

[mshustov]

A customer complains that we config-schema logs sensitive data in the plain text

We provided an invalid encryption key for Kibana 7.6.0 and were surprised to find that when there is an error it logs the encryption key in plain text:
config validation of [xpack.encryptedSavedObjects].encryptionKey]: value is [some_value] but it must have a minimum length of [32].

We need to provide a way to filter out sensitive data. For example, we can mark a key as containing sensitive data to prevent disclosure.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

One other option would be to have a convention to never display the actual data value in any error message. It seems there are only very few messages where we do display the raw values. Most messages are like expected value of type [string] but got [${typeDetect(value)}]

The value is [some_value] but it must have a minimum length of [32] could be changed to valuehas length [XX] but it must have a minimum length of [32].

This would avoid introducing a parameter for that, and the risk that a developer actually forget to flag sensitive data validation with it.

[pgayvallet]

So, after a 'quick' look, impacted types are:

• uri

kibana/packages/kbn-config-schema/src/types/uri_type.ts

Lines 38 to 41 in 790739b

	case 'string.uriCustomScheme':
	return `expected URI with scheme [${scheme}] but got [${value}].`;
	case 'string.uri':
	return `value is [${value}] but it must be a valid URI (see RFC 3986).`;

• string

kibana/packages/kbn-config-schema/src/types/string_type.ts

Lines 45 to 59 in 7949f34

	if (options.minLength !== undefined) {
	schema = schema.custom(value => {
	if (value.length < options.minLength!) {
	return `value is [${value}] but it must have a minimum length of [${options.minLength}].`;
	}
	});
	}
	if (options.maxLength !== undefined) {
	schema = schema.custom(value => {
	if (value.length > options.maxLength!) {
	return `value is [${value}] but it must have a maximum length of [${options.maxLength}].`;
	}
	});
	}

kibana/packages/kbn-config-schema/src/types/string_type.ts

Lines 68 to 69 in 7949f34

	case 'string.hostname':
	return `value is [${value}] but it must be a valid hostname (see RFC 1123).`;

• number

kibana/packages/kbn-config-schema/src/types/number_type.ts

Lines 48 to 51 in b2baf32

	case 'number.min':
	return `Value is [${value}] but it must be equal to or greater than [${limit}].`;
	case 'number.max':
	return `Value is [${value}] but it must be equal to or lower than [${limit}].`;

• record / object / map

kibana/packages/kbn-config-schema/src/types/record_type.ts

Lines 43 to 44 in c13b075

	case 'record.parse':
	return `could not parse record value from [${value}]`;

• literal

kibana/packages/kbn-config-schema/src/types/literal_type.ts

Lines 31 to 32 in 94b2b83

	case 'any.allowOnly':
	return `expected value to equal [${expectedValue}] but got [${value}]`;

• byte_size

kibana/packages/kbn-config-schema/src/types/byte_size_type.ts

Lines 63 to 70 in b2baf32

	case 'bytes.min':
	return `Value is [${value.toString()}] ([${value.toString(
	'b'
	)}]) but it must be equal to or greater than [${limit.toString()}]`;
	case 'bytes.max':
	return `Value is [${value.toString()}] ([${value.toString(
	'b'
	)}]) but it must be equal to or less than [${limit.toString()}]`;

Hiding the actual value in some of these errors will strongly reduce the help the message actually provides (thinking about literal, number, byte_size mostly but all overall). It's probably not that important though. Do we think this is still acceptable to just remove value reference in every of them?