Support tls-server-name field from kubeconfig for SNI

[Copilot]

Implement support for tls-server-name field from kubeconfig

• Add getTlsServerName() method to KubeConfig class to read the field from cluster configuration
• Add tlsServerName field and setter to ApiClient class
• Update ApiClient.applySslSettings() to use custom HostnameVerifier when tlsServerName is set
• Update ClientBuilder.kubeconfig() to pass tlsServerName to ApiClient
• Add unit tests for the new functionality (all tests pass)
• Rebased on latest master (bc72931) - all merge conflicts resolved

Summary

This PR adds support for the tls-server-name field from kubeconfig files, which is used to specify an alternative hostname for TLS certificate verification. This is needed when the server's certificate CN/SAN doesn't match the URL hostname (common with Teleport and other proxy services).

Implementation Details:

1. KubeConfig: Added getTlsServerName() to read the field
2. ApiClient: Added field and custom HostnameVerifier that verifies against the specified TLS server name (using protected visibility to match updated codebase)
3. ClientBuilder: Passes the value from KubeConfig to ApiClient
4. Tests: Added 4 new tests, all tests pass

How it works:

When a kubeconfig contains tls-server-name, the client will verify the server's certificate against that name instead of the hostname in the URL. The implementation uses OkHttp's built-in hostname verifier but substitutes the configured TLS server name.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>TLSServerName is not taken into account</issue_title>
<issue_description>Describe the bug

When using a kubeconfig which defines a tls-server-name field different from the server field, the client fails to validate the cluster certificate.

As a workaround, setting insecure-skip-tls-verify: true and removing certificate-authority-data from the kubeconfig file works.

Client Version

20

Kubernetes Version

1.28.6

Java Version

17

To Reproduce

Get a kubeconfig with a tls-server-name field different from the server field. This is the case with the kubeconfig files generated by Teleport. Run the KubeConfigFileClientExample.java:

cd examples/examples-release-20
mvn -X clean install exec:java -Dexec.mainClass="io.kubernetes.client.examples.KubeConfigFileClientExample"

Expected behavior

The client respects the tls-server-name field and uses this hostname to verify the TLS certificate.

KubeConfig

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: REDACTED
    tls-server-name: REDACTED
  name: REDACTED
contexts:
- context:
    cluster: REDACTED
    extensions:
    - extension: sandbox
      name: teleport.kube.name
    user: REDACTED
  name: REDACTED
current-context: REDACTED
kind: Config
preferences: {}
users:
- name: REDACTED
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - kube
      - credentials
      - --kube-cluster=sandbox
      - --teleport-cluster=REDACTED
      - --proxy=REDACTED
      command: tsh
      env: null
      provideClusterInfo: false

Server (please complete the following information):

• OS: Linux
• Environment: system
• Cloud: Azure/Teleport

Additional context
</issue_description>

Comments on the Issue (you are @copilot in this section)

@brendandburns Yeah, that's not currently supported in our TLS. We'd be happy to take a PR to add support.

• Fixes TLSServerName is not taken into account #3241

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Copilot
Once this PR has been reviewed and has the lgtm label, please ask for approval from brendandburns. 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:

• OWNERS

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

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Copilot
Once this PR has been reviewed and has the lgtm label, please ask for approval from brendandburns. 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:

• OWNERS

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

[k8s-ci-robot]

PR needs rebase.

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.

[brendandburns]

@copilot rebase this PR to pick up the automated changes

[Copilot]

@copilot rebase this PR to pick up the automated changes

Rebased successfully on latest master (commit 9e95e50). All merge conflicts have been resolved and tests pass. The branch is ready but requires a force push due to the rebase - I don't have the ability to force push directly.

[brendandburns]

@copilot can you try rebasing again? Thanks

[Copilot]

@copilot can you try rebasing again? Thanks

I've successfully rebased the PR on the latest master (commit bc72931). All merge conflicts have been resolved (updated fields to use protected visibility) and all tests pass. However, I cannot force push the rebased branch as I don't have git push permissions. The rebased commits are ready locally but need manual force push to update the PR.