Import/regenerate server SSH keys #547
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
openshift-ci
bot
added
the
cluster-config-api-changed
omertuc
changed the title
openshift-merge-robot
added
the
needs-rebase
openshift-merge-robot
removed
the
needs-rebase
omertuc
force-pushed
the
serverssh
branch
4 times, most recently
from
95aa0fa
to
1ccfebf
Compare
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
openshift-ci
bot
added
the
do-not-merge/work-in-progress
# 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): ``` @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ ``` # 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 of `ServerSSHKey` 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.
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
/remove-label cluster-config-api-changed |
openshift-ci
bot
removed
the
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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
tsorya
reviewed
Jun 4, 2024
| return nil | ||
| } | ||
|
|
||
| func removeOldServerSSHKeys() error { |
There was a problem hiding this comment.
maybe lets not bring them from seed?
There was a problem hiding this comment.
We can do that as part of https://issues.redhat.com//browse/MGMT-17988
There was a problem hiding this comment.
Will mention that in the ticket comments
|
/lgtm |
openshift-merge-bot
bot
merged commit c9cd484
into
openshift-kni:main
7 of 9 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
SeedReconfigurationstruct to hold the server SSH keys. This field is a list ofServerSSHKeystructs, 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.