[网络协议]《k8s中的网络安全丨PKI知识梳理》

证书工作流程：

单向认证

指的是只有一个对象校验对端的证书合法性,通常是客户端来校验服务器的合法性。那么 client 需要一个 ca.crt, 服务器需要 server.crt, server.key

1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数 等信息。

2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3、客户端使用服务端返回的信息验证服务器的合法性，包括：

• 证书是否过期、吊销
• 服务器证书的CA是否可靠
• 返回的公钥是否能正确解开返回证书中的数字签名
• 服务器证书上的域名是否和服务器的实际域名相匹配

证书校验没有强制的过程，也就是校验严格和校验宽松通常都是可以配置的，由校验端来确定。

验证通过后，将继续进行通信，否则，终止通信

4、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择

5、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。

6、服务器将选择好的加密方案通过明文方式返回给客户端

7、客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器

8、服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，生成对称加密密钥。客户端和服务端都拥有三个随机数Random1 + Random2 + Random3，两边再根据同样的算法就可以生成一份秘钥，握手结束后的应用层数据都是使用这个秘钥进行对称加密。

为什么要使用三个随机数呢？这是因为 SSL/TLS 握手过程的数据都是明文传输的，并且多个随机数种子来生成秘钥不容易被暴力破解出来。

在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

双向认证

指的是相互校验，服务器需要校验每个 client 证书, client 也需要校验服务器证书
server 需要 server.key 、server.crt 、ca.crt
client 需要 client.key 、client.crt 、ca.crt

双向SSL证书一般用于组织内部的沟通。

1、客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。

2、服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3、客户端使用服务端返回的信息验证服务器的合法性，包括：

• 证书是否过期、吊销
• 服务器证书的CA是否可靠
• 返回的公钥是否能正确解开返回证书中的数字签名
• 服务器证书上的域名是否和服务器的实际域名相匹配

验证通过后，将继续进行通信，否则，终止通信

4、服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端

5、验证客户端的证书，通过验证后，会获得客户端的公钥

6、客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择

7、服务器端在客户端提供的加密方案中选择加密程度最高的加密方式

8、将加密方案通过使用之前获取到的公钥进行加密，返回给客户端

9、客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端

10、服务端收到客户端发送的消息后，使用自己的私钥进行解密，生成对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

证书链

如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。

a.服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;

b.中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;

c.客户端内置信任 CA 的 root.pem 证书，因此服务器证书 server.pem 的被信任。

服务器证书、中间证书与根证书在一起组合成一条合法的证书链，证书链的验证是自下而上的信任传递的过程。

二级证书结构存在的优势：

a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发;

b.根证书一般内置在客户端中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救;

c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书;

d.证书链四级以内一般不会对 HTTPS 的性能造成明显影响。

证书链有以下特点：

a.同一本服务器证书可能存在多条合法的证书链。

因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的 CA，不同的是中间证书的签发机构不同;

b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。

中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

证书吊销

CA 机构能够签发证书，同样也存在机制宣布以往签发的证书无效。证书使用者不合法，CA 需要废弃该证书;或者私钥丢失，使用者申请让证书无效。主要存在两类机制：CRL 与 OCSP。

a.CRL

Certificate Revocation List, 证书吊销列表，是一个单独的文件。该文件包含了 CA 已经吊销的证书序列号(唯一)与吊销日期，同时该文件包含生效日期并通知下次更新该文件的时间，当然该文件必然包含 CA 私钥的签名以验证文件的合法性。

证书中一般会包含一个 URL 地址 CRL Distribution Point，通知使用者去哪里下载对应的 CRL 以校验证书是否吊销。该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书，因为 CRL 更新时间一般是几天，这期间可能已经造成了极大损失。

b.OCSP

Online Certificate Status Protocol, 证书状态在线查询协议，一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个 OCSP 的 URL 地址，要求查询服务器具有良好的性能。

部分 CA 或大部分的自签 CA (根证书)都是未提供 CRL 或 OCSP 地址的，对于吊销证书会是一件非常麻烦的事情。(自签证书的风险之一)

HTTPS性能损耗

HTTPS协议的性能损耗主要体现如下：

• 增加延时

  ? 分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2* RTT(往返时延)，利用会话缓存从而复用连接，延时也至少1* RTT*。

• 消耗较多的CPU资源

  ? 包括对对称加解密、非对称加解密

优化方案：

• CDN接入

  ? HTTPS 增加的延时主要是传输延时 RTT(往返时延)，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。

