TLS 使用指南（一）：如何在 Rancher 2.x 中进行 TLS 终止？

引言

这是一个系列文章，我们将在本系列中探索 Rancher 使用 TLS 证书的不同方式。TLS，安全传输层协议，是用于保护网络通信的加密协议。它是目前已经弃用的安全套接层（SSL）的继任者。

你可以从本系列中了解 TLS 如何集成到各种 Rancher 组件中以及如何准备环境以正确利用 Rancher 中的 TLS。

为什么安全传输层协议（TLS）很重要？

Rancher 在任何地方都可以使用 TLS。因此，在安装 Rancher 之前，确定 TLS 终止选项十分重要。

1、 确认你想要执行的 TLS 终止类型，有以下几种类型：

• 自签名，由 Rancher 终止（这是默认的）

• Let’s Encrypt，由 Rancher 终止

• 自带证书，由 Rancher 终止

• 外部 TLS 终止

2、 如果你选择了自带证书或外部 TLS 终止，那么请确保你有用于注册证书的 CA 证书的副本（仅需 cert，不需要密钥）。Rancher 在执行操作时需要这一文件。

3、 确保你知道 Rancher 要使用的主机名。这在安装之后不可更改。

建议你通过阅读文档来了解更多的细节：

https://docs.rancher.cn/

什么组件需要安全传输层协议

对于任何企业软件来说，你都需要在安装和使用之前确定特定的要求，包括存储要求、网络、在云端还是本地等等。在进行安装之前，你必须得明确回答这些问题。

对于 Rancher 来说，考虑因素之一是 TLS。必须了解并计划使用 Rancher 进行 TLS 的方法，如此才能获得能够充分支持并且拥有良好功能的解决方案。

除了 HTTPS 安全之外，还有其他两个地方也十分需要 TLS：

1、 kubectl

2、 节点和集群 agent 通信

注意，并不止以上两个地方会使用到 TLS，只是上述两个地方更为常见。

理解 kubectl TLS

首先，我们来看一下示例 kubeconfig 文件：

apiVersion: v1kind: Configclusters:- name: "sample"  cluster:    server: "https://rancher.example.org/k8s/clusters/c-1234"    certificate-authority-data: "LS0t..."

特别注意 certificate-authority-data 的存在。该字段是 CA 证书的 base64 编码版本，这一 CA 证书可用于对 Kubernetes API 服务器提供的 TLS 证书进行签名。或者是 Rancher 在代理调用 kube-apiserver 时提供的 TLS 证书。

为什么这个如此重要呢？因为 kubectl 使用 certificate-authority-data 来确保是你（而不是冒名顶替者）正在连接到正确的集群。如果服务器提供的证书尚未由 certificate-authority-data 中的证书签名，那么 kubectl 会警告你并且退出。基本上，你不会遭受 MITM（中间人）攻击。

certificate-authority-data 中的值来自 kube-ca 的 CA 证书（非 Rancher 集群或使用授权集群端点的 Rancher 集群），或者是 Rancher CA 证书（任意 Rancher 集群）。

请务必在此字段中输入正确的值，否则 kubectl 不会验证与你的 Kubernetes 集群的连接。这就是为什么在设置 Rancher 时需要正确配置 TLS。

理解节点和集群 Agent 通信

在任意 Rancher 连接的集群（包括导入的或其他方式）中，需要部署两个工作负载：

1、 cattle-cluster-agent Deployment

2、 cattle-node-agent Deployment

每个工作负载执行一个特定的功能。总之，这两个 agent 连接到 Rancher 的 API 并在 tcp/443 上建立安全的 websocket 连接。然后，该 websocket 连接会用于 Rancher 与托管的节点或集群之间的双向通信。

集群 agent 连接到托管集群的 Kubernetes API，这使 Rancher 可以通过 websocket 隧道执行 API 操作。当执行集群操作时（如升级、ectd 快照等），节点 agent 将与 RKE 集群中的节点进行交互。

