kubelet 启动时的动作流程
- 寻找kubeconifg文件
- 从kubeconfig 文件中获取API SERVER的地址和端口以及访问api sever的凭证(通常情况下,凭证为ca签名后的证书)
- 使用凭证与 api server 通信
TLS bootstrapping 介绍
TLS bootstrapping 是用来简化管理员配置kubelet 与 apiserver 双向加密通信的配置步骤的一种机制。
kubelet 和 api server 要双向加密通信，集群管理员需要做如下配置。
-
创建/获取 ca key 和 ca 证书
-
将ca证书分发到所有 master 和node 节点
-
对每个node 的kubelet 生成 对应的key 和 客户端证书 - 强烈推荐每个kubelet的证书使用一个全局唯一的CN
-
用CA 证书对 kubelet 客户端证书进行签名.
-
分发对应的 (key 和 签名证书)对到对应的kubelet(因为全局唯一,所以每个证书也唯一,也可以所有kubelet 统一使用一个客户端证书和签名证书.此时需要设置证书中的host为所有的kubelet node ip 或主机名.)
TLS bootstrapping 配置
TLS bootstrapping 用于自动化从第三步开始及之后的操作.
TLS bootstrapping 初始化过程介绍
-
kubelet开始
-
kubelet发现没有kubeconfig文件
-
kubelet搜索并找到一个
bootstrap-kube.config文件 -
kubelet读取它的引导文件，检索API服务器的URL和一个有限的使用“token”
-
kubelet连接到API服务器，使用令牌进行身份验证
-
kubelet现在拥有有限的凭据来创建和检索证书签名请求(CSR)
-
kubelet为自己创建了CSR
-
CSR是通过以下两种方式之一获得批准的:
- 如果配置成功，kube-controller-manager将自动批准CSR
- 如果配置成功，外部进程(可能是一个人)将使用Kubernetes API或通过kubectl批准CSR
-
证书是为kubelet创建的
-
证书颁发给kubelet
-
kubelet 查找并读取证书
-
kubelet使用密钥和签名证书创建一个适当的kubeconfig
-
kubelet 开始正常工作
-
可选:如果配置好了，kubelet会在证书快到期时自动请求续订证书
-
根据配置自动或手动批准和颁发更新的证书
配置TLS BOOTSTRAPPING 所涉及到的组件及资源
- API SERVER
- KUBELET
- KUBE-CONTROLLER-MANAGER
- clusterrolebinding 和 clusterrole
前置条件
假设你已经拥有了CA key 放在/var/lib/kubernetes/ca-key.pem 及CA 证书放在/var/lib/kubernetes/ca.pem
api server 配置
api server 需要满足的条件如下
- 设置CA证书
- 认证 boostrapping kubelet 到 system:bootstrappers group
- 授权 bootstrapping kubelet 创建 证书签名请求
设置 ca 证书
api server 启动参数中添加
--client-ca-file=/var/lib/kubernetes/ca.pem
认证 boostrapping kubelet 到 system:bootstrappers group
api server 启动参数中添加
--enable-bootstrap-token-auth=true
token authentication file
生成token
head -c 16 /dev/urandom | od -An -t x | tr -d ' '
生成出来的token为 02b50b05283e98dd0fd71db496ef01e8
也可以使用kubeadm 来生成token
kubeadm token create --description kubelet-bootstrap-token --groups system:bootstrappers --kubeconfig ~/.kube/config(master的 kubeconfig)
编写token file: bootstrapping-token, 内容为
02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:bootstrappers"
前三段的内容可以是任意值,最后一个组是固定的值,当然,token 不能随便乱写,必须通过杠杆的命令生成
token的格式为token,user,uid,"group1,group2,group3"
设置 api server 使用 token file
--token-auth-file=FILENAME
授权kubelet创建CSR
bootstrapping-clusterrolebinding.yaml
# enable bootstrapping nodes to create CSR
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: create-csrs-for-bootstrapping
subjects:
- kind: Group
name: system:bootstrappers
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: system:node-bootstrapper
apiGroup: rbac.authorization.k8s.io
kubectl apply -f bootstrapping-clusterrolebinding.yaml
kube-controller-manager 配置
--cluster-signing-cert-file="/var/lib/kubernetes/ca.pem" --cluster-signing-key-file="/var/lib/kubernetes/ca-key.pem"
--experimental-cluster-signing-duration 可以设置签名的过期时长
两组授权
nodeclient:如果一个节点正在为一个节点创建一个新证书，那么它还没有证书。它使用上面列出的一个令牌进行身份验证，因此是组system:bootstrappers的一部分。
selfnodeclient:如果一个节点正在更新它的证书，那么它已经拥有一个证书(根据定义)，它连续使用该证书作为组system:nodes的一部分进行身份验证。
同意csr 签名的权限授权
# Approve all CSRs for the group "system:bootstrappers"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: auto-approve-csrs-for-group
subjects:
- kind: Group
name: system:bootstrappers
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: system:certificates.k8s.io:certificatesigningrequests:nodeclient
apiGroup: rbac.authorization.k8s.io
同意csr 证书更新的权限授权
# Approve renewal CSRs for the group "system:nodes"
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: auto-approve-renewals-for-nodes
subjects:
- kind: Group
name: system:nodes
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient
apiGroup: rbac.authorization.k8s.io
kubelet 配置
前置条件
- 存储它生成的密钥和证书的路径(可选，可以使用缺省值)
- 指向尚未存在的“kubeconfig”文件的路径;它将把引导的配置文件放在这里
-
kubeconfig文件的路径，该文件尚不存在;它将把引导的配置文件放在这里 - bootstrap kubeconfig 文件的路径，用于为服务器和引导凭据提供URL，例如引导令牌
- 可选:循环续签证书的指令
bootstrap kubeconfig应该位于kubelet可用的路径中，例如/var/lib/kubelet/bootstrap-kubeconfig
bootstrap-kubeconfig 的内容
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority: /var/lib/kubernetes/ca.pem
server: https://my.server.example.com:6443
name: bootstrap
contexts:
- context:
cluster: bootstrap
user: kubelet-bootstrap
name: bootstrap
current-context: bootstrap
preferences: {}
users:
- name: kubelet-bootstrap
user:
token: 07401b.f395accd246ae52d
令牌的格式并不重要，只要它符合kube-apiserver的期望即可。在上面的例子中，我们使用了引导令牌。如前所述，可以使用任何有效的身份验证方法，而不仅仅是令牌。
创建bootstrap-kubeconfig
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-cluster bootstrap --server='https://my.server.example.com:6443' --certificate-authority=/var/lib/kubernetes/ca.pem
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-credentials kubelet-bootstrap --token=07401b.f395accd246ae52d
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig set-context bootstrap --user=kubelet-bootstrap --cluster=bootstrap
kubectl config --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig use-context bootstrap
指定kubelet 使用 bootstrap kube config
--bootstrap-kubeconfig="/var/lib/kubelet/bootstrap-kubeconfig" --kubeconfig="/var/lib/kubelet/kubeconfig"
客户端和服务端证书
上述所有内容都与kubelet客户机证书有关，特别是kubelet用于对kube-apiserver进行身份验证的证书。
kubelet还可以使用服务端证书。kubelet本身为某些特性公开一个https端点。为了确保这些，kubelet可以做以下工作之一:
-
通过
--tls-private-key-file和tls-cert-file标志使用提供的密钥和证书 -
如果没有提供密钥和证书，则创建自签名密钥和证书
-
通过CSR API从集群服务器请求服务证书
缺省情况下，TLS boostrap 提供的客户端证书只针对客户端身份验证进行签名，因此不能用作服务证书或服务器身份验证。
证书续期
Certubernetes v1.8和更高版本的kubelet实现了beta特性，支持客户端和/或服务证书的续期。这些可以通过kubelet上的RotateKubeletClientCertificate和RotateKubeletServerCertificate特性标志启用，并且默认情况下是启用的。
RotateKubeletClientCertificate在现有凭证过期时创建新的csr，从而使kubelet其续期客户机证书。要启用此功能，请将以下标志传递给kubelet:
--rotate-certificates
RotateKubeletServerCertificate使kubelet在引导其客户端凭据之后请求服务证书，并续期该证书。要启用此功能，请将以下标志传递给kubelet:
--rotate-server-certificates
注意:出于安全原因，Kubernetes中实现的CSR批准控制器不批准节点服务证书。要使用RotateKubeletServerCertificate操作符，需要运行自定义批准控制器，或者手动批准服务证书请求。
手动批准
可以在控制器管理的审批流之外批准csr。
签名控制器(signing controller)不会立即对所有证书请求签名。相反，它将等待适当的特权用户将它们标记为“已批准”状态。此流程旨在允许由外部审批控制器(自定义控制器)或在核心控制器(默认实现)中实现的审批控制器处理的自动化审批。然而，集群管理员还可以使用kubectl手动批准证书请求。管理员可以使用kubectl get csr列出csr，并使用kubectl describe csr <name>详细描述csr。管理员可以通过kubectl certificate approve <name> 和 kubectl certificate deny <name>来批准或拒绝CSR
如果文章对您有帮助,请点一下下面的 "喜欢"
网友评论