Open
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: falseServer (please complete the following information):
- OS: Linux
- Environment: system
- Cloud: Azure/Teleport
Additional context