• 会话缓存

  ? 基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。

• 硬件加速

  ? 为接入服务器安装专用的SSL硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序 。

• 远程解密

  ? 本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。

• SPDY/HTTP2

  ? 前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。

证书等格式说明

.crt 表示证书, .key 表示私钥, .req 表示请求文件,.csr 也表示请求文件, .pem 表示 pem 格式，.der 表示 der 格式。

文件拓展名你可以随便命名，只是为了理解需要而命名不同的拓展名。但文件中的信息是有格式的，和 exe，PE 格式一样。

证书有两种格式：pem 格式和 der 格式

所有证书，私钥等都可以是 pem, 也可以是 der 格式，取决于应用需要。
pem 和 der 格式可以互转:

openssl x509 -in ca.crt -outform DER -out ca.der  # pem -> der
openssl x509 -inform der -in ca.der -out ca.pem   # der -> pem

pem 格式：经过加密的文本文件，一般有下面几种开头结尾：

	-----BEGIN RSA PRIVATE KEY-----
	-----END RSA PRIVATE KEY-----
	or:
   -----BEGIN CERTIFICATE REQUEST-----
   -----END CERTIFICATE REQUEST-----
	or:
   ----BEGIN CERTIFICATE-----
  -----END CERTIFICATE-----

der 格式: 经过加密的二进制文件。

k8s证书机制

k8s组件的认证方式：

k8s各个组件的接口都包含了集群的内部信息，因此采用双向验证，涉及到的相关文件:

• 服务器端证书：包含服务器端公钥和服务端身份信息
• 服务器端私钥
• 客户端证书：包含客户端公钥和客户端身份信息
• 客户端私钥
• 服务器端CA根证书：验证服务器端证书的合法性
• 客户端CA根证书：验证客户端证书的合法性

k8s使用的主要证书

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uoSKdt8z-1651827930662)(D:\文档\AI训练平台\笔记\pki-learning-notes\《网络安全丨PKI知识梳理》.assets\k8s证书.png)]

1. etcd 集群中各个节点之间相互通信使用的证书。由于一个 etcd 节点既为其他节点提供服务，又需要作为客户端访问其他节点，因此该证书同时用作服务器证书和客户端证书。
2. etcd 集群向外提供服务使用的证书。该证书是服务器证书。
3. kube-apiserver 作为客户端访问 etcd 使用的证书。该证书是客户端证书。
4. kube-apiserver 对外提供服务使用的证书。该证书是服务器证书。
5. kube-controller-manager 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
6. kube-scheduler 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书
7. kube-proxy 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
8. kubelet 作为客户端访问 kube-apiserver 使用的证书，该证书是客户端证书。
9. 管理员用户通过 kubectl 访问 kube-apiserver 使用的证书，该证书是客户端证书。
10. kubelet 对外提供服务使用的证书。该证书是服务器证书。
11. kube-apiserver 作为客户端访问 kubelet 采用的证书。该证书是客户端证书。
12. kube-controller-manager 用于生成和验证 service-account token 的证书。该证书并不会像其他证书一样用于身份认证，而是将证书中的公钥/私钥对用于 service account token 的生成和验证。kube-controller-manager 会用该证书的私钥来生成 service account token，然后以 secret 的方式加载到 pod 中。pod 中的应用可以使用该 token 来访问 kube-apiserver， kube-apiserver 会使用该证书中的公钥来验证请求中的 token。

如果通过 kubeadm 安装的 Kubernetes，所有证书都存放在 /etc/kubernetes/pki 目录下。下文所有相关的路径都是基于该路径的相对路径。

手动配置证书的两种方式：

1.单根CA

创建一个单根 CA，由管理员控制器它。该根 CA 可以创建多个中间 CA，并将所有进一步的创建委托给 Kubernetes。

如果要这样做, 你必须将证书文件放置在通过 --cert-dir 命令行参数或者 kubeadm 配置中的 CertificatesDir 配置项指明的目录中。默认的值是 /etc/kubernetes/pki。

如果在运行 kubeadm init 之前存在给定的证书和私钥对，kubeadm 将不会重写它们。 例如，可以将现有的 CA 复制到 /etc/kubernetes/pki/ca.crt 和 /etc/kubernetes/pki/ca.key 中，而 kubeadm 将使用此 CA 对其余证书进行签名。

需要这些 CA：

上面的 CA 之外，还需要获取用于服务账户管理的密钥对，也就是 sa.key 和 sa.pub。

