Value Statement

In certain situations, the kubeconfig that ACM console offers for download for HCP (Hypershift) clusters, becomes invalid. Via the API, a custom kubeconfig can be supplies instead. Customers should always be able to download a valid kubeconfig for these clusters from the ACM console.

Definition of Done for Engineering Story Owner (Checklist)

• The existing download kubeconfig action for hypershift clusters provides the customkubeconfig when it is available, falling back to kubeconfig otherwise

Development Complete

• The code is complete.
• Functionality is working.
• Any required downstream Docker file changes are made.

Tests Automated

• [ ] Unit/function tests have been automated and incorporated into the
  build.
• [ ] 100% automated unit/function test coverage for new or changed APIs.

Secure Design

• [ ] Security has been assessed and incorporated into your threat model.

Multidisciplinary Teams Readiness

• [ ] Create an informative documentation issue using the Customer

Portal Doc template that you can access from [The Playbook](

https://docs.google.com/document/d/1YTqpZRH54Bnn4WJ2nZmjaCoiRtqmrc2w6DdQxe_yLZ8/edit#heading=h.9fvyr2rdriby),

and ensure doc acceptance criteria is met.

• Call out this sentence as it's own action:

• [ ] Link the development issue to the doc issue.

Support Readiness

• [ ] The must-gather script has been updated.

Background:

The current hosted cluster setup allows the addition of DNS names pointing to the API endpoint. However, operational limitations exist, including the automatic generation of KubeConfigs and the static nature of the DNS names used in the console login command. There is a need to enhance flexibility in how DNS names are managed and utilized.

User Story:

As a self-managed HCP cluster service consumer, after changing the external DNS Names on a HostedCluster the differents kubeconfigs should be updated properly.

Automated KubeConfig Updates: Automatically generate and update KubeConfigs to reflect the current external DNS settings, ensuring that users have immediate access to the cluster with the latest configurations.

Acceptance Criteria:

Description of criteria:

• Upstream documentation
• After an update of a External DNS names of a HC, the different Kubeconfigs should be updated with the right TLS certificates.

Engineering Details:

• OCPSTRAT: https://issues.redhat.com/browse/OCPSTRAT-1516

Right now the current behaviour when you press the "download Kubeconfig" button is:

• The MCE console checks the hostedcluster.status.kubeconfig field and grabs the name
• Try to get the secret using the name from the above request
• Extracts the kubeconfig field and decode the base64 content
• And begin the download

The new implementation of https://issues.redhat.com/browse/HOSTEDCP-1960 requires to modify this behavior to the next:

Scenario when the customkubeconfig is reported into the hostedcluster status

• The MCE console checks the hostedcluster.status.customkubeconfig field
• Grab the name from that field
• Try to get the secret using the name from the above request
• Extracts the kubeconfig field and decode the base64 content
• And begin the download

Scenario when the customkubeconfig is not reported into the hostedcluster status

• The MCE console checks the hostedcluster.status.customkubeconfig field
• If that field is not reported in the hostedcluster.status
• The MCE console checks the hostedcluster.status.kubeconfig field
• Grab the name from that field
• Try to get the secret using the name from the above request
• Extracts the kubeconfig field and decode the base64 content
• And begin the download

See Slack thread