Add InMemoryClonedSecureSettings for keeping temporary secure settings loaded

[jfreden]

The pattern to load secure settings for later use during secure settings reload has been repeated across the code base and is now needed by #134137. This PR extracts the functionality to a InMemoryClonedSecureSettings utility class.

[elasticsearchmachine]

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

[elasticsearchmachine]

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

[mosche]

Imho if turning this into a general util, this requires a bit more care in a few places. See the comments below.

I'm just wondering, are there no security concerns around providing such a simple util to work around the purpose of secure settings?

[jfreden]

I'm just wondering, are there no security concerns around providing such a simple util to work around the purpose of secure settings?

I'm suspecting that's why this has not been added before and that was also my hesitation. This utility class works against the current intention of the KeyStoreWrapper - that the settings are only available during the reload to refresh some state and then dropped.

The security implication is that the secure settings that are "always loaded" will be in memory and visible in a heap dump. The secure settings approach we're taking with the KeyStoreWrapper isn't immune to that, even if the settings are just loaded for a while they can be extracted and stored in some state past the reload.

I think ideally the settings would be extracted and stored in an instance variable of the class that uses it. The problem this PR solves is that the actual Settings object is needed at some later point by the code we're using and having some intermediate representation of the settings becomes hacky.

[tvernum]

In practice, we need to retain some secure settings in memory.

They're used in places that are dynamic - typically because the secure setting is paired with some other dynamic cluster settings - and we can't clear them from memory after the first use.

We definitely don't want to retain all secure settings in memory, but making it hard to do the thing we have to do, doesn't help anyone. It just forces duplication of the same work-arounds, often with poorer security than we would have gotten if we'd just implemented something that filled the need.

I think we can come up with a better name that LoadedSecureSettings, one that reflect the compromise we've having to make, but I'm not sold on an argument that we should keep it out of core so that we end up with multiple reimplementations of the same thing.

[jfreden]

Thanks for the feedback! I've changed the name to ClonedSecureSettings and added some more javadoc.

[mosche]

I think we can come up with a better name that LoadedSecureSettings, one that reflect the compromise we've having to make

How about InMemoryClonedSecureSettings or just InMemorySecureSettings to highlight that compromise?

but I'm not sold on an argument that we should keep it out of core so that we end up with multiple reimplementations of the same thing.

keeping it out of core was never my intention, if we highlight the compromise and make devs well aware (as done in the Javadocs now) I'm totally fine with this

[mosche]

lgtm provided tests pass, just a few optional suggestions