首页 > 其他分享 >k8s各种证书介绍

k8s各种证书介绍

时间：2023-02-28 17:35:56浏览次数：52  
标签：k8s kubernetes 证书 ca 介绍 pem key kube

在进行二进制搭建K8S集群前，我们需要梳理最磨人的一个点，就是各种各样的证书。

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

https://blog.csdn.net/vic_qxz/article/details/127568609

一共有多少证书：

先从Etcd算起：

1、Etcd对外提供服务，要有一套etcd server证书

2、Etcd各节点之间进行通信，要有一套etcd peer证书

3、Kube-APIserver访问Etcd，要有一套etcd client证书

再算kubernetes：

4、Kube-APIserver对外提供服务，要有一套kube-apiserver server证书

5、kube-scheduler、kube-controller-manager、kube-proxy、kubelet和其他可能用到的组件，需要访问kube-APIserver，要有一套kube-APIserver client证书

6、kube-controller-manager要生成服务的service account，要有一对用来签署service account的证书(CA证书)

7、kubelet对外提供服务，要有一套kubelet server证书

8、kube-APIserver需要访问kubelet，要有一套kubelet client证书

加起来共8套，但是这里的“套”的含义我们需要理解。

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

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

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

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

***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

kubelet证书为何不同

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

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

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

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

正式制作证书

虽然可以用多套证书，但是维护多套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

使用证书的组件如下：

  • 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

创建CA证书

创建证书配置文件

  1.   vim ca-config.json
  2.   {
  3.   "signing": {
  4.   "default": {
  5.   "expiry": "87600h"
  6.   },
  7.   "profiles": {
  8.   "kubernetes": {
  9.   "usages": [
  10.   "signing",
  11.   "key encipherment",
  12.   "server auth",
  13.   "client auth"
  14.   ],
  15.   "expiry": "87600h"
  16.   }
  17.   }
  18.   }
  19.   }

字段说明：

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

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

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

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

expiry：过期时间

创建CA证书签名请求文件

  1.   vim ca-csr.json
  2.    
  3.    
  4.   {
  5.   "CN": "kubernetes",
  6.   "key": {
  7.   "algo": "rsa",
  8.   "size": 2048
  9.   },
  10.   "names": [
  11.   {
  12.   "C": "CN",
  13.   "ST": "BeiJing",
  14.   "L": "BeiJing",
  15.   "O": "k8s",
  16.   "OU": "System"
  17.   }
  18.   ],
  19.   "ca": {
  20.   "expiry": "87600h"
  21.   }
  22.   }

字段说明：

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

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

生成CA证书和私钥

  1.   cfssl gencert -initca ca-csr.json | cfssljson -bare ca
  2.    
  3.   ls | grep ca
  4.    
  5.   ca-config.json
  6.    
  7.   ca.csr
  8.    
  9.   ca-csr.json
  10.    
  11.   ca-key.pem
  12.    
  13.   ca.pem

其中ca-key.pem是ca的私钥，ca.csr是一个签署请求，ca.pem是CA证书，是后面kubernetes组件会用到的RootCA。

创建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

创建kubernetes证书签名请求文件

  1.   vim kubernetes-csr.json
  2.   {
  3.   "CN": "kubernetes",
  4.   "hosts": [
  5.   "127.0.0.1",
  6.   "10.211.55.11",
  7.   "10.211.55.12",
  8.   "10.211.55.13",
  9.   "10.211.55.8",
  10.   "10.0.0.1",
  11.   "k8s-master1",
  12.   "k8s-master2",
  13.   "k8s-master3",
  14.   "etcd01",
  15.   "etcd02",
  16.    
  17.   "etcd03",
  18.   "kubernetes",
  19.   "kube-api.wangdong.com",
  20.   "kubernetes.default",
  21.   "kubernetes.default.svc",
  22.   "kubernetes.default.svc.cluster",
  23.   "kubernetes.default.svc.cluster.local"
  24.   ],
  25.   "key": {
  26.   "algo": "rsa",
  27.   "size": 2048
  28.   },
  29.   "names": [
  30.   {
  31.   "C": "CN",
  32.   "ST": "BeiJing",
  33.   "L": "BeiJing",
  34.   "O": "k8s",
  35.   "OU": "System"
  36.   }
  37.   ]
  38.   }

