Impact
Upon cluster creation, if the administrator does not specify a cluster token, the bootstrap data for the cluster is encrypted with a key derived from the empty string, rather than a randomly-generated cluster token. This means that any user with direct access to the datastore, or a copy of a datastore backup, would be able to extract the cluster's confidential keying material (cluster certificate authority private keys, secrets encryption configuration passphrase, etc) and decrypt it without having to know the token value.
Note that this confidential material is present on the disk of server (control-plane nodes) and accessible to anyone with root access; the additional exposure path is via a user with read access to the datastore or datastore backups.
Am I affected?
This bug presents itself under the following circumstances:
- Server (control-plane) nodes were not initially started with a token provided via the
--token CLI flag or config file key.
Remediation
Upgrade RKE2 on all server nodes. On startup, updated versions of RKE2 will automatically re-encrypt the bootstrap data using the cluster token, and delete the copy encrypted with the incorrect key.
Mitigation
If it is not possible to upgrade RKE2, administrators may rebuild the cluster from scratch on a new datastore, ensuring that a token is passed during initial cluster creation.
Background
RKE2 encrypts the cluster bootstrap data (cluster CA keys, secrets encryption configuration, etc) at-rest within the datastore, using AES in GCM mode with a 32-byte key derived from the cluster token using PBKDF2, as defined in RFC 2898. In addition to having valid credentials to access the datastore, servers must also know the cluster token in order to decrypt the bootstrap data and successfully join the cluster.
In affected versions, the raw token flag value from the CLI or configuration file was passed in to PBKDF2, rather than using the passphrase portion of the final cluster token (either specified by the user, or randomly generated on initial cluster startup). Fixed versions of RKE2 now detect this condition, properly encrypt the data at all times, and correct datastores previously affected by this issue.
Impact
Upon cluster creation, if the administrator does not specify a cluster token, the bootstrap data for the cluster is encrypted with a key derived from the empty string, rather than a randomly-generated cluster token. This means that any user with direct access to the datastore, or a copy of a datastore backup, would be able to extract the cluster's confidential keying material (cluster certificate authority private keys, secrets encryption configuration passphrase, etc) and decrypt it without having to know the token value.
Note that this confidential material is present on the disk of server (control-plane nodes) and accessible to anyone with root access; the additional exposure path is via a user with read access to the datastore or datastore backups.
Am I affected?
This bug presents itself under the following circumstances:
--tokenCLI flag or config file key.Remediation
Upgrade RKE2 on all server nodes. On startup, updated versions of RKE2 will automatically re-encrypt the bootstrap data using the cluster token, and delete the copy encrypted with the incorrect key.
Mitigation
If it is not possible to upgrade RKE2, administrators may rebuild the cluster from scratch on a new datastore, ensuring that a token is passed during initial cluster creation.
Background
RKE2 encrypts the cluster bootstrap data (cluster CA keys, secrets encryption configuration, etc) at-rest within the datastore, using AES in GCM mode with a 32-byte key derived from the cluster token using PBKDF2, as defined in RFC 2898. In addition to having valid credentials to access the datastore, servers must also know the cluster token in order to decrypt the bootstrap data and successfully join the cluster.
In affected versions, the raw token flag value from the CLI or configuration file was passed in to PBKDF2, rather than using the passphrase portion of the final cluster token (either specified by the user, or randomly generated on initial cluster startup). Fixed versions of RKE2 now detect this condition, properly encrypt the data at all times, and correct datastores previously affected by this issue.