2.所有的证书

如果你不想将 CA 的私钥拷贝至你的集群中，你也可以自己生成全部的证书，需要这些证书：

[1]: 用来连接到集群的不同 IP 或 DNS 名 （就像 kubeadm 为负载均衡所使用的固定 IP 或 DNS 名，kubernetes、kubernetes.default、kubernetes.default.svc、 kubernetes.default.svc.cluster、kubernetes.default.svc.cluster.local）。

其中，'类型’对应一种或多种类型的 x509 密钥用途：

证书路径：

服务帐户密钥对：

用户帐户配置证书

Note: kubelet.conf 中 <nodeName> 的值 必须 与 kubelet 向 apiserver 注册时提供的节点名称的值完全匹配。

1. 对于每个配置，请都使用给定的 CN 和 O 生成 x509 证书/密钥偶对。

2. 为每个配置运行下面的 kubectl 命令：

   KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
   KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
   KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
   KUBECONFIG=<filename> kubectl config use-context default-system
   

文件用途如下：

ETCD配置：

/usr/local/bin/etcd \\
  --cert-file=/etc/etcd/kube-etcd.pem \\                   # 对外提供服务的服务器证书
  --key-file=/etc/etcd/kube-etcd-key.pem \\                # 服务器证书对应的私钥
  --peer-cert-file=/etc/etcd/kube-etcd-peer.pem \\         # peer证书，用于etcd节点之间的相互访问
  --peer-key-file=/etc/etcd/kube-etcd-peer-key.pem \\      # peer 证书对应的私钥
  --trusted-ca-file=/etc/etcd/cluster-root-ca.pem \\       # 用于验证访问etcd服务器的客户端证书的 CA 根证书
  --peer-trusted-ca-file=/etc/etcd/cluster-root-ca.pem\\   # 用于验证peer证书的CA根证书
  ...

kube-apiserver配置

/usr/local/bin/kube-apiserver \\ 
  --tls-cert-file=/var/lib/kubernetes/kube-apiserver.pem \\                             # 用于对外提供服务的服务器证书
  --tls-private-key-file=/var/lib/kubernetes/kube-apiserver-key.pem \\                  # 服务器证书对应的私钥
  --etcd-certfile=/var/lib/kubernetes/kube-apiserver-etcd-client.pem \\                 # 用于访问 etcd 的客户端证书
  --etcd-keyfile=/var/lib/kubernetes/kube-apiserver-etcd-client-key.pem \\              # 用于访问 etcd 的客户端证书的私钥
  --kubelet-client-certificate=/var/lib/kubernetes/kube-apiserver-kubelet-client.pem \\ # 用于访问 kubelet 的客户端证书
  --kubelet-client-key=/var/lib/kubernetes/kube-apiserver-kubelet-client-key.pem \\     # 用于访问 kubelet 的客户端证书的私钥
  --client-ca-file=/var/lib/kubernetes/cluster-root-ca.pem \\                           # 用于验证访问 kube-apiserver 的客户端的证书的 CA 根证书
  --etcd-cafile=/var/lib/kubernetes/cluster-root-ca.pem \\                              # 用于验证 etcd 服务器证书的 CA 根证书  
  --kubelet-certificate-authority=/var/lib/kubernetes/cluster-root-ca.pem \\            # 用于验证 kubelet 服务器证书的 CA 根证书
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\                 # 用于验证 service account token 的公钥
  ...

kube-controller配置：

 /usr/local/bin/kube-controller-manager \\
 --kubeconfig=/etc/kubernetes/controller-manager.conf 
 # 下面几个证书和访问 kube-apiserver 无关
 --cluster-signing-cert-file=/var/lib/kubernetes/cluster-root-ca.pem             # 用于签发证书的 CA 根证书
 --cluster-signing-key-file=/var/lib/kubernetes/cluster-root-ca-key.pem          # 用于签发证书的 CA 根证书的私钥  
 --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem  # 用于对 service account token 进行签名的私钥
 ... 

service account 主要被 pod 用于访问 kube-apiserver。 在为一个 pod 指定了 service account 后，kubernetes 会为该 service account 生成一个 JWT token，并使用 secret 将该 service account token 加载到 pod 上。pod 中的应用可以使用 service account token 来访问 api server。实际上使用的是其公钥和私钥，而并不需要对证书进行验证。

下图展示了 Kubernetes 中生成、使用和验证 service account token 的过程

使用 TLS bootstrapping 简化 Kubelet 证书制作