字段说明：

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

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

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

生成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

创建admin证书

创建admin证书签名请求文件

  1.   vim admin-csr.json
  2.   {
  3.   "CN": "admin",
  4.   "hosts": [],
  5.   "key": {
  6.   "algo": "rsa",
  7.   "size": 2048
  8.   },
  9.   "names": [
  10.   {
  11.   "C": "CN",
  12.   "ST": "BeiJing",
  13.   "L": "BeiJing",
  14.   "O": "system:masters",
  15.   "OU": "System"
  16.   }
  17.   ]
  18.   }

说明：

后续 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

生成admin证书和私钥

  1.   cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin
  2.    
  3.   ls | grep admin
  4.    
  5.   admin.csr
  6.    
  7.   admin-csr.json
  8.    
  9.   admin-key.pem
  10.    
  11.   admin.pem

创建kube-proxy证书

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

  1.   vim kube-proxy-csr.json
  2.   {
  3.   "CN": "system:kube-proxy",
  4.   "hosts": [],
  5.   "key": {
  6.   "algo": "rsa",
  7.   "size": 2048
  8.   },
  9.   "names": [
  10.   {
  11.   "C": "CN",
  12.   "ST": "BeiJing",
  13.   "L": "BeiJing",
  14.   "O": "k8s",
  15.   "OU": "System"
  16.   }
  17.   ]
  18.   }
  19.    

说明：

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 字段为空

生成kube-proxy证书和私钥

  1.   cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy
  2.    
  3.   ls |grep kube-proxy
  4.    
  5.   kube-proxy.csr
  6.    
  7.   kube-proxy-csr.json
  8.    
  9.   kube-proxy-key.pem
  10.    
  11.   kube-proxy.pem

创建kube-controoler-manager证书

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

  1.   vim kube-controller-manager-csr.json
  2.    
  3.    
  4.   {
  5.   "CN": "system:kube-controller-manager",
  6.   "key": {
  7.   "algo": "rsa",
  8.   "size": 2048
  9.   },
  10.   "hosts": [
  11.   "127.0.0.1",
  12.   "10.211.55.11",
  13.   "10.211.55.12",
  14.   "10.211.55.13",
  15.   "k8s-master1",
  16.   "k8s-master2",
  17.   "k8s-master3"
  18.   ],
  19.   "names": [
  20.   {
  21.   "C": "CN",
  22.   "ST": "BeiJing",
  23.   "L": "BeiJing",
  24.   "O": "system:kube-controller-manager",
  25.   "OU": "system"
  26.   }
  27.   ]
  28.   }

说明：

hosts 列表包含所有 kube-controller-manager 节点 IP；

CN 为 system:kube-controller-manager、O 为 system:kube-controller-manager，kubernetes 内置的 ClusterRoleBindings system:kube-controller-manager 赋予 kube-controller-manager 工作所需的权限

生成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

创建kube-scheduler证书

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

  1.   vim kube-scheduler-csr.json
  2.   {
  3.   "CN": "system:kube-scheduler",
  4.   "hosts": [
  5.   "127.0.0.1",
  6.   "10.211.55.11",
  7.   "10.211.55.12",
  8.   "10.211.55.13",
  9.   "k8s-master1",
  10.   "k8s-master2",
  11.   "k8s-master3",
  12.   ],
  13.   "key": {
  14.   "algo": "rsa",
  15.   "size": 2048
  16.   },
  17.   "names": [
  18.   {
  19.   "C": "CN",
  20.   "ST": "BeiJing",
  21.   "L": "BeiJing",
  22.   "O": "system:kube-scheduler",
  23.   "OU": "4Paradigm"
  24.   }
  25.   ]
  26.   }

说明：

hosts 列表包含所有 kube-scheduler 节点 IP；

CN 为 system:kube-scheduler、O 为 system:kube-scheduler，kubernetes 内置的 ClusterRoleBindings system:kube-scheduler 将赋予 kube-scheduler 工作所需的权限。

