在进行二进制搭建K8S集群前,我们需要梳理最磨人的一个点,就是各种各样的证书。
官方文档参考:https://kubernetes.io/docs/setup/certificates/
一共有多少证书:
先从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证书
创建证书配置文件
| 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:过期时间 |
创建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) |
生成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。 |
创建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证书签名请求文件
| 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也可以更换为主机名。
生成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证书签名请求文件
| 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
生成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 |
创建kube-proxy证书
创建 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 字段为空
生成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 |
创建kube-controoler-manager证书
创建 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 工作所需的权限 |
生成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 证书签名请求文件
| 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 工作所需的权限。 |
经过上述操作,我们会用到如下文件
| 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 |
| 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 |
在搭建k8s集群的时候,将这些文件分发到至此集群中其他节点机器中即可。至此,TLS证书创建完毕
证书这块知道怎么生成、怎么用即可,建议暂时不必过多研究