• 在安装 Kubernetes 时，我们需要为每一个工作节点上的 Kubelet 分别生成一个证书。
• 由于工作节点可能很多，手动生成 Kubelet 证书的过程会比较繁琐。
• 为了解决这个问题，Kubernetes 提供了 TLS bootstrapping 的方式来简化 Kubelet 证书的生成过程。
• 其原理是预先提供一个 bootstrapping token，kubelet 通过该 kubelet 调用 kube-apiserver 的证书签发 API 来生成 自己需要的证书。
• 要启用该功能，需要在 kube-apiserver 中启用 --enable-bootstrap-token-auth ，并创建一个 kubelet 访问 kube-apiserver 使用的 bootstrap token secret。如果使用 kubeadmin 安装，可以使用 kubeadm token create命令来创建 token。

采用TLS bootstrapping 生成证书的流程如下：

1. 调用 kube-apiserver 生成一个 bootstrap token。
2. 将该 bootstrap token 写入到一个 kubeconfig 文件中，作为 kubelet 调用 kube-apiserver 的客户端验证方式。
3. 通过 --bootstrap-kubeconfig 启动参数将 bootstrap token 传递给 kubelet 进程。
4. Kubelet 采用bootstrap token 调用 kube-apiserver API，生成自己所需的服务器和客户端证书。
5. 证书生成后，Kubelet 采用生成的证书和 kube-apiserver 进行通信，并删除本地的 kubeconfig 文件，以避免 bootstrap token 泄漏风险。

cfssl工具

lijian@vma:/opt/k8s/kubernetes-cert$ cat ca-config.json 
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": { # 可以定义多个 profiles，分别指定不同的过期时间、使用场景等参数；后续在签名						证书时使用某个 profile；此实例只有一个kubernetes模板
      "kubernetes": {
         "expiry": "87600h", # 过期时间
         "usages": [
            "signing", # 表示该证书可用于签名其它证书；生成的 ca.pem 证书中 CA=TRUE
            "key encipherment",
            "server auth", # 表示client可以用该 CA 对server提供的证书进行验证；
            "client auth" # 表示server可以用该CA对client提供的证书进行验证；
        ]
      }
    }
  }
}

lijian@vma:/opt/k8s/kubernetes-cert$ cat ca-csr.json  # 自签根证书
{
    "CN": "kubernetes",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN", # Common Name，kube-apiserver 从证书中提取该字段作为请求的用户名 							(User Name)
            "L": "suzhou",
            "ST": "suzhou",
            "O": "k8s", # Organization，kube-apiserver 从证书中提取该字段作为请求用户所属							的组 (Group)
            "OU": "System"
        }
    ]
}

lijian@vma:/opt/k8s/kubernetes-cert$ cat server-csr.json 
{
    "CN": "kubernetes",
    "hosts": [ # hosts包含的是授权范围，不在此范围的的节点或者服务使用此证书就会报证书不匹配错					误。
      "10.0.0.1",
      "127.0.0.1",
      "192.168.17.143",
      "192.168.17.144",
      "192.168.17.145",
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "suzhou",
            "ST": "suzhou",
            "O": "k8s",
            "OU": "System"
        }
    ]
}

cfssl gencert -initca ca-csr.json | cfssljson -bare ca -

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

生成 ca-key.pem（私钥） ca.pem（公钥），server.pem(公钥）,server-key.pem（私钥）

如何使用公司自建PKI

想法1：向公司申请一个 具有签名功能的中间证书，作为整个集群的根证书，随后所有需要的证书由此中间证书签发。

公司根证书：Jiefang-ca.crt 中间证书文件：ca.pem、ca-key.pem

优点：集群证书交互复杂，这种方式后续签发其他证书比较方便，如果有需要新增、变更、更新的证书，同样方便再次签发。

风险： 中间证书签发不受限制

想法2：向公司申请所有需要的证书

公司根证书：Jiefang-ca.crt, etcd.pem,etcd-key.pem, api-server.pem, api-server-key.pem ......

优点：所有证书都由公司根证书签发，安全等级高;如果公司PKI系统有吊销机制，安全性更高

缺点：证书量大，签发繁琐；

? 如果有需要新增、变更、更新的证书，需要再次向公司申请签发。

? 考虑kubelet是否只支持使用启动引导令牌（Bootstrap Tokens）认证方式向api-server申请证书，因为启动引导需要提前配置根证书秘钥。

创作打卡挑战赛

赢取流量/现金/CSDN周边激励大奖