Add trust configuration for cross cluster api keys

[jfreden]

This PR adds trust configuration for cross-cluster API keys.

The actual verification of certificate dn to cross cluster api keys will be added in subsequent PRs.

The new configurations are:

cluster.remote.signing.truststore.path
cluster.remote.signing.truststore.secure_password
cluster.remote.signing.truststore.algorithm
cluster.remote.signing.truststore.type
cluster.remote.signing.certificate_authorities

• All new cluster settings can be dynamically updated through the cluster settings API
• All new secure settings can be reloaded through the reload_secure_settings API
• All files pointed to by the new settings are hot reloadable and the trust config will automatically be updated when the files change

[elasticsearchmachine]

Pinging @elastic/es-security (Team:Security)

[elasticsearchmachine]

Hi @jfreden, I've created a changelog YAML for you.

[tvernum]

I would move this check into SslConfiguration - it seems like something useful to push up.

That is,

var sslConfig = loadSslConfig(environment, settings);
if (sslConfig.hasExplicitTrustConfig()) {
 ....
}

It like that this PR reduces the amount of custom certificate handling we have. If there are opportunities to push more SSL/certificate related things up that's generally going to be good.

[jfreden]

I moved the hasExplicitConfig check into SslTrustConfig. While doing that I realized that we might want to allow the default jdk trust store as a valid config. Do you agree with that? So if you configure nothing, that's what you'll get.

The thing I was trying to protect against with that check was that the customer doesn't accidentally trust the key store setup for signing, since it doesn't feel like I would expect that to happen.

[tvernum]

This has one {} but two args.

Suggested change

	logger.warn("Cross cluster API Key trust configuration [{}] has no accepted certificate issuers", this, trustConfig);
	logger.warn("Cross cluster API Key trust configuration [{}] has no accepted certificate issuers", trustConfig);

[tvernum]

It might be worth being explicit about which method handles trust and which handles signing.

Suggested change

	public Collection<Path> getDependentFiles() {
	public Collection<Path> getDependentTrustFiles() {

or some other name of your choosing.

[tvernum]

Suggested change

	public Collection<Path> getDependentFiles(String clusterAlias) {
	public Collection<Path> getDependentSigningFiles(String clusterAlias) {

[tvernum]

This is a plausible scenario if someone updates the cluster settings to remove the trust config, right?

In that case I think these messages need to be a bit more explicit about what's happened.

Something like

Cannot verify signed cross-cluster headers because [cluster.remote.signing] has not trust configuration

[tvernum]

I think it's worth a trace log here

Suggested change

	authTrustManager.checkClientTrusted(signature.certificates(), signature.certificates()[0].getPublicKey().getAlgorithm());
	var leaf = signature.certificates()[0];
	if (logger.isTraceEnabled()) {
	logger.trace("checking signing chain (len={}) [{}] with leaf subject [{}] using algorithm [{}]",
	signature.certificates().length,
	Arrays.stream(signature.certificates()).map(CrossClusterApiKeySignatureManager::calculateFingerprint).collect(Collectors.joining(",")),
	leaf.getSubjectX500Principal().getName(X500Principal.RFC2253),
	leaf.getPublicKey().getAlgorithm
	);
	}
	authTrustManager.checkClientTrusted(signature.certificates(),left.getPublicKey().getAlgorithm());

[tvernum]

I can never remember how much the trust manager does for you here. I think it does more than you'd expect from the name, but maybe not everything we need.

[jfreden]

I left the todo very broad to make sure I verify everything when we do the "certificate belongs to the correct DN" check.

[tvernum]

This could just be a return (rather than needing a local variable).

[tvernum]

Would it better to use Collectors.joining(",") rather than converting to an array here?

[tvernum]

Can we also have tests for:

1. Signed with a different key
2. Manipulate signature string

?