Add new API field nodeSshPublicKey

[tmstff]

https://redhat.atlassian.net/browse/ARO-26939

What

New (ARO-HCP) API version exposing the nodeSshPublicKey field to customers, as part of an effort to provide ssh access to cluster nodes for customers ( https://redhat.atlassian.net/browse/ARO-26935 ).

ARM API change and transmission to CS not part of this story, will be handled in a follow-up.

Why

To allow the customer to provide a ssh public key, which can then be forwarded to HyperShift via Backend and CS.

Testing

• Unit tests (for helper methods and validations)
• Integration tests (to make sure the API functions as expected, also with different API versions)
• E2E tests (which can later on be extended to test ssh login)
  • run test against personal-dev-env: make e2e-local/run-test TEST_NAME="Customer should persist nodeSshPublicKey set at cluster creation and return it via ARM GET"

Special notes for your reviewer

models.go and models_serde.go are generated (via make testsdk) and contain code that is not directly related to this PR - seemed to be alright like that anyways.

internal/api/utils_test.go was added, because it seemed untested so far.

PR Checklist

• PR is scoped to a single task (no mixed concerns)
• Title follows Conventional Commits format
• Summary explains the "Why" behind the change
• Linked to relevant ticket/issue
• Screenshots included (if graph/UI/metrics changes)
• Self-reviewed the diff
• CI/CD checks are passing (ignore Tide)
• Draft PR used for WIP (if applicable)
• Commit history is clean (rebased/squashed)
• Tricky code blocks are commented
• Specific reviewers tagged
• All comment threads resolved before merge

If E2E tests are included:

• E2E tests follow Principles of Good E2E Test Case Design
• If new E2E use case is covered (via a new test or new check/verifier),
  demonstrate that the test is able to detect a defect/error and fail with
  proper error message and logs which communicates nature of the problem.

[openshift-ci]

Hi @tmstff. Thanks for your PR.

I'm waiting for a Azure member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[tmstff-azure]

/ok-to-test

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tmstff
Once this PR has been reviewed and has the lgtm label, please assign mbarnes, miquelsi for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• api/OWNERS
• internal/OWNERS
• test/OWNERS
• test-integration/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tmstff]

/test api-validation

[tmstff]

/test e2e-parallel

[tmstff-azure]

/test e2e-parallel
/test api-validation

[miguelsorianod]

Where do the pattern and maxlength come from?

[miguelsorianod]

Does this mean this field accepts one and only one SSH public key?

In the Hypershift API, the corresponding attribute in the HostedCluster:

	// sshKey is a local reference to a Secret that must have a "id_rsa.pub" key whose content must be the public part of 1..N SSH keys.
	// If the reference is set but none of the above requirements are met, the HostedCluster will enter a degraded state.
	// TODO(alberto): Signal this in a condition.
	// When sshKey is set, the controllers will generate a machineConfig with the sshAuthorizedKeys https://coreos.github.io/ignition/configuration-v3_2/ populated with this value.
	// This MachineConfig will be part of every payload generated by the controllers for any NodePool of the HostedCluster.
	// Changing this value will trigger a rollout for all existing NodePools in the cluster.
	// +rollout
	// +optional
	SSHKey corev1.LocalObjectReference `json:"sshKey"`

Which if I understand correctly technically allows providing multiple (confirm this as I just checked superficially)

Were/are we aware of this and is our design where it seems to differ intentional?