【转】k8s证书详解

最新推荐文章于 2024-01-11 09:00:00 发布
最新推荐文章于 2024-01-11 09:00:00 发布
阅读量817 收藏 3
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_40496191/article/details/117453844
版权

转载于https://www.cnblogs.com/centos-python/articles/11043570.html

官方文档参考：https://kubernetes.io/docs/setup/certificates/

文章目录

1、证书套数

1.1 etcd证书套数

  1. Etcd对外提供服务，要有一套etcd server证书
  2. Etcd各节点之间进行通信，要有一套etcd peer证书
  3. Kube-APIserver访问Etcd，要有一套etcd client证书

1.2 kubernetes证书套数

  1. Kube-APIserver对外提供服务，要有一套kube-apiserver server证书
  2. kube-scheduler、kube-controller-manager、kube-proxy、kubelet和其他可能用到的组件，需要访问kube-APIserver，要有一套kube-APIserver client证书
    先从Etcd算起：
  3. kube-controller-manager要生成服务的service account，要有一对用来签署service account的证书(CA证书)
  4. kubelet对外提供服务，要有一套kubelet server证书
  5. kube-APIserver需要访问kubelet，要有一套kubelet client证书
    加起来共8套

2、证书问题

2.1 为什么证书是用“套”

同一个套内的证书必须是用同一个CA签署的，签署不同套里的证书的CA可以相同，也可以不同。例如，所有etcd server证书需要是同一个CA签署的，所有的etcd peer证书也需要是同一个CA签署的，而一个etcd server证书和一个etcd peer证书，完全可以是两个CA机构签署的，彼此没有任何关系。这算两套证书。

2.2 为什么同一个“套”内的证书必须是同一个CA签署的

原因在验证这些证书的一端。因为在要验证这些证书的一端，通常只能指定一个Root CA。这样一来，被验证的证书自然都需要是被这同一个Root CA对应的私钥签署，不然不能通过认证。

其实实际上，使用一套证书（都使用一套CA来签署）一样可以搭建出K8S，一样可以上生产，但是理清这些证书的关系，在遇到因为证书错误，请求被拒绝的现象的时候，不至于无从下手，而且如果没有搞清证书之间的关系，在维护或者解决问题的时候，贸然更换了证书，弄不好会把整个系统搞瘫。

2.3 TLS bootstrapping 简化kubelet证书制作

Kubernetes1.4版本引入了一组签署证书用的API。这组API的引入，使我们可以不用提前准备kubelet用到的证书。

官网地址：https://kubernetes.io/docs/tasks/tls/certificate-rotation/

每个kubelet用到的证书都是独一无二的，因为它要绑定各自的IP地址，于是需要给每个kubelet单独制作证书，如果业务量很大的情况下，node节点会很多，这样一来kubelet的数量也随之增加，而且还会经常变动（增减Node）kubelet的证书制作就成为一件很麻烦的事情。使用TLS bootstrapping就可以省事儿很多。

工作原理：Kubelet第一次启动的时候，先用同一个bootstrap token作为凭证。这个token已经被提前设置为隶属于用户组system：bootstrappers，并且这个用户组的权限也被限定为只能用来申请证书。 用这个bootstrap token通过认证后，kubelet申请到属于自己的两套证书（kubelet server、kube-apiserver client for kubelet），申请成功后，再用属于自己的证书做认证，从而拥有了kubelet应有的权限。这样一来，就去掉了手动为每个kubelet准备证书的过程，并且kubelet的证书还可以自动轮替更新

参考文档：

https://mritd.me/2018/01/07/kubernetes-tls-bootstrapping-note/

https://www.jianshu.com/p/bb973ab1029b

2.4kubelet证书为何不同

这样做是一个为了审计，另一个为了安全。 每个kubelet既是服务端（kube-apiserver需要访问kubelet），也是客户端（kubelet需要访问kube-apiserver），所以要有服务端和客户端两组证书。

服务端证书需要与服务器地址绑定，每个kubelet的地址都不相同，即使绑定域名也是绑定不同的域名，故服务端地址不同

客户端证书也不应相同，每个kubelet的认证证书与所在机器的IP绑定后，可以防止一个kubelet的认证证书泄露以后，使从另外的机器上伪造的请求通过验证。

安全方面，如果每个node上保留了用于签署证书的bootstrap token，那么bootstrap token泄漏以后，是不是可以随意签署证书了？安全隐患非常大。所以，kubelet启动成功以后，本地的bootstrap token需要被删除。

三、需要准备的证书和组件

3.1 准备的证书