这两个 agent 都使用称为“CA checksum”的配置值，该配置值将作为环境变量以 CATTLE_CA_CHECKSUM 的形式传递给 Pod。该值需要与 kubectl 相同——确保连接到正确的端点并方式 MITM 的发生。但是，校验和的工作原理略有不同。

cattle agent 的 CA checksum 可以厌憎 agent 是否连接到 Rancher API 的正确实例。由于 Rancher 使用 TLS 保护其 HTTPS API 端点，因此 agent 容器可以使用此校验和来验证 API 端点提供的 TLS 证书是否正确。

其次，CATTLE_CA_CHECKSUM 未配置为 CA 证书的 base64 编码副本。相反，Rancher 会生成 CA 证书的 sha256 校验和，该证书用于签署 Rancher TLS 证书，并将该值放入 CATTLE_CA_CHECKSUM 字段中。结果如下：

CATTLE_CA_CHECKSUM=b0af09b35ef086fcfc21e990fbd750720abe5c811dbea3ae40fe050a67f0bdb0e

当一个 Rancher 集群或节点 agent 调用 Rancher API，它会将 CA 证书与其在 Deployment 和 DaemonSet 中配置的那一个进行比较。如果它们匹配，通信则会建立起来。

安全传输层协议（TLS）终止

当安装 Rancher 时有以下 4 种主要方式来终止 TLS：

• 使用 Rancher 的自签名证书

• 使用 Let’s Encrypt

• 自带证书

• 外部 TLS 终止

每种方法都有特定的要求，需要在具体操作中进行权衡。

使用 Rancher 的自签名证书

在终止 TLS 的四个选项中，这个可能是最简单的。在 HA 和单节点安装方案中，这也是 Rancher 的默认选项。也就是说，通过不将任何 TLS 特定的参数传递给 helm 安装或 docker run，来进行安装。

安装后，Rancher 会生成一个 CA 证书（CN=cattle-ca），并且使用该证书为其自身证书签名。根据你执行的安装类型，自签名证书的工作方式会有所不同。

单节点安装

容器启动后，设置前，Rancher 在 443 端口上响应任意 HTTPS 请求，无论其目标 Host 值如何。这是如何成为可能的呢？

在这一状态下，Rancher 会为你到达的任何主机名自动生成一个证书。如果是一个 IP（如 10.11.12.13），那么 Rancher 会为该 IP 生成一个自签名（使用 cattle-ca）证书。如果是以一个主机名（如 my-rancher.example.org）到达此新的 Rancher 安装目录，同样也会以相同的方式生成一个自签名证书。

在 Rancher 使用单个证书之前，你需要完成设置步骤（设置管理员密码并确认 Rancher 主机名）。该证书对于在 Rancher 初始设置期间配置的主机名有效。

HA 安装

在 HA 安装场景下，自签名证书需要你安装一个名为 cert-manager 的应用程序。与单节点 Rancher 管理 CA 证书本身不同，HA rancher 使用 cert-manager 来处理证书的生命周期。你可以根据以下指引将 cert-manager 安装到你准备好的 Kubernetes 集群中：

https://rancher.com/docs/rancher/v2.x/en/installation/k8s-install/helm-rancher/

一旦你完成 cert-manager 的安装，下一步是安装 rancher。使用自签名证书是 Rancher 的默认设置，所以执行 helm install 时实际上只有一个强制性参数：

--set hostname=<YOUR.DNS.NAME>

该参数是强制性的，因为 Rancher HA 安装不具有与单节点安装相同的即时证书生成功能。因此，一旦你设置了主机名，该主机名将用于 Rancher 安装的整个生命周期。所以你必须确保你的设置是正确的。

然后 cert-manager 将会生成一个证书，该证书作为一个 secret 存储在 cattle-system 命名空间中，名为 tls-rancher-ingress。

本文就到此结束啦，本系列的第二篇文章将会为大家介绍其他类型的 TLS 终止选项。