kubernetes-handbook/practice/create-tls-and-secret-key.md

407 lines
13 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# 创建 TLS 证书和秘钥
执行下列步骤前建议你先阅读以下内容:
- [管理集群中的TLS](../guide/managing-tls-in-a-cluster.md)教您如何创建TLS证书
- [kubelet的认证授权](../guide/kubelet-authentication-authorization.md):向您描述如何通过认证授权来访问 kubelet 的 HTTPS 端点。
- [TLS bootstrap](../guide/tls-bootstrapping.md):介绍如何为 kubelet 设置 TLS 客户端证书引导bootstrap
**注意**:这一步是在安装配置 kubernetes 的所有步骤中最容易出错也最难于排查问题的一步,而这却刚好是第一步,万事开头难,不要因为这点困难就望而却步。
**如果您足够有信心在完全不了解自己在做什么的情况下能够成功地完成了这一步的配置,那么您可以尽管跳过上面的几篇文章直接进行下面的操作。**
`kubernetes` 系统的各组件需要使用 `TLS` 证书对通信进行加密,本文档使用 `CloudFlare` 的 PKI 工具集 [cfssl](https://github.com/cloudflare/cfssl) 来生成 Certificate Authority (CA) 和其它证书;
**生成的 CA 证书和秘钥文件如下:**
+ ca-key.pem
+ ca.pem
+ kubernetes-key.pem
+ kubernetes.pem
+ kube-proxy.pem
+ kube-proxy-key.pem
+ admin.pem
+ admin-key.pem
**使用证书的组件如下:**
+ etcd使用 ca.pem、kubernetes-key.pem、kubernetes.pem
+ kube-apiserver使用 ca.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
**注意:以下操作都在 master 节点即 172.20.0.113 这台主机上执行,证书只需要创建一次即可,以后在向集群中添加新节点时只要将 /etc/kubernetes/ 目录下的证书拷贝到新节点上即可。**
## 安装 `CFSSL`
**方式一:直接使用二进制源码包安装**
``` bash
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
chmod +x cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
chmod +x cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo
export PATH=/usr/local/bin:$PATH
```
**方式二使用go命令安装**
我们的系统中安装了Go1.7.5,使用以下命令安装更快捷:
```bash
$ go get -u github.com/cloudflare/cfssl/cmd/...
$ echo $GOPATH
/usr/local
$ls /usr/local/bin/cfssl*
cfssl cfssl-bundle cfssl-certinfo cfssljson cfssl-newkey cfssl-scan
```
在`$GOPATH/bin`目录下得到以cfssl开头的几个命令。
注意以下文章中出现的cat的文件名如果不存在需要手工创建。
## 创建 CA (Certificate Authority)
**创建 CA 配置文件**
``` bash
mkdir /root/ssl
cd /root/ssl
cfssl print-defaults config > config.json
cfssl print-defaults csr > csr.json
# 根据config.json文件的格式创建如下的ca-config.json文件
# 过期时间设置成了 87600h
cat > ca-config.json <<EOF
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
],
"expiry": "87600h"
}
}
}
}
EOF
```
字段说明
+ `ca-config.json`:可以定义多个 profiles分别指定不同的过期时间、使用场景等参数后续在签名证书时使用某个 profile
+ `signing`:表示该证书可用于签名其它证书;生成的 ca.pem 证书中 `CA=TRUE`
+ `server auth`表示client可以用该 CA 对server提供的证书进行验证
+ `client auth`表示server可以用该CA对client提供的证书进行验证
**创建 CA 证书签名请求**
创建 `ca-csr.json` 文件,内容如下:
``` 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 证书和私钥**
``` bash
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
$ ls ca*
ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem
```
## 创建 kubernetes 证书
创建 kubernetes 证书签名请求文件 `kubernetes-csr.json`
``` json
{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"172.20.0.112",
"172.20.0.113",
"172.20.0.114",
"172.20.0.115",
"10.254.0.1",
"kubernetes",
"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` 集群、`kubernetes master` 集群的主机 IP **`kubernetes` 服务的服务 IP**(一般是 `kube-apiserver` 指定的 `service-cluster-ip-range` 网段的第一个IP,如 10.254.0.1)。
+ 这是最小化安装的kubernetes集群,包括一个私有镜像仓库,三个节点的kubernetes集群,以上物理节点的IP也可以更换为主机名。
**生成 kubernetes 证书和私钥**
``` bash
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kubernetes-csr.json | cfssljson -bare kubernetes
$ ls kubernetes*
kubernetes.csr kubernetes-csr.json kubernetes-key.pem kubernetes.pem
```
或者直接在命令行上指定相关参数:
``` bash
echo '{"CN":"kubernetes","hosts":[""],"key":{"algo":"rsa","size":2048}}' | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes -hostname="127.0.0.1,172.20.0.112,172.20.0.113,172.20.0.114,172.20.0.115,kubernetes,kubernetes.default" - | cfssljson -bare kubernetes
```
## 创建 admin 证书
创建 admin 证书签名请求文件 `admin-csr.json`
``` 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具体参考[ Kubernetes中的用户与身份认证授权](../guide/authentication.md)中 X509 Client Certs 一段)。
在搭建完 kubernetes 集群后,我们可以通过命令: `kubectl get clusterrolebinding cluster-admin -o yaml` ,查看到 `clusterrolebinding cluster-admin` 的 subjects 的 kind 是 Groupname 是 `system:masters`。 `roleRef` 对象是 `ClusterRole cluster-admin`。 意思是凡是 `system:masters Group` 的 user 或者 `serviceAccount` 都拥有 `cluster-admin` 的角色。 因此我们在使用 kubectl 命令时候,才拥有整个集群的管理权限。
```yaml
$ kubectl get clusterrolebinding cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
creationTimestamp: 2017-04-11T11:20:42Z
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-admin
resourceVersion: "52"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin
uid: e61b97b2-1ea8-11e7-8cd7-f4e9d49f8ed0
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:masters
```
生成 admin 证书和私钥:
``` bash
$ cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin
$ ls admin*
admin.csr admin-csr.json admin-key.pem admin.pem
```
## 创建 kube-proxy 证书
创建 kube-proxy 证书签名请求文件 `kube-proxy-csr.json`
``` 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 的权限;
生成 kube-proxy 客户端证书和私钥
``` bash
$ 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 kube-proxy*
kube-proxy.csr kube-proxy-csr.json kube-proxy-key.pem kube-proxy.pem
```
## 校验证书
以 Kubernetes 证书为例。
### 使用 `openssl` 命令
``` bash
$ openssl x509 -noout -text -in kubernetes.pem
...
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, ST=BeiJing, L=BeiJing, O=k8s, OU=System, CN=Kubernetes
Validity
Not Before: Apr 5 05:36:00 2017 GMT
Not After : Apr 5 05:36:00 2018 GMT
Subject: C=CN, ST=BeiJing, L=BeiJing, O=k8s, OU=System, CN=kubernetes
...
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
DD:52:04:43:10:13:A9:29:24:17:3A:0E:D7:14:DB:36:F8:6C:E0:E0
X509v3 Authority Key Identifier:
keyid:44:04:3B:60:BD:69:78:14:68:AF:A0:41:13:F6:17:07:13:63:58:CD
X509v3 Subject Alternative Name:
DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster, DNS:kubernetes.default.svc.cluster.local, IP Address:127.0.0.1, IP Address:172.20.0.112, IP Address:172.20.0.113, IP Address:172.20.0.114, IP Address:172.20.0.115, IP Address:10.254.0.1
...
```
+ 确认 `Issuer` 字段的内容和 `ca-csr.json` 一致;
+ 确认 `Subject` 字段的内容和 `kubernetes-csr.json` 一致;
+ 确认 `X509v3 Subject Alternative Name` 字段的内容和 `kubernetes-csr.json` 一致;
+ 确认 `X509v3 Key Usage、Extended Key Usage` 字段的内容和 `ca-config.json` `kubernetes` profile 一致;
### 使用 `cfssl-certinfo` 命令
``` bash
$ cfssl-certinfo -cert kubernetes.pem
...
{
"subject": {
"common_name": "kubernetes",
"country": "CN",
"organization": "k8s",
"organizational_unit": "System",
"locality": "BeiJing",
"province": "BeiJing",
"names": [
"CN",
"BeiJing",
"BeiJing",
"k8s",
"System",
"kubernetes"
]
},
"issuer": {
"common_name": "Kubernetes",
"country": "CN",
"organization": "k8s",
"organizational_unit": "System",
"locality": "BeiJing",
"province": "BeiJing",
"names": [
"CN",
"BeiJing",
"BeiJing",
"k8s",
"System",
"Kubernetes"
]
},
"serial_number": "174360492872423263473151971632292895707129022309",
"sans": [
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster",
"kubernetes.default.svc.cluster.local",
"127.0.0.1",
"10.64.3.7",
"10.254.0.1"
],
"not_before": "2017-04-05T05:36:00Z",
"not_after": "2018-04-05T05:36:00Z",
"sigalg": "SHA256WithRSA",
...
```
## 分发证书
将生成的证书和秘钥文件(后缀名为`.pem`)拷贝到所有机器的 `/etc/kubernetes/ssl` 目录下备用;
``` bash
mkdir -p /etc/kubernetes/ssl
cp *.pem /etc/kubernetes/ssl
```
## 参考
+ [Generate self-signed certificates - coreos.com](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)
+ [Client Certificates V/s Server Certificates - blogs.msdn.microsoft.com](https://blogs.msdn.microsoft.com/kaushal/2012/02/17/client-certificates-vs-server-certificates/)