虽然可以用多套证书，但是维护多套CA实在过于繁杂，这里还是用一个CA签署所有证书。
admin.pem
ca.-key.pem
ca.pem
admin-key.pem
admin.pem
kube-scheduler-key.pem
kube-scheduler.pem
kube-controller-manager-key.pem
kube-controller-manager.pem
kube-proxy-key.pem
kube-proxy.pem
kubernetes-key.pem
kubernetes.pem

3.2 准备的证书组件

etcd：使用 ca.pem kubernetes-key.pem kubernetes.pem
kube-apiserver：使用 ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem
kubelet：使用 ca.pem
kube-proxy：使用 ca.pem kube-proxy-key.pem kube-proxy.pem
kubectl：使用 ca.pem admin-key.pem、admin.pem
kube-controller-manager：使用 ca-key.pem ca.pem kube-controller-manager-key.pem kube-controller-manager.pem
kube-scheduler: 使用 kube-scheduler-key.pem kube-scheduler.pem
我们使用CFSSL来制作证书，它是cloudflare开发的一个开源的PKI工具，是一个完备的CA服务系统，可以签署、撤销证书等，覆盖了一个证书的整个生命周期，后面只用到了它的命令行工具。

注：一般情况下，K8S中证书只需要创建一次，以后在向集群中添加新节点时只要将/etc/kubernetes/ssl目录下的证书拷贝到新节点上即可。

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x cfssl_linux-amd64 cfssljson_linux-amd64 cfssl-certinfo_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
mv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo

四、正式制作证书

4.1 CA证书

4.1.1 创建CA证书

创建证书配置文件

vim ca-config.json
{
“signing”: {
“default”: {
“expiry”: “87600h”
},
“profiles”: {
“kubernetes”: {
“usages”: [
“signing”,
“key encipherment”,
“server auth”,
“client auth”
],
“expiry”: “87600h”
}
}
}
}
字段说明：

ca-config.json：可以定义多个 profiles，分别指定不同的过期时间、使用场景等参数；后续在签名证书时使用某个 profile；

signing：表示该证书可以签名其他证书；生成的ca.pem证书中 CA=TRUE；

server auth：表示client可以用该 CA 对server提供的证书进行验证；

client auth：表示server可以用该CA对client提供的证书进行验证；

expiry：过期时间

4.1.2 创建CA证书签名请求文件

vim ca-csr.json

{
“CN”: “kubernetes”,
“key”: {
“algo”: “rsa”,
“size”: 2048
},
“names”: [
{
“C”: “CN”,
“ST”: “BeiJing”,
“L”: “BeiJing”,
“O”: “k8s”,
“OU”: “System”
}
],
“ca”: {
“expiry”: “87600h”
}
}
字段说明：

“CN”：Common Name，kube-apiserver 从证书中提取该字段作为请求的用户名 (User Name)；浏览器使用该字段验证网站是否合法；

“O”：Organization，kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group)

4.1.3 生成CA证书和私钥

cfssl gencert -initca ca-csr.json | cfssljson -bare ca
ls | grep ca
ca-config.json
ca.csr
ca-csr.json
ca-key.pem
ca.pem
其中ca-key.pem是ca的私钥，ca.csr是一个签署请求，ca.pem是CA证书，是后面kubernetes组件会用到的RootCA。

4.2 kubernetes证书

在创建这个证书之前，先规划一下架构
k8s-master1 10.211.55.11
k8s-master2 10.211.55.12
k8s-master3 10.211.55.13
etcd01 10.211.55.11
etcd02 10.211.55.12
etcd03 10.211.55.13
VIP 10.211.55.8

4.2.1 创建kubernetes证书签名请求文件

vim kubernetes-csr.json
{
“CN”: “kubernetes”,
“hosts”: [
“127.0.0.1”,
“10.211.55.11”,
“10.211.55.12”,
“10.211.55.13”,
“10.211.55.8”,
“10.0.0.1”,
“k8s-master1”,
“k8s-master2”,
“k8s-master3”,
“etcd01”,
“etcd02”,

  "etcd03",
  "kubernetes",
  "kube-api.wangdong.com",
  "kubernetes.default",
  "kubernetes.default.svc",
  "kubernetes.default.svc.cluster",
  "kubernetes.default.svc.cluster.local"
],
"key": {
    "algo": "rsa",
    "size": 2048
},
"names": [
    {
        "C": "CN",
        "ST": "BeiJing",
        "L": "BeiJing",
        "O": "k8s",
        "OU": "system"
    }
]

}
字段说明：

如果 hosts 字段不为空则需要指定授权使用该证书的 IP 或域名列表。

由于该证书后续被 etcd 集群和 kubernetes master 集群使用，将etcd、master节点的IP都填上，同时还有service网络的首IP。(一般是 kube-apiserver 指定的 service-cluster-ip-range 网段的第一个IP，如 10.0.0.1)

三个etcd，三个master，以上物理节点的IP也可以更换为主机名。

4.2.2 生成kubernetes证书和私钥

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
ls |grep kubernetes
kubernetes.csr
kubernetes-csr.json
kubernetes-key.pem
kubernetes.pem

4.3admin证书

4.3.1创建admin证书签名请求文件

vim admin-csr.json
{
“CN”: “admin”,
“hosts”: [],
“key”: {
“algo”: “rsa”,
“size”: 2048
},
“names”: [
{
“C”: “CN”,
“ST”: “BeiJing”,
“L”: “BeiJing”,
“O”: “system:masters”,
“OU”: “system”
}
]
}
说明：

后续 kube-apiserver 使用 RBAC 对客户端(如 kubelet、kube-proxy、Pod)请求进行授权；

kube-apiserver 预定义了一些 RBAC 使用的 RoleBindings，如 cluster-admin 将 Group system:masters 与 Role cluster-admin 绑定，该 Role 授予了调用kube-apiserver 的所有 API的权限；

O指定该证书的 Group 为 system:masters，kubelet 使用该证书访问 kube-apiserver 时 ，由于证书被 CA 签名，所以认证通过，同时由于证书用户组为经过预授权的 system:masters，所以被授予访问所有 API 的权限；

注：这个admin 证书，是将来生成管理员用的kube config 配置文件用的，现在我们一般建议使用RBAC 来对kubernetes 进行角色权限控制， kubernetes 将证书中的CN 字段 作为User， O 字段作为 Group

相关权限认证可以参考下面文章

https://mp.weixin.qq.com/s/XIkQdh5gnr-KJhuFHboNag

4.3.2生成admin证书和私钥

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin
ls | grep admin
admin.csr
admin-csr.json
admin-key.pem
admin.pem

4.4创建kube-proxy证书

4.4.1创建 kube-proxy 证书签名请求文件

vim kube-proxy-csr.json
{
“CN”: “system:kube-proxy”,
“hosts”: [],
“key”: {
“algo”: “rsa”,
“size”: 2048
},
“names”: [
{
“C”: “CN”,
“ST”: “BeiJing”,
“L”: “BeiJing”,
“O”: “k8s”,
“OU”: “system”
}
]
}

说明：

CN 指定该证书的 User 为 system:kube-proxy；

kube-apiserver 预定义的 RoleBinding system:node-proxier 将User system:kube-proxy 与 Role system:node-proxier 绑定，该 Role 授予了调用 kube-apiserver Proxy 相关 API 的权限；

该证书只会被 kubectl 当做 client 证书使用，所以 hosts 字段为空

4.4.2生成kube-proxy证书和私钥

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy
ls |grep kube-proxy
kube-proxy.csr
kube-proxy-csr.json
kube-proxy-key.pem
kube-proxy.pem

4.5 kube-controoler-manager证书

4.5.1创建 kube-controoler-manager 证书签名请求文件

vim kube-controller-manager-csr.json

{
“CN”: “system:kube-controller-manager”,
“key”: {
“algo”: “rsa”,
“size”: 2048
},
“hosts”: [
“127.0.0.1”,
“10.211.55.11”,
“10.211.55.12”,
“10.211.55.13”,
“k8s-master1”,
“k8s-master2”,
“k8s-master3”
],
“names”: [
{
“C”: “CN”,
“ST”: “BeiJing”,
“L”: “BeiJing”,
“O”: “system:kube-controller-manager”,
“OU”: “system”
}
]
}
说明：

hosts 列表包含所有 kube-controller-manager 节点 IP；
CN 为 system:kube-controller-manager、O 为 system:kube-controller-manager，kubernetes 内置的 ClusterRoleBindings system:kube-controller-manager 赋予 kube-controller-manager 工作所需的权限

4.5.2生成kube-controoller-manager证书和私钥

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager

4.6创建kube-scheduler证书

4.6.1创建 kube-scheduler 证书签名请求文件

vim kube-scheduler-csr.json
{
“CN”: “system:kube-scheduler”,
“hosts”: [
“127.0.0.1”,
“10.211.55.11”,
“10.211.55.12”,
“10.211.55.13”,
“k8s-master1”,
“k8s-master2”,
“k8s-master3”,
],
“key”: {
“algo”: “rsa”,
“size”: 2048
},
“names”: [
{
“C”: “CN”,
“ST”: “BeiJing”,
“L”: “BeiJing”,
“O”: “system:kube-scheduler”,
“OU”: “system”
}
]
}
说明：

hosts 列表包含所有 kube-scheduler 节点 IP；
CN 为 system:kube-scheduler、O 为 system:kube-scheduler，kubernetes 内置的 ClusterRoleBindings system:kube-scheduler 将赋予 kube-scheduler 工作所需的权限。

4.6.2生成 kube-scheduler 证书和私钥

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-scheduler-csr.json| cfssljson -bare kube-scheduler
ls | grep pem

4.7最终生成证书一览

admin-key.pem
admin.pem
ca-key.pem
ca.pem
kube-proxy-key.pem
kube-proxy.pem
kubernetes-key.pem
kubernetes.pem
kube-controller-manager-key.pem
kube-controller-manager.pem
kube-scheduler-key.pem
kube-scheduler.pem

注：查看证书信息命令 -->cfssl-certinfo -cert kubernetes.pem

懒惰の天真热
关注
  • 0
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
阿里Kubernetes（k8s）详解
09-02
阿里深入浅出k8s
k8s证书过期处理方案
11-17
k8s默认的证书有效期为一年，在实际生产中，经常遇到证书过期导致的节点故障问题。 K8S集群证书过期后，会导无法创建Pod，通过kubectl get nodes也无法获取信息，甚至dashboard也无法访问。 执行命令发现报错： Unable to connect to the server: x509: certificate has expired or is not yet valid 查看K8S的日志: Part of the existing bootstrap client certificate is expired: 2022-11-9 9:29:04 +0000 UT 这是说明k8s使用的证书过期了，k8s自带证书是一年的有效期。所以我们解决问题的办法就是更换证书。 kubernetes证书过期处理流程适用于单master或多master的kubeadm安装部署方式。
k8s 证书延期脚本k8s 证书延期脚本
11-27
k8s 证书延期脚本k8s 证书延期脚本k8s 证书延期脚本k8s 证书延期脚本
k8s证书修改为10年文件
06-13
k8s证书修改为10年文件
K8S集群证书监控ssl-exporter监控模板
01-14
原文链接：https://blog.csdn.net/m0_37814112/article/details/122349602
k8s学习笔记-证书详解
weixin_30321449的博客
06-18 1143
在进行二进制搭建K8S集群前，我们需要梳理最磨人的一个点，就是各种各样的证书。 官方文档参考：https://kubernetes.io/docs/setup/certificates/ 一共有多少证书： 先从Etcd算起： 1、Etcd对外提供服务，要有一套etcdserver证书 2、Etcd各节点之间进行通信，要有一套etcdpeer证书 3、Kube-APIserver访问...
kubernetes认证-CKA、CKS考试
热门推荐
西京刀客
04-17 2万+
K8s的专业技术认证主要有以下几种： * CKA（Kubernetes 管理员认证） * CKAD（Kubernetes 应用程序开发者认证） * CKS（Kubernetes 认证安全专家。预计2020年11月开放，须先通过CKA认证）
【博客535】k8s证书原理：各类证书作用
qq_43684922的博客
11-13 2649
我们其实可以使用多个不同的 CA 来颁发这些证书。只要在通信的组件中正确配置用于验证对方证书的 CA 根证书，就可以使用不同的 CA 来颁发不同用途的证书。但我们一般建议采用统一的 CA 来颁发 kubernetes 集群中的所有证书，这是因为采用一个集群根 CA 的方式比采用多个 CA 的方式更容易管理，可以避免多个CA 导致的复杂的证书配置、更新等问题，减少由于证书配置错误导致的集群故障。
K8S各种各样的证书介绍
Vic的博客
10-28 3029
例如，所有etcd server证书需要是同一个CA签署的，所有的etcd peer证书也需要是同一个CA签署的，而一个etcd server证书和一个etcd peer证书，完全可以是两个CA机构签署的，彼此没有任何关系。其实实际上，使用一套证书（都使用一套CA来签署）一样可以搭建出K8S，一样可以上生产，但是理清这些证书的关系，在遇到因为证书错误，请求被拒绝的现象的时候，不至于无从下手，而且如果没有搞清证书之间的关系，在维护或者解决问题的时候，贸然更换了证书，弄不好会把整个系统搞瘫。
k8s有啥证书考
weixin_42589700的博客
12-20 649
在 Kubernetes 中，有许多不同类型的证书可用于认证和加密通信。这些证书包括： TLS 证书：用于加密 HTTPS 通信的证书。 kubeconfig 证书：用于认证 kubectl 客户端与 Kubernetes 集群之间的通信的证书。 授权证书：用于认证 API 服务器与其他组件之间的通信的证书。 客户端认证证书：用于认证 API 服务器对来自客户端的请求的身份的证书。 服务...
k8s 的基本命令
weixin_71474937的博客
06-14 747
1、查看k8s的集群2、查看某一个节点3、删除某个节点4、查看node的详细信息8、查看service的信息10、查询api
Kubernetes 证书详解(鉴权)
qq_37091832的博客
05-28 340
Kubernetes 证书鉴权详解，了解 Kubernetes 证书不仅仅只有 TLS 认证的功能~
k8s证书机制
m0_46673598的博客
09-22 182
原文地址：https://www.zhaohuabing.com/post/2020-05-19-k8s-certificate/接触 Kubernetes 以来，我经常看到 Kubernetes 在不同的地方使用了证书（Certificate），在 Kubernetes 安装和组件启动参数中也需要配置大量证书相关的参数。但是 Kubernetes 的文档在解释这些证书的工作机制方面做得并不是太好。经过大量的相关阅读和分析工作后，我基本弄清楚了 Kubernetes 中证书的使用方式。
k8s(二)管理命令速查
vpx_srio的博客
05-08 564
k8s管理命令速查
k8s-cka考试题库
吴某人的博客
02-22 6955
本次测试的所有问题都必须在指定的cluster配置环境中完成。为尽量减少切换，系统已对问题进行分组，同一cluster内的所有问题将连续显示。 开启TAB补全 做题前先配置k8s自动补齐功能，否则无法TAB补全命令： 登陆管理节点 kubectl --help | grep bash,此步是为了找关键词completion sudo vim /etc/profile 添加source <(kubectl completion bash) 5.保存退出，source /etc/profile
傻傻分不清楚的kubernetes证书
github_35614077的博客
04-05 1488
傻傻分不清楚的kubernetes证书 kubeadm 生成的一坨证书是不是让人很蒙逼，这些东西没那么神奇，来深入扒扒其内裤。 root@k8s-master:/etc/kubernetes/pki# tree . |-- apiserver.crt |-- apiserver-etcd-client.crt |-- apiserver-etcd-client.key |-- apiserver....
k8s学习笔记-创建CA 证书和密钥
snipercai的博客
09-19 2433
主机列表 本次实验选择5台主机，3台作为master主机，2台作为node节点 节点ip OS版本 hostname -f 安装软件 192.168.0.1 RHEL7.4 k8s-master01 docker,etcd,flanneld,kube-apiserver,kube-controller-manager,kube-scheduler 1...
【菜鸡带你识证书】之K8S：CKA（Kubernetes管理员）
最新发布
weixin_42064165的博客
01-11 942
针对CKA（Kubernetes管理员）的综合介绍
k8s自动申请证书
qq_34482492的博客
04-16 45
证书签名请求 | Kubernetes
k8s ingress详解
10-14
K8s ingress（进入）是Kubernetes（K8s）中负责管理和控制入口流量的一种资源对象。它允许我们灵活地将外部流量路由到Kubernetes集群中的不同服务和后端容器。 K8s ingress作为一种API对象，定义了一组规则，用于指定流量如何从集群外部进入特定的服务。它可以基于IP地址、主机名、URL路径等信息来进行路由和转发。 K8s ingress使用了标准的HTTP和HTTPS协议，并可以与一些标准的负载均衡器（如Nginx、HAProxy等）进行集成。在创建ingress资源时，常常会指定一个负载均衡器作为入口流量的进入点。该负载均衡器可以在集群外部接收流量，并将其转发到Kubernetes内部的不同服务上。 K8s ingress不仅提供了流量路由和负载均衡的功能，还支持请求的TLS终结（也称为SSL终结），即可以通过TLS协议对传入的TLS流量进行解密并转发至后端的服务。这极大地简化了为服务配置和管理SSL证书的过程。 另外，K8s ingress还支持多种流量处理的方式，如：会话粘滞、重试和故障转移等。这些功能使得在Kubernetes集群中实现高可用和灵活的流量管理变得更加容易。 总之，K8s ingress为我们提供了管理Kubernetes集群入口流量的强大工具。通过定义一些规则和策略，我们可以根据流量的特点和需求将其精确地路由和转发到后端服务上，并提供一些额外的功能，如负载均衡、SSL终结和多流量处理等。这使得我们可以更好地管理和控制流量，提高服务的可用性和稳定性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值