k8s 证书相关

2024-01-20 18:35:58

本文介绍的是k8s证书介绍以及通过kubeadm 安装的集群的证书更新方式。

证书默认的安装位置

/etc/kubernetes/pki

涉及到的证书

各个证书介绍

Kubernetes 集群根证书

其他证书都是由此根证书签发的

/etc/kubernetes/pki/ca.crt

/etc/kubernetes/pki/ca.key

由此根证书签发的证书有:

1,kube-apiserver 组件持有的服务端证书

/etc/kubernetes/pki/apiserver.crt

/etc/kubernetes/pki/apiserver.key

2,kubelet 组件持有的客户端证书

/etc/kubernetes/pki/apiserver-kubelet-client.crt

/etc/kubernetes/pki/apiserver-kubelet-client.key

kubelet 上一般不会明确指定服务端证书, 而是只指定 ca 根证书, 让 kubelet 根据本地主机信息自动生成服务端证书并保存到配置的cert-dir文件夹中。

3、汇聚层(aggregator)证书

/etc/kubernetes/pki/front-proxy-ca.crt

/etc/kubernetes/pki/front-proxy-ca.key

由此根证书签发的证书只有一组:

1,代理端使用的客户端证书, 用作代用户与 kube-apiserver 认证

/etc/kubernetes/pki/front-proxy-client.crt

/etc/kubernetes/pki/front-proxy-client.key

etcd 集群根证书

/etc/kubernetes/pki/etcd/ca.crt

/etc/kubernetes/pki/etcd/ca.key

由此根证书签发机构签发的证书有:

1,etcd server 持有的服务端证书

/etc/kubernetes/pki/etcd/server.crt

/etc/kubernetes/pki/etcd/server.key

2,peer 集群中节点互相通信使用的客户端证书

/etc/kubernetes/pki/etcd/peer.crt

/etc/kubernetes/pki/etcd/peer.key

3,pod 中定义 Liveness 探针使用的客户端证书

/etc/kubernetes/pki/etcd/healthcheck-client.crt

/etc/kubernetes/pki/etcd/healthcheck-client.key

4,配置在 kube-apiserver 中用来与 etcd server 做双向认证的客户端证书

/etc/kubernetes/pki/apiserver-etcd-client.crt

/etc/kubernetes/pki/apiserver-etcd-client.key

kubeconfig 介绍

kubeconfig 是一类配置文件的总称，这类配置文件是k8s里面的组件访问集群做认证的配置文件，通常有 admin.conf controller-manager.conf kubelet.conf scheduler.conf。

admin.conf 里面配置的是最高权限，通常作为kubectl 的配置文件，配置在~/.kube/config 里面。

controller-manager.conf kubelet.conf scheduler.conf 顾名思义是对应的controller-manager、kubelet、scheduler 等组件访问集群是的配置文件，他们使用各自权限的用户，具有不同的权限。

证书更新

集群的根证书默认都是10年有效期，但是其他的证书例如apiserver etcd 的证书都是1年有效期，所以在不更改源码的情况下就只能每年进行一次证书更新，否则我们就无法通过kubectl 来管理集群，现象就是当证书过期的时候我们执行kubectl任何命令都会报错如下：

Unable to connect to the server: x509: certificate has expired or is not yet valid

当然理论上像controller-manager scheduler等组建也不能正常与apiserver通讯了，所以就无法实现调度和管理集群了。但是有一个庆幸的地方是集群上正在运行的服务不受影响，简单说就是这些服务可以正常访问，只是我们无法再通过kubectl 等操作去进行更新pod 等管理命令了。

证书更新操作

k8s集群版本1.15 +

操作之前，请务必先备份/etc/kubernetes目录，以备不时之需

0.先查看哪些证书过期了

kubeadm alpha certs check-expiration

1.更新/etc/kubernetes/pki目录下的所有证书（不包含ca证书）

kubeadm alpha certs renew all

