K8S各种各样的证书介绍
一共有多少证书:
先从Etcd算起:
1、Etcd对外提供服务,要有一套etcd 证书
2、Etcd各节点之间进行通信,要有一套etcd peer证书
3、Kube-API 访问Etcd,要有一套etcd 证书
再算:
4、Kube-API 对外提供服务,要有一套kube- 证书
5、kube-、kube--、kube-proxy、和其他可能用到的组件,需要访问kube-API ,要有一套kube- 证书
6、kube--要生成服务的 ,要有一对用来签署 的证书(CA证书)
7、对外提供服务,要有一套 证书
8、kube-API 需要访问,要有一套 证书
加起来共8套,但是这里的“套”的含义我们需要理解。
同一个套内的证书必须是用同一个CA签署的,签署不同套里的证书的CA可以相同,也可以不同。例如,所有etcd 证书需要是同一个CA签署的,所有的etcd peer证书也需要是同一个CA签署的,而一个etcd 证书和一个etcd peer证书,完全可以是两个CA机构签署的,彼此没有任何关系。这算两套证书。
为什么同一个“套”内的证书必须是同一个CA签署的
原因在验证这些证书的一端。因为在要验证这些证书的一端,通常只能指定一个Root CA。这样一来,被验证的证书自然都需要是被这同一个Root CA对应的私钥签署,不然不能通过认证。
其实实际上,使用一套证书(都使用一套CA来签署)一样可以搭建出K8S,一样可以上生产,但是理清这些证书的关系,在遇到因为证书错误,请求被拒绝的现象的时候,不至于无从下手,而且如果没有搞清证书之间的关系,在维护或者解决问题的时候,贸然更换了证书,弄不好会把整个系统搞瘫。
每个用到的证书都是独一无二的,因为它要绑定各自的IP地址,于是需要给每个单独制作证书,如果业务量很大的情况下,node节点会很多,这样一来的数量也随之增加,而且还会经常变动(增减Node)的证书制作就成为一件很麻烦的事情。使用TLS 就可以省事儿很多。
**工作原理:**第一次启动的时候,先用同一个 token作为凭证。这个token已经被提前设置为隶属于用户组:,并且这个用户组的权限也被限定为只能用来申请证书。 用这个 token通过认证后,申请到属于自己的两套证书( 、kube- for ),申请成功后,再用属于自己的证书做认证,从而拥有了应有的权限。这样一来,就去掉了手动为每个准备证书的过程,并且的证书还可以自动轮替更新
证书为何不同
这样做是一个为了审计,另一个为了安全。 每个既是服务端(kube-需要访问),也是客户端(需要访问kube-),所以要有服务端和客户端两组证书。
服务端证书需要与服务器地址绑定,每个的地址都不相同,即使绑定域名也是绑定不同的域名,故服务端地址不同
客户端证书也不应相同,每个的认证证书与所在机器的IP绑定后,可以防止一个的认证证书泄露以后,使从另外的机器上伪造的请求通过验证。
安全方面,如果每个node上保留了用于签署证书的 token,那么 token泄漏以后,是不是可以随意签署证书了?安全隐患非常大。所以,启动成功以后,本地的 token需要被删除
正式制作证书
虽然可以用多套证书,但是维护多套CA实在过于繁杂,这里还是用一个CA签署所有证书。
需要准备的证书:
ca-key.pem
ca.pem
admin-key.pem
admin.pem
kube--key.pem
kube-.pem
kube---key.pem
kube--.pem
kube-proxy-key.pem
kube-proxy.pem
-key.pem (-key.pem)
.pem(.pem)
使用证书的组件如下:
etcd:使用 ca.pem -key.pem .pem
kube-:使用 ca.pem ca-key.pem -key.pem .pem
:使用 ca.pem
kube-proxy:使用 ca.pem kube-proxy-key.pem kube-proxy.pem
:使用 ca.pem admin-key.pem、admin.pem
kube--:使用 ca-key.pem ca.pem kube---key.pem kube--.pem
kube-: 使用 kube--key.pem kube-.pem
我们使用CFSSL来制作证书,它是开发的一个开源的PKI工具,是一个完备的CA服务系统,可以签署、撤销证书等,覆盖了一个证书的整个生命周期,后面只用到了它的命令行工具。
注:一般情况下,K8S中证书只需要创建一次,以后在向集群中添加新节点时只要将/etc//ssl目录下的证书拷贝到新节点上即可。
wget
wget
wget
chmod +x -amd64 -amd64 cfssl--amd64
mv -amd64 /usr/local/bin/cfssl
mv -amd64 /usr/local/bin/
mv cfssl--amd64 /usr/bin/cfssl-
一:创建CA证书
创建证书配置文件
/etc//ssl
ca-.json
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"expiry": "87600h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}
}
字段说明:
ca-.json:可以定义多个 ,分别指定不同的过期时间、使用场景等参数;后续在签名证书时使用某个 ;
:表示该证书可以签名其他证书;生成的ca.pem证书中 CA=TRUE;
auth:表示可以用该 CA 对提供的证书进行验证;
auth:表示可以用该CA对提供的证书进行验证;
:过期时间
创建CA证书签名请求文件
ca-csr.json
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Shenzhen",
"ST": "Shenzhen",
"O": "k8s",
"OU": "System"
}
],
"ca": {
"expiry": "87600h"
}
}
字段说明:
“CN”: Name,kube- 从证书中提取该字段作为请求的用户名 (User Name);浏览器使用该字段验证网站是否合法;
“O”:,kube- 从证书中提取该字段作为请求用户所属的组 (Group)
生成CA证书和私钥
-amd64 - ca-csr.json | -amd64 -bare ca -
其中ca-key.pem是ca的私钥,ca.csr是一个签署请求,ca.pem是CA证书,是后面组件会用到的
二:创建证书
创建证书签名请求文件
-csr.json
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local",
"192.168.10.10","192.168.10.11","192.168.10.12"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Shenzhen",
"ST": "Shenzhen",
"O": "k8s",
"OU": "System"
}
]
}
字段说明:
如果 hosts 字段不为空则需要指定授权使用该证书的 IP 或域名列表。
由于该证书后续被 etcd 集群和 集群使用,将etcd、节点的IP都填上,同时还有网络的首IP。(一般是 kube- 指定的 --ip-range 网段的第一个IP,如 10.0.0.1)
生成证书和私钥
-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= -csr.json | -amd64 -bare
三:创建admin证书
创建admin证书签名请求文件
admin-csr.json
{
"CN": "admin",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Shenzhen",
"ST": "Shenzhen",
"O": "system:masters",
"OU": "System"
}
]
}
说明:
后续 kube- 使用 RBAC 对客户端(如 、kube-proxy、Pod)请求进行授权;
kube- 预定义了一些 RBAC 使用的 ,如 -admin 将 Group : 与 Role -admin 绑定,该 Role 授予了调用kube- 的所有 API的权限;
O指定该证书的 Group 为 :, 使用该证书访问 kube- 时 ,由于证书被 CA 签名,所以认证通过,同时由于证书用户组为经过预授权的 :,所以被授予访问所有 API 的权限;
注:这个admin 证书,是将来生成管理员用的kube 配置文件用的,现在我们一般建议使用RBAC 来对 进行角色权限控制, 将证书中的CN 字段 作为User, O 字段作为 Group
注意"hosts": []表示所有主机
生成admin证书和私钥
-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= admin-csr.json | -amd64 -bare admin
四:创建kube-proxy证书
创建 kube-proxy 证书签名请求文件
kube-proxy-csr.json
{
"CN": "system:kube-proxy",
"hosts": [],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Shenzhen",
"ST": "Shenzhen",
"O": "k8s",
"OU": "System"
}
]
}
说明:
CN 指定该证书的 User 为 :kube-proxy;
kube- 预定义的 :node- 将User :kube-proxy 与 Role :node- 绑定,该 Role 授予了调用 kube- Proxy 相关 API 的权限;
该证书只会被 当做 证书使用,所以 hosts 字段为空
生成kube-proxy证书和私钥
-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= kube-proxy-csr.json | -amd64 -bare kube-proxy
五:创建kube--证书
创建 kube-- 证书签名请求文件
kube---csr.json
{
"CN": "system:kube-controller-manager",
"hosts": [
"127.0.0.1",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local",
"192.168.10.10",
"192.168.10.11",
"192.168.10.12"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Shenzhen",
"ST": "Shenzhen",
"O": "system:kube-controller-manager",
"OU": "System"
}
]
}
说明:
hosts 列表包含所有 kube-- 节点 IP;
CN 为 :kube--、O 为 :kube--, 内置的 :kube-- 赋予 kube-- 工作所需的权限
生成kube--证书和私钥
-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= kube---csr.json | -amd64 -bare kube--
六:创建kube-证书
创建 kube- 证书签名请求文件
kube--csr.json
{
"CN": "system:kube-scheduler",
"hosts": [
"127.0.0.1",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local",
"192.168.10.10",
"192.168.10.11",
"192.168.10.12"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Shenzhen",
"ST": "Shenzhen",
"O": "system:kube-scheduler",
"OU": "System"
}
]
}
说明:
hosts 列表包含所有 kube- 节点 IP;
CN 为 :kube-、O 为 :kube-, 内置的 :kube- 将赋予 kube- 工作所需的权限
生成kube-证书和私钥
-amd64 -ca=ca.pem -ca-key=ca-key.pem -=ca-.json -= kube--csr.json | -amd64 -bare kube-
七:查看证书信息:
cfssl- -cert .pem
在搭建k8s集群的时候,将这些文件分发到至此集群中其他节点机器中即可。至此,TLS证书创建完毕
分发 /etc/目录内容
rsync -av -- -- '*.json' -- '*.csr' /etc/ [email protected]:/etc
rsync -av -- -- '*.json' -- '*.csr' /etc/ [email protected]:/etc
还木有评论哦,快来抢沙发吧~