最好的K8S 安全机制介绍 6 TLS BOOTSTRAPPIN

2019-07-04 本文已影响0人陈sir的知识图谱

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是通过以下两种方式之一获得批准的:
1. 如果配置成功，kube-controller-manager将自动批准CSR
2. 如果配置成功，外部进程(可能是一个人)将使用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

如果文章对您有帮助,请点一下下面的 "喜欢"

最好的K8S 安全机制介绍 6 TLS BOOTSTRAPPIN

kubelet 启动时的动作流程

TLS bootstrapping 介绍

TLS bootstrapping 配置

TLS bootstrapping 初始化过程介绍

配置TLS BOOTSTRAPPING 所涉及到的组件及资源

前置条件

api server 配置

设置 ca 证书

认证 boostrapping kubelet 到 system:bootstrappers group

token authentication file

授权kubelet创建CSR

kube-controller-manager 配置

两组授权

同意csr 签名的权限授权

同意csr 证书更新的权限授权

kubelet 配置

前置条件

创建bootstrap-kubeconfig

客户端和服务端证书

证书续期

手动批准

猜你喜欢

热点阅读