经过上述操作，我们会用到如下文件

  1.   cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-scheduler-csr.json| cfssljson -bare kube-scheduler
  2.    
  3.   ls | grep pem
  4.    
  5.   admin-key.pem
  6.    
  7.   admin.pem
  8.    
  9.   ca-key.pem
  10.    
  11.   ca.pem
  12.    
  13.   kube-proxy-key.pem
  14.    
  15.   kube-proxy.pem
  16.    
  17.   kubernetes-key.pem
  18.    
  19.   kubernetes.pem
  20.    
  21.   kube-controller-manager-key.pem
  22.    
  23.   kube-controller-manager.pem
  24.    
  25.   kube-scheduler-key.pem
  26.    
  27.   kube-scheduler.pem

查看证书信息：

cfssl-certinfo -cert kubernetes.pem

在搭建k8s集群的时候，将这些文件分发到至此集群中其他节点机器中即可。至此，TLS证书创建完毕

证书这块知道怎么生成、怎么用即可，建议暂时不必过多研究

标签：k8s,kubernetes,证书,ca,介绍,pem,key,kube
From： https://www.cnblogs.com/xiexun/p/17165266.html

相关文章

  • 【django-vue】前端取消默认样式 main.js配置 后端主页模块接口 跨域问题详解 项目自
    目录回顾上节课回顾今日内容1前端全局样式和js配置1.1global.css1.2settings.js1.3main.js2后端主页模块接口三种开发模式模型父类BaseModel轮播图模型类代码轮播图接......
  • K8S调度约束 （云原生）
    一、调度约束Kubernetes是通过List-Watch（监控）的机制进行每个组件的协作，保持数据同步的，每个组件之间的设计实现了解耦。用户是通过kubectl根据配置文件，向APIServer......
  • 前端技术之HTML-介绍和目标
    HTML可以让我们实现静态页面效果，掌握绘制静态页面所需的各种知识点，了解前端体系方向，为后续深入打下基础。课程通俗易懂，理论结合实战，课堂感染力丰富，轻松掌握必会标签，真正做到......
  • 前端技术之HTML-介绍和目标
    HTML可以让我们实现静态页面效果，掌握绘制静态页面所需的各种知识点，了解前端体系方向，为后续深入打下基础。课程通俗易懂，理论结合实战，课堂感染力丰富，轻松掌握必会标签，真正做到......
  • 前端技术之HTML-介绍和目标
    HTML可以让我们实现静态页面效果，掌握绘制静态页面所需的各种知识点，了解前端体系方向，为后续深入打下基础。课程通俗易懂，理论结合实战，课堂感染力丰富，轻松掌握必会标签，真正做......
  • 前端技术之HTML-介绍和目标
    HTML可以让我们实现静态页面效果，掌握绘制静态页面所需的各种知识点，了解前端体系方向，为后续深入打下基础。课程通俗易懂，理论结合实战，课堂感染力丰富，轻松掌握必会标签，真正做......
  • 揭开Salesforce Accredited Professional证书神秘面纱，到底含金量有多高？
    自从Salesforce宣布AccreditedProfessional计划以来，已经过去了将近两年。这些认证旨在证明备考者在Salesforce平台特定领域的广泛知识，并且仅供Salesforce合作伙伴使用。A......
  • k8s 部署 metrics-server
    k8s提供了top命令可用于统计资源使用情况，它包含有node和pod两个⼦命令，分别显⽰node节点和Pod对象的资源使⽤信息。kubectltop命令依赖于metrics接口。k8s系......
  • 轻量级CI/CD发布部署环境搭建及使用_01_基本介绍
    轻量级CI/CD发布部署环境搭建及使用_01_基本介绍授人以鱼不如授人以渔，如果说的别人都没明白，说明自己实际也不是太明白 最终实现效果如图1，选择相应环境下的项目，执行构......
  • K8S 1.20 弃用 Docker 评估之 Docker CLI 的替代产品
    背景2020年12月初，Kubernetes在其最新的Changelog中宣布，自Kubernetes1.20之后将弃用Docker作为容器运行时。弃用Docker带来的，可能是一系列的改变，包括不限于：......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99