注意如果上述操作失败，是因为在kubeadm命令升级master证书时，它也会默认从网上读取一个stable.txt的文件。如果无法访问外网那么就需要指定一个配置文件。

kubeadm alpha certs renew all --config=/home/ubuntu/cluster.yaml

clusterl.yaml 可以通过kubeadm config view > cluster-n.yaml 生成，但是在证书过期后就无法生成了，这需要在证书过期之前生成这个文件

手动写配置文件

apiServer:
extraArgs:
authorization-mode: Node,RBAC
timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: 192.168.1.200:8443　　#apiserver 地址，注意如果master多节点这个地址就是代理服务地址和端口。
controllerManager: {}
dns:
type: CoreDNS
etcd:
local:
dataDir: /var/lib/etcd
imageRepository: registry.sensedeal.wiki:8443/sp
kind: ClusterConfiguration
kubernetesVersion: v1.18.3
networking:
dnsDomain: cluster.local
podSubnet: 10.244.0.0/16　　　　　　#pod 网段，根据实际情况填写
serviceSubnet: 10.96.0.0/16　　　　#svc 网段，根据实际情况填写
scheduler: {}

整个过程不仅更新了证书也更新了kubeconfig 等文件，然后就是把admin.conf 复制到～/.kube/config

如果是多个master 节点，需要把证书和kubeconfig 复制到其他节点

最后要重启相关容器

docker ps |grep -E 'k8s_kube-apiserver|k8s_kube-controller-manager|k8s_kube-scheduler|k8s_etcd_etcd'  | awk -F '''{print $1}' |xargs docker restart

其他版本集群更新证书

网上很多教程都是逐个更新证书的命令，但是此命令在1.15后已经废弃了，所以要注意版本问题。

上面新版本的证书更新命令并未更新ca.crt ca.key sa.crt sa.key ，如果是其他旧版的时候也要注意不要更新这两个证书。原因如下：

1、因为更新了ca证书，集群节点就需要手工操作，才能让集群正常(会涉及重新join)。

2、由于service account的密钥是以rsa密钥对形式生成，所以没有过期时间。如无必要，千万不要生成重新生成sa密钥。因为sa密钥关联到一切系统pod内的进程访问api server时的认证。

如果更新了sa，则需要先重新生成这些pod加截的token，再删除这些pod之后，重新加载token文件。经过测试，这些系统级pod包括但不限于kube-proxy,flannel,kubenetes-dashboard, kube-stat-metricst等所有用到sa认证的pod。

证书过期监控

本人使用的是kube-prometheus ，默认是带有监控证书的功能的，但是貌似只是在过期前的24h 之前发送报警，报警信息如戏，注意识别

关于apiserver 的认证

API Server的authenticating环节支持多种身份校验方式：client cert、bearer token、static password auth等，这些方式中有一种方式通过authenticating（Kubernetes API Server会逐个方式尝试），那么身份校验就会通过。一旦API Server发现client发起的request使用的是service account token的方式，API Server就会自动采用signed bearer token方式进行身份校验。而request就会使用携带的service account token参与验证。该token是API Server在创建service account时用API server启动参数：–service-account-key-file的值签署(sign)生成的。如果–service-account-key-file未传入任何值，那么将默认使用–tls-private-key-file的值，即API Server的私钥（server.key）。

通过authenticating后，API Server将根据Pod username所在的group：system:serviceaccounts和system:serviceaccounts:(NAMESPACE)的权限对其进行authority 和admission control两个环节的处理。在这两个环节中，cluster管理员可以对service account的权限进行细化设置

Serveice Account秘钥

这组的密钥对儿仅提供给 kube-controller-manager 使用. kube-controller-manager 通过 sa.key 对 token 进行签名, master 节点通过公钥 sa.pub 进行签名的验证.

通过kubeadm 安装的集群，kube-proxy ,coredns ，flannel 等都是以pod 形式运行，所以他们访问apiserver 都是通过相应的sa 方式认证的。

码农公寓