Closed omertuc closed 4 weeks ago
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
/remove-label cluster-config-api-changed
/approve
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: omertuc
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/lgtm
Background / Context
Every server has unique SSH server keys which help clients verify the server's identity (not to be confused with authorized keys, which are the list of public keys of clients that are allowed to log into the server).
Ideally, during IBI, we would regenerate the server SSH keys in the seed to avoid using the seed's SSH keys. This is because we don't want all cluster spun up from the same seed to have the same server SSH keys.
During IBU, we should use the server SSH keys from the original cluster to maintain the same server SSH fingerprint (otherwise, when a user tries to SSH following an IBU upgrade, they will see a warning that the server's fingerprint has changed).
Issue / Requirement / Reason for change
Currently, we're simply using the keys that are present in the seed (ticket MGMT-16818):
Solution / Feature Overview
During IBI, ask recert to regenerate fresh SSH server keys. In IBU, delete the existing seed keys and copy the server SSH keys from the original cluster.
Implementation Details
Add a new field to the
SeedReconfiguration
struct to hold the server SSH keys. This field is a list ofServerSSHKey
structs, each of which contains the file name and content of the server SSH key.If the list is empty (indicating IBI), we will ask recert to regenerate the server SSH keys.
The copying of the keys is done simply by LCA's post-pivot phase. We don't use recert for this because it's overkill, just need to delete some files and create new ones, no changes in the etcd database are needed.
Other Information
This work is incomplete, created a separate MGMT-17988 to track the purposeful invalidation of seed server SSH keys. Right now the seed image still contains the true server SSH keys of the seed cluster, which is not ideal as it compromises the security of the seed cluster.
Ideally we would regenerate the seed server SSH keys during seed image generation, and then restore the original server SSH keys once the seed cluster is restored. This would ensure that the seed image does not contain the true server SSH keys of the seed cluster and that the seed cluster's SSH fingerprint remains the same after seed generation.