Using kubectl behind SSL Interception

kubectl performs its own verification of the cluster's certificate outside of the OS' trusted certificate authorities, using the certificate authority defined in the certificate-authority-data field of the Kubeconfig file.

It is likely that the device performing the interception is a) replacing the cluster's certificate with its own, signed by a difference CA and b) unable to verify the cluster's certificate, which is signed by a different CA.

Depending on how the cluster is built, you may be able to issue certificates based on a pre-existing CA trusted by the interception device instead of a separate CA for the cluster. This is far beyond the scope of a StackOverflow answer; Kubernetes Up and Running and Kubernetes the Hard Way are good starting points, and you may need to read Kubernetes source code to get all the Key Usages of the certificates right.

It should be noted that SSL Interception is considered a bad practice (though it is widespread in some industries such as banking). TLS 1.3 is designed to prevent it entirely through the exclusive use of Perfect Forward Secrecy.