TLSServerName is not taken into account
nicolas-goudry opened this issue · 5 comments
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
Yeah, that's not currently supported in our TLS. We'd be happy to take a PR to add support.
Yeah, that's not currently supported in our TLS. We'd be happy to take a PR to add support.
I’m not a Java developer, I reported this issue because some applications from my company use the Java client and some of our customers use Teleport so the said apps don’t work for them.
Our Java developer don’t have any bandwidth to take this matter into his hands, so I hope someone could work on this 🙏
Hello,
Can we consider this issue like one for newcomers in this project?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/stale
is applied - After 30d of inactivity since
lifecycle/stale
was applied,lifecycle/rotten
is applied - After 30d of inactivity since
lifecycle/rotten
was applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale
- Close this issue with
/close
- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale