Implement the `activateKeys` and `keyStatePollingSeconds` options in the `security.kmip` config section

The table below summaries how the feature is going to behave. The first tree columns list the version of Percona Server for MongoDB and the config parameters. The further columns list three situations in which the behavior depends on the version and config parameters.

Explicitly setting the activateKeys parameters to false completely disables the feature (line 1). When the feature is explicitly enabled (lines 2 and 3), Percona Server activates all new keys. On startup with an already encrypted data directory, it refuses to work with a non-active key. After any startup, a positive value of keyStatePollingSeconds makes Percona Server for MongoDB to periodically (period equals to the value of keyStatePollingSeconds) check the state of the key and shut down if the key goes to the non-active state. The polling can be disabled separately while preserving key activation and state check at startup by a negative value of keyStatePollingSeconds (line 3).

The default values for activateKeys and keyStatePollingSeconds are true and 900 respectively (lines 4 and 5).

At present, before the feature has been introduced, all the keys are in Pre-Active state. So in order to avoid shutting down on startup after an minor version upgrade, already released major versions of Percona Server for MongoDB treat the Pre-Active state tolerably (lines 6 and 7), when configured by default. They log a warning and continue the starting up. As a result, an operation team is made aware of the necessity to active keys and given time to activate the existing keys or rotate to the new (activated) ones. It is only since upgrade to 8.0 when the stricter behavior on a non-active key is enforced.

Table 1. What Percona Server for MongoDB does when…

Let me add more context.

This couple of options implements key activation and state polling, meaning that each new key created on a KMIP server is transitioned to the Active state. Then, its state is periodically polled to check whether the key is still active. If this not the case, the mongod terminates itself with an error in log.

Key activation and state polling make recovery from a compromised master encryption key easier and quicker. Consider a database cluster with several hundred nodes. Each node has its own master encryption key. If one of them gets compromised, we must rotate it as soon as possible, but how do we discover which node it belong to? Without key state polling we will need to rotate master encryption keys on the whole cluster, which is tedious and time consuming task. On the contrary, if key state polling enabled, a security engineer just need to put the compromised key in any state other than Active on a KMIP server, and the affected mongod instance will detect that no later than in a configurable polling interval and stop the process. One only needs to rotate the master encryption key on that particular node.

In version 8.0, the feature is going to be enabled by default (as it is done in the upstream), but earlier created master encryption keys are in Per-Active state on the KMIP server. That means that one needs to manually transition all the master encryption keys to the Active state before upgrading to version 8.0. Alternatively, they can do master key rotation on each node just after installing version 8.0, but before running it. Rotation will create and activate new master encryption key.