-
Bug
-
Resolution: Done
-
Normal
-
None
-
4.13, 4.12, 4.14
-
Moderate
-
No
-
False
-
This is a clone of issue OCPBUGS-16171. The following is the description of the original issue:
—
Description of problem:
tls-server-name is missing when using oc client causing x509: certificate signed by unknown authority. Here is PR https://github.com/openshift/oc/issues/1457. Please use this slack thread for any reference. https://redhat-internal.slack.com/archives/CKJR6200N/p1689170150899359
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
A kubeconfig might look like this:apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJ.......<redacted>.... server: https://celonis.teleport.sh:443 tls-server-name: kube-teleport-proxy-alpn.celonis.teleport.sh name: celonis.teleport.sh contexts: - context: cluster: celonis.teleport.sh user: celonis.teleport.sh-<cluster_name> name: celonis.teleport.sh-<cluster_name> current-context: celonis.teleport.sh-<cluster_name>When running oc commands against the default namespace these commands succeed:oc get pods No resources found in default namespace. When running the oc project <namespace> command this modifies the context and sets the namespace. When this operation occurs the tls-server-name attribute is not obeyed which then causes an x509$oc project <namespace> Now using project "<namespace>" on server "https://celonis.teleport.sh:443". $oc get pods --loglevel 8 I0613 12:41:05.038351 122971 loader.go:373] Config loaded from file: /home/kwoodson/.kube/config I0613 12:41:05.046716 122971 round_trippers.go:463] GET https://celonis.teleport.sh:443/api/v1/namespaces/<namespace>/pods?limit=500 I0613 12:41:05.046732 122971 round_trippers.go:469] Request Headers: I0613 12:41:05.046741 122971 round_trippers.go:473] User-Agent: oc/4.13.0 (linux/amd64) kubernetes/92b1a3d I0613 12:41:05.046746 122971 round_trippers.go:473] Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json I0613 12:41:05.121700 122971 round_trippers.go:574] Response Status: in 74 milliseconds I0613 12:41:05.121716 122971 round_trippers.go:577] Response Headers: I0613 12:41:05.121787 122971 helpers.go:264] Connection error: Get https://celonis.teleport.sh:443/api/v1/namespaces/<namespace>/pods?limit=500: x509: certificate signed by unknown authority Unable to connect to the server: x509: certificate signed by unknown authority If we review the kubeconfig we can see a new context was added as well as a new server:apiVersion: v1 clusters: - cluster: certificate-authority-data: <redacted> server: https://celonis.teleport.sh:443 name: celonis-teleport-sh:443 - cluster: certificate-authority-data: <redacted> server: https://celonis.teleport.sh:443 tls-server-name: kube-teleport-proxy-alpn.celonis.teleport.sh name: celonis.teleport.sh contexts: - context: cluster: celonis.teleport.sh user: celonis.teleport.sh-<namespace> name: celonis.teleport.sh-<namespace> - context: cluster: celonis-teleport-sh:443 namespace: <namespace> user: kwoodson/celonis-teleport-sh:443 name: <namespace>/celonis-teleport-sh:443/kwoodson current-context: <namespace>/celonis-teleport-sh:443/kwoodson As we can see the tls-server-name attribute in this context was not copied to the new context. If I copy this attribute from the old cluster to the new cluster this works.
Actual results:
Expected results:
Additional info:
- clones
-
OCPBUGS-16171 Backporting tls-server-name is missing when using oc client
- Closed
- is blocked by
-
OCPBUGS-16171 Backporting tls-server-name is missing when using oc client
- Closed
- links to