Question

我正在使用Azure容器服务中运行的Kubernetes集群。我们使用SSL Interception，这会导致任何kubectl命令返回此错误：

Unable to connect to the server: x509: certificate signed by unknown authority

我正在研究macOS 10.12.6

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.1", GitCommit:"f38e43b221d08850172a9a4ea785a86a3ffa3b3a", GitTreeState:"clean", BuildDate:"2017-10-11T23:27:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.9", GitCommit:"19fe91923d584c30bd6db5c5a21e9f0d5f742de8", GitTreeState:"clean", BuildDate:"2017-10-19T16:55:06Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

以下是运行kubectl version

的详细输出

$ kubectl version --v=10
I1128 10:27:28.721914   16346 loader.go:357] Config loaded from file /Users/foo/.kube/config
I1128 10:27:28.726719   16346 round_trippers.go:417] curl -k -v -XGET  -H "Accept: application/json, */*" -H "User-Agent: kubectl/v1.8.1 (darwin/amd64) kubernetes/f38e43b" https://foo.westus2.cloudapp.azure.com/version
I1128 10:27:29.046962   16346 round_trippers.go:436] GET https://foo.westus2.cloudapp.azure.com/version  in 320 milliseconds
I1128 10:27:29.046989   16346 round_trippers.go:442] Response Headers:
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.1", GitCommit:"f38e43b221d08850172a9a4ea785a86a3ffa3b3a", GitTreeState:"clean", BuildDate:"2017-10-11T23:27:35Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
I1128 10:27:29.047291   16346 helpers.go:225] Connection error: Get https://foo.westus2.cloudapp.azure.com/version: x509: certificate signed by unknown authority
F1128 10:27:29.047310   16346 helpers.go:120] Unable to connect to the server: x509: certificate signed by unknown authority

我尝试过的事情：

设置--insecure-skip-tls-verify=true会导致另一个错误Unable to connect to the server: EOF
将https_proxy设置为不受SSL拦截的代理正常工作
从apiserver导入并信任ca

Answer 1

kubectl 使用 Kubeconfig 文件的 certificate-authority-data 字段中定义的证书颁发机构，在操作系统的受信任证书颁发机构之外自行验证集群证书。

执行拦截的设备很可能是 a) 用自己的、由不同 CA 签名的证书替换了集群的证书，以及 b) 无法验证由不同 CA 签名的集群证书。

根据集群的构建方式，您可能能够根据拦截设备信任的预先存在的 CA 而不是集群的单独 CA 颁发证书。这远远超出了 StackOverflow 答案的范围； Kubernetes Up and Running 和 Kubernetes the Hard Way 是很好的起点，您可能需要阅读 Kubernetes 源代码才能正确了解证书的所有关键用法。 >

应该注意的是，SSL 拦截被认为是一种不好的做法（尽管它在银行等某些行业中很普遍）。 TLS 1.3 旨在通过独家使用 Perfect Forward Secrecy 来完全防止这种情况发生。

在SSL拦截后面使用kubectl

1 个答案: