Kubeadm: 使用签名的kubelet服务证书

@ raravena80我不知道kubeadm在/var/lib/kubelet/pki/下创建的任何证书..您能提供更多信息吗？ 例如，kubeadm配置文件，创建集群的步骤

@fabriziopandini我不确定证书是否由kubeadm创建，但此处描述了一般过程。

这是目录内容的样子：

root@ip-172-31-1-118:/var/lib/kubelet/pki# pwd
/var/lib/kubelet/pki
root@ip-172-31-1-118:/var/lib/kubelet/pki# ls -al
total 24
drwxr-xr-x 2 root root 4096 Jul 23 21:10 .
drwxr-xr-x 7 root root 4096 Nov 12 04:52 ..
-rw------- 1 root root 2810 Jul 23 21:09 kubelet-client-2018-07-23-21-09-53.pem
-rw------- 1 root root 1159 Jul 23 21:10 kubelet-client-2018-07-23-21-10-43.pem
lrwxrwxrwx 1 root root   59 Jul 23 21:10 kubelet-client-current.pem -> /var/lib/kubelet/pki/kubelet-client-2018-07-23-21-10-43.pem
-rw-r--r-- 1 root root 1501 Nov  8 23:53 kubelet.crt
-rw------- 1 root root 1679 Nov  8 23:53 kubelet.key
root@ip-172-31-1-118:/var/lib/kubelet/pki#

它们是kubelet首次加载时创建的kubelet.crt和kubelet.key文件吗？

@ raravena80感谢您的澄清
可能我在这里没有完整的上下文，所以我留给别人回答的余地。

仅一个旁注（可能有帮助）
Kubeadm已经创建了一个名为apiserver-kubelet-client的证书，用于让api服务器与kubelet安全地通信； 它由ca签名并绑定到必要的RBAC规则。

/ assign @liztio

我认为这是为了预先生成kubelet的服务器证书。 我尝试将Kubelet标志用于TLS服务器引导并轮换服务器证书，但不幸的是，我无法让Kubelet使用引导令牌为自己请求服务器证书。 Kubelet最终退回到服务器证书的默认行为，即生成一个自签名证书。

据我所知，目前唯一的解决方法是带外生成Kubelet的服务器证书，并将它们放置在确定的路径上，然后kubelet（由kubeadm配置）将对其进行拾取，并相应地设置一些kubelet标志; 参考： https :

apiserver-kubelet-client是API服务器将提供给kubelet的客户端证书，但是kubelet配置为信任由k8s CA签名的客户端：

# cat /var/lib/kubelet/config.yaml 
address: 0.0.0.0
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
  anonymous:
    enabled: false
  webhook:
    cacheTTL: 2m0s
    enabled: true
  x509:
    clientCAFile: /etc/kubernetes/pki/ca.crt

这是kubelet作为服务器的身份，需要由k8s CA签名，这与原始问题有关。

该线程末尾还进行了一些相关的讨论： https :

我认为kubeadm可能必须为具有有效引导令牌的服务器证书请求添加CSR批准者，就像它对客户端证书请求那样吗？

让Kubelet将其自签名的ca上传到某个地方的configmap怎么样？ nodeadmission插件可以将其限制为仅其自己的configmap。 metrics-server可以使用它来联系节点。

有什么想法吗？

如果可能的话，我认为我们应该使用kubelet中内置的TLS引导工具来请求/旋转服务证书。

@alexbrand我同意

无论出于何种原因，kubelet TLS引导程序只会生成客户端证书：
--bootstrap-kubeconfig string
Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by --kubeconfig. The client certificate and key file will be stored in the directory pointed by --cert-dir.

而kubeadm已经做到了。 也许这是一个kubelet功能请求？

让我们总结一下问题：

正如@anitgandhi概述的
https://github.com/kubernetes/kubeadm/issues/1223#issuecomment -454572577

这里的kubeadm问题是我们没有将几个标志传递给kubelet：

--tls-cert-file=<some-path>/kubelet.crt
--tls-private-key-file=<some-path>/kubelet.key

如果没有这些标志，则kubelet默认在首次运行时对其服务证书进行自签名，可以使用以下方法进行验证：

sudo openssl verify -verbose -CAfile /var/lib/kubelet/pki/kubelet.crt /var/lib/kubelet/pki/kubelet.crt

使用自签名证书而不是集群CA（ /etc/kubernetes/ca.crt ）签名的证书，诸如度量服务器的部署无法抓取kubelet，因为自签名证书SAN仅包含DNS:hostname 。

可能的解决方案：
A）实现唱一个新的kubelet.crt/key对，最好在/var/lib/kubelet/pki之下，并​​设置额外的kubelet标志--tls-cert-file ， --tls-private-key-file 。

B）文档意味着可以按需启用此功能，类似于@ raravena80在这里实现的方式： https : //stackoverflow.com/questions/53212149/x509-certificate-signed-by-unknown-authority-kubeadm/53218524#53218524
除了可能使用Kubernetes CSR / kubeadm命令外。

C） @alexbrand评论

如果可能的话，我认为我们应该使用kubelet中内置的TLS引导工具来请求/旋转服务证书。

D）？

@ kubernetes / sig-cluster-lifecycle
对我来说，这似乎在错误/功能之间的空间中。

另请参阅：
https://github.com/kubernetes/community/pull/602/files

我认为应该在选项B + C之间进行一些操作，因为许多引导令牌客户端cert / CSR逻辑kubelet + kubeadm对此具有共同的逻辑。

让我们总结一下问题：

正如@anitgandhi概述的
第1223章（评论）

这里的kubeadm问题是我们没有将几个标志传递给kubelet：

--tls-cert-file=<some-path>/kubelet.crt
--tls-private-key-file=<some-path>/kubelet.key

如果没有这些标志，则kubelet默认在首次运行时对其服务证书进行自签名，可以使用以下方法进行验证：

sudo openssl verify -verbose -CAfile /var/lib/kubelet/pki/kubelet.crt /var/lib/kubelet/pki/kubelet.crt

使用自签名证书而不是集群CA（ /etc/kubernetes/ca.crt ）签名的证书，诸如度量服务器的部署无法抓取kubelet，因为自签名证书SAN仅包含DNS:hostname 。

可能的解决方案：
A）实现唱一个新的kubelet.crt/key对，最好在/var/lib/kubelet/pki之下，并​​设置额外的kubelet标志--tls-cert-file ， --tls-private-key-file 。

B）文档意味着可以按需启用此功能，类似于@ raravena80在这里实现的方式： https : //stackoverflow.com/questions/53212149/x509-certificate-signed-by-unknown-authority-kubeadm/53218524#53218524
除了可能使用Kubernetes CSR / kubeadm命令外。

C）如@alexbrand所评论

如果可能的话，我认为我们应该使用kubelet中内置的TLS引导工具来请求/旋转服务证书。

D）？

@ kubernetes / sig-cluster-lifecycle
对我来说，这似乎在错误/功能之间的空间中。

另请参阅：
https://github.com/kubernetes/community/pull/602/files

很棒的总结@ neolit123 。 您知道这是否会拖入下一个周期或正在进行中吗？ 主要是因为metrics-server询问每个部署都希望拥有哪个imo;）

@randomvariable提到了另一种解决方法。
从到目前为止的讨论中，我们不愿与群集CA签署kubelet服务证书。 这个话题需要进一步讨论。

/删除帮助

因为尚未选择实施解决方案。

有什么动静吗？ 我反对在kubeadm部署的集群中支持自动扩展功能。

当前的解决方法是关闭kubelet证书的CA检查。

helm install --set 'args={--kubelet-insecure-tls}' --namespace kube-system metrics stable/metrics-serve

并非完全如此，它在设计建议中受阻。
有许多解决方法，但是记录这些方法的工作陷入了停顿：
https://github.com/kubernetes/kubeadm/issues/1602

--kubelet-insecure-tls

对于所有用户而言，这可能不是理想的选择。

闲置90天后，问题变得陈旧。
使用/remove-lifecycle stale将问题标记为新问题。
再过30天不活动后，陈旧的问题就会消失，并最终关闭。

如果现在可以安全解决此问题，请使用/close进行关闭。

将反馈发送到sig-testing，kubernetes / test-infra和/或fejta 。
/ lifecycle stale

/生命周期冻结

遇到这个确切的问题，使用kubeadm创建v1.18.2集群。

设置指标服务器时，如果没有设置它的kubelet-insecure-tls标志，或者为Kublet“带外”颁发证书，并使用kubernetes CA对其进行签名，则该服务器不起作用。

我考虑过重新使用kubelet客户端证书，但这当然是颁发给CN = system:node:nodename且没有SAN。 我确实对其进行了测试，尽管当然会更改错误以表明这一点。 如果将节点名作为使用者的备用名，同一证书可以同时用作服务器/客户端吗？ 但是我猜想为服务器/客户端使用单独的证书会更合适吗？

/删除生命周期已冻结

/生命周期冻结

它已冻结，因此漫游器不会解决问题。

如果将节点名作为使用者的备用名，同一证书可以同时用作服务器/客户端吗？

从理论上讲，除非kubelet对其进行了验证-例如“客户端证书不得具有SAN”。

但是我猜想为服务器/客户端使用单独的证书会更合适吗？

即使在似乎可以避免的情况下，也通常将它们分开使用。 kubelet / auth {z | n}维护者不太可能会更改此详细信息。

嘿。 做了更多的diggin。 Kubelet配置选项serverTLSBootstrap: true实际上可以为服务证书创建CSR。 但是，它没有得到批准。 哪个可以吗？

设置rotateCertificates: true和serverTLSBootsrap: true然后批准服务证书的CSR似乎是最简单的方法。 要求/签发的服务证书的价格为O = system:nodes, CN = system:node:<nodename> ，主题备用名称的价格为DNS: <nodename>, IP Address: <node IP address>

应该至少在kubeadm启用serverTLSBootstrap配置选项，以便批准服务器证书很容易吗？ 甚至kubeadm也可以批准？

嘿。 做了更多的diggin。 Kubelet配置选项serverTLSBootstrap: true实际上可以为服务证书创建CSR。 但是，它没有得到批准。 哪个可以吗？

设置rotateCertificates: true和serverTLSBootsrap: true然后批准服务证书的CSR似乎是最简单的方法。 要求/签发的服务证书的价格为O = system:nodes, CN = system:node:<nodename> ，主题备用名称的价格为DNS: <nodename>, IP Address: <node IP address>

应该至少在kubeadm启用serverTLSBootstrap配置选项，以便批准服务器证书很容易吗？ 甚至kubeadm也可以批准？

不确定安全性实现，但您可以将serverTLSBootstrap与此操作符结合使用以自动批准CSR https://github.com/kontena/kubelet-rubber-stamp

应该至少在kubeadm启用serverTLSBootstrap配置选项，以便批准服务器证书很容易吗？ 甚至kubeadm也可以批准？

kubeadm不是守护程序，因此kubeadm无法进行批准。 它必须部署一个控制器/操作员来为用户进行管理。 也许在将来。

证书API应该很快就会在Google Analytics（分析）中使用，希望我们将有一种更好的方法来在k8s中进行管理。 请注意：
https://github.com/kubernetes/enhancements/issues/267
（但我不清楚我们最终会得到什么...）

我们还有其他选择的想法。 但是，如果所有这些都试图解决度量服务器问题，那么您最好使用https://github.com/brancz/kube-rbac-proxy ，它可以对对kubelet的MS请求执行SAR。 不幸的是，这还没有在我们这边得到证明：
https://github.com/kubernetes/kubeadm/issues/1602

@ neolit123我至少在尝试在kubeadm和“艰苦的方式”集群上建立指标服务器以获取学习经验时开始研究它。 当然，最简单的方法是用--kubelet-insecure-tls标记MS，但我真的很想知道如何以安全的方式修复它，然后才对该问题感兴趣。 🙂

现在，对我来说将serverTLSbootstrap标志添加到kubelet配置并手动批准证书已经足够容易了。 我注意到它的一个缺点，那就是在批准证书之前，您无法与节点上的Pod进行完全交互。 （例如，kubectl exec在批准之前无法在节点上运行的Pod上运行命令）

我也会关注增强功能问题。 谢谢。

令人遗憾的是，对于看起来足够成熟的kubeadm，kubeletet cert的开箱即用结果是自签名的，许多人选择kubelet-insecure-tls作为指标服务器，而不是正确地做事等等：(

这是一个复杂的问题。

请试试：
https://github.com/kontena/kubelet-rubber-stamp
或者
https://github.com/brancz/kube-rbac-proxy
解决方法

这是一个复杂的问题。

请试试：
https://github.com/kontena/kubelet-rubber-stamp
或者
https://github.com/brancz/kube-rbac-proxy
解决方法

实际上https://github.com/kontena/kubelet-rubber-stamp效果很好，而且imo似乎是一种更正确的解决方案，而不是代理。

步骤1：
添加
serverTLSBootstrap: true到每个/var/lib/kubelet/config.yaml的结尾

第2步：
部署kubelet-rubber-stamp

service_account.yaml
role.yaml
role_binding.yaml
operator.yaml

第三步：
编辑指标服务器部署并删除--kubelet-insecure-tls

结果：

kubectl get csr
NAME        AGE   SIGNERNAME                      REQUESTOR          CONDITION
csr-7dvsx   31m   kubernetes.io/kubelet-serving   system:node:u-02   Approved,Issued
csr-d6rvm   31m   kubernetes.io/kubelet-serving   system:node:u-03   Approved,Issued
csr-szblz   31m   kubernetes.io/kubelet-serving   system:node:u-01   Approved,Issued
csr-zjfgj   31m   kubernetes.io/kubelet-serving   system:node:u-04   Approved,Issued

嘿，只是添加到该@vainkop
在最初的kubeadm init创建集群的过程中，您还应该能够传递KubeletConfiguration API对象文件来设置serverTLSBootstrap

kubeadm-config.yaml
api版本：kubeadm.k8s.io/v1beta2
种类：ClusterConfiguration

...

apiVersion：kubelet.config.k8s.io/v1beta1
种类：KubeletConfiguration
serverTLSBootstrap：true

`kubeadm init --config=kubeadm-config.yaml`

Then all kubelet's will automatically be set up using the `serverTLSBootstrap` flag.

To get the CSRs

kubectl获取csr
姓名年龄签名人姓名要求条件
csr-2qkdw 2m1s kubernetes.io/kube-apiserver-client-kubelet system：bootstrap ：fcufbo已批准，已发布
csr-9wvgt 114s kubernetes.io/kubelet-serving system：node ：worker-1待定
csr-lz97v 4m58s kubernetes.io/kubelet-serving system：node ：master-1待定
csr-rsdsp 4m59s kubernetes.io/kube-apiserver-client-kubelet系统：node ：master-1已批准，已发布
csr-wgxqs 4m49s kubernetes.io/kubelet-serving system：node ：master-1待定

Then either approve them manually or deploy https://github.com/kontena/kubelet-rubber-stamp which approves them automatically. I just tried it with kubelet-rubber-stamp and it works great.

Also I did not seem to need to restart the kubelet's this way, they picked up their certificates as soon as I approvde the CSR, but a caveat is that the kublet's have NO cert until the CSR is approved, it does not get a self signed certificate first.

kubectl证书批准csr-ab123＃或部署橡皮图章！

kubectl获取csr
姓名年龄签名人姓名要求条件
csr-9wvgt 3m kubernetes.io/kubelet-serving system：node ：worker-1已批准，已发布
...
```

顺便说一句，这里似乎发生了另一件事，那就是主节点似乎两次创建了它的CSR。 （至少我尝试过两次）

但是正如@nijave在上面的评论中所说，我不确定使用橡胶防震垫对安全性有何影响。

@allir ， @vainkop到目前为止，我可以看到kubelet-rubber-stamp仅验证CSR的通用名称是否与请求者名称匹配，而不验证kubelet请求的其他主机名和IP地址是否有效。 这意味着有权访问kubelet客户端证书的攻击者可以为几乎任何域名或IP地址创建证书。 然后，配置为信任根CA的所有客户端将接受此证书。
当然，要验证对给定kubelet有效的主机名和IP地址很困难，因为当前没有权限可以确认允许kubelet请求什么。 例如，在API服务器上使用节点对象是不够的，因为kubelet可以无限制地更新对象。

嘿，只是添加到该@vainkop
在最初的kubeadm init创建集群的过程中，您还应该能够传递KubeletConfiguration API对象文件来设置serverTLSBootstrap
kubeadm init --config=kubeadm-config.yaml
然后将使用serverTLSBootstrap标志自动设置所有kubelet。

或对于使用Ansible的现有K8s设置，它可以是：

  tasks:
    - name: Insert a line at the end of /var/lib/kubelet/config.yaml
      lineinfile:
        path: /var/lib/kubelet/config.yaml
        line: 'serverTLSBootstrap: true'

+重启小玩意

哇，我很高兴发现了这个问题，而且不是一个人愿意采取这种正确的方法。 :)

现在，让我分享我对这个问题的想法（如果我错了，请纠正我） ：

首先，我对原始问题的看法是：
当前，kubeadm默认情况下对所有kubelet启用webhook身份验证，因此，即使指定了--kubelet-insecure-tls选项，kubelet仍可以毫无问题地验证客户端证书的传入连接。
另一方面，metrics-server没有机会验证特定的kubelet证书，因为它在节点上是自签名的。

为指标服务器使用--kubelet-insecure-tls可能风险：
尽管kubelet数据在某种程度上是安全的，但是如果没有成功的Webhook身份验证，就永远不会将其提供给指标服务器。
理论上，有人可能会破坏服务器IP或主机名并提供错误的统计信息。 但是，为了建立连接，metricserver使用的是通过kube-apiserver为节点指定的IP地址和主机名，因此攻击者需要首先破解API服务器，DNS或节点IP地址。

一点观察：
指标服务器不是直接访问kubelet的单一服务。 Kube-apiserver也会这样做，以读取容器日志或在其上执行shell。 好的问题是kube-apiserver如何确保它与特定kubelet建立连接，而没有有关颁发证书的CA的任何信息？
在这种情况下，它的行为与带有--kubelet-insecure-tls选项的指标服务器不一样吗？

可能的解决方案：
如今，Webhooks和API聚合在Kubernetes中非常流行。 通过生成自己的CA和crt /密钥对，它们的行为都相似。 CA哈希还存储在特定资源中，以向kube-apiserver提供有关其可以信任的证书的信息。

例如：

• APIServices将相关的CA哈希存储在其apiservices.apiregistration.k8s.io资源中：

  spec:
  caBundle: <ca-hash>
  

• Webhooks将相关的CA哈希存储在其validatingwebhookconfigurations.admissionregistration.k8s.io和mutatingwebhookconfigurations.admissionregistration.k8s.io资源中：

  webhooks:
  - clientConfig:
    caBundle: <ca-hash>
  

对我来说，很明显每个节点资源的caBundle中应该有类似的spec ，其中kubelet可以注册自己的CA以使用其客户端证书进行服务：

spec:
  caBundle: <ca-hash>

metris-server和kube-apiserver都应使用这些证书来验证和信任与kubelet的连接。

感谢@ kfox1111之前曾表达过类似的想法https://github.com/kubernetes/kubeadm/issues/1223#issuecomment -460854312

好的问题是kube-apiserver如何确保它与特定kubelet建立连接，而没有有关颁发证书的CA的任何信息？
在这种情况下，它的行为与带有--kubelet-insecure-tls选项的指标服务器不一样吗？

为了回答这个问题，我可以在这里引用@luxas ：

正确，我们无法验证从api服务器到kubelet服务器的连接，因为每个kubelet都有自己的自签名证书。 我们可能会考虑在将来手动批准带有kubelet服务证书的流程，但目前默认情况下尚不安全。

来自https://github.com/kubernetes/kubeadm/issues/118#issuecomment -407498529

希望有一天能解决

[root<strong i="6">@jenkins</strong> metrics-server]# kubectl -n kube-system logs -f metrics-server-6955d88db9-lftlz
I1120 08:23:09.094132       1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController
I1120 08:23:09.094234       1 shared_informer.go:240] Waiting for caches to sync for RequestHeaderAuthRequestController
I1120 08:23:09.094270       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1120 08:23:09.094279       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1120 08:23:09.094307       1 configmap_cafile_content.go:202] Starting client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1120 08:23:09.094315       1 shared_informer.go:240] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1120 08:23:09.095064       1 dynamic_serving_content.go:130] Starting serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key
I1120 08:23:09.095207       1 secure_serving.go:197] Serving securely on [::]:4443
I1120 08:23:09.095259       1 tlsconfig.go:240] Starting DynamicServingCertificateController
I1120 08:23:09.194453       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file 
I1120 08:23:09.194660       1 shared_informer.go:247] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file 
I1120 08:23:09.194455       1 shared_informer.go:247] Caches are synced for RequestHeaderAuthRequestController 
E1120 08:23:10.420643       1 server.go:132] unable to fully scrape metrics: [unable to fully scrape metrics from node k8s-master3: unable to fetch metrics from node k8s-master3: Get "https://10.39.140.250:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.250 because it doesn't contain any IP SANs, unable to fully scrape metrics from node k8s-master1: unable to fetch metrics from node k8s-master1: Get "https://10.39.140.248:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.248 because it doesn't contain any IP SANs, unable to fully scrape metrics from node k8s-master2: unable to fetch metrics from node k8s-master2: Get "https://10.39.140.249:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.249 because it doesn't contain any IP SANs, unable to fully scrape metrics from node k8s-node1: unable to fetch metrics from node k8s-node1: Get "https://10.39.140.251:10250/stats/summary?only_cpu_and_memory=true": x509: cannot validate certificate for 10.39.140.251 because it doesn't contain any IP SANs]
I1120 08:23:33.874949       1 requestheader_controller.go:183] Shutting down RequestHeaderAuthRequestController
I1120 08:23:33.874978       1 configmap_cafile_content.go:223] Shutting down client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1120 08:23:33.874993       1 configmap_cafile_content.go:223] Shutting down client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1120 08:23:33.875019       1 tlsconfig.go:255] Shutting down DynamicServingCertificateController
I1120 08:23:33.875026       1 dynamic_serving_content.go:145] Shutting down serving-cert::/tmp/apiserver.crt::/tmp/apiserver.key
I1120 08:23:33.875041       1 secure_serving.go:241] Stopped listening on [::]:4443

这个问题没有消息吗？ 我也有对此感兴趣的解决方案。

我们在这里记录解决方法：
https://github.com/kubernetes/website/pull/27071
https://github.com/kubernetes/kubeadm/issues/1602

我们可以保留此问题的公开性，但是由于默认情况下要求使用kubeadm部署签名者的复杂性，我们不太可能很快就进行此更改。