管理集群中的 TLS 证书

Kubernetes 提供了一个 certificates.k8s.io API，它允许你配置由你控制的证书颁发机构 (CA) 签名的 TLS 证书。这些 CA 和证书可以被你的工作负载用来建立信任。

certificates.k8s.io API 使用与 ACME 草案类似的协议。

说明

使用 certificates.k8s.io API 创建的证书由专用的 CA 签名。可以配置你的集群使用集群根 CA 来实现此目的，但你不应该依赖它。不要假设这些证书将针对集群根 CA 进行验证。

开始之前

你需要一个 Kubernetes 集群，并且 kubectl 命令行工具必须配置为与你的集群通信。建议在至少有两个节点（不充当控制平面主机）的集群上运行本教程。如果你还没有集群，可以使用 minikube 创建一个，或者可以使用以下 Kubernetes 游乐场

你需要 cfssl 工具。你可以从 https://github.com/cloudflare/cfssl/releases 下载 cfssl。

此页面中的某些步骤使用 jq 工具。如果你没有 jq，可以通过你的操作系统软件源安装它，或者从 https://jqlang.github.io/jq/ 获取它。

集群中信任 TLS

信任自定义 CA 的应用程序（作为 Pod 运行）通常需要额外的应用程序配置。你需要将 CA 证书捆绑包添加到 TLS 客户端或服务器信任的 CA 证书列表中。例如，你可以使用 golang TLS 配置通过解析证书链并将解析后的证书添加到 tls.Config 结构体中的 RootCAs 字段中来执行此操作。

说明

即使自定义 CA 证书可能包含在文件系统中（在 ConfigMap kube-root-ca.crt 中），也不应将该证书颁发机构用于任何其他目的，而仅用于验证内部 Kubernetes 端点。内部 Kubernetes 端点的示例是默认命名空间中的名为 kubernetes 的 Service。

如果你想为你的工作负载使用自定义证书颁发机构，你应该单独生成该 CA，并通过你的 Pod 可以访问读取的 ConfigMap 分发其 CA 证书。

请求证书

以下部分演示了如何为通过 DNS 访问 Kubernetes Service 创建 TLS 证书。

说明

本教程使用 CFSSL：Cloudflare 的 PKI 和 TLS 工具包点击此处了解更多信息。

创建证书签名请求

通过运行以下命令生成私钥和证书签名请求 (CSR)

cat <<EOF | cfssl genkey - | cfssljson -bare server
{
  "hosts": [
    "my-svc.my-namespace.svc.cluster.local",
    "my-pod.my-namespace.pod.cluster.local",
    "192.0.2.24",
    "10.0.34.2"
  ],
  "CN": "my-pod.my-namespace.pod.cluster.local",
  "key": {
    "algo": "ecdsa",
    "size": 256
  }
}
EOF

其中 192.0.2.24 是 Service 的集群 IP，my-svc.my-namespace.svc.cluster.local 是 Service 的 DNS 名称，10.0.34.2 是 Pod 的 IP，而 my-pod.my-namespace.pod.cluster.local 是 Pod 的 DNS 名称。你应该看到类似以下的输出

2022/02/01 11:45:32 [INFO] generate received request
2022/02/01 11:45:32 [INFO] received CSR
2022/02/01 11:45:32 [INFO] generating key: ecdsa-256
2022/02/01 11:45:32 [INFO] encoded CSR

此命令生成两个文件；它生成包含 PEM 编码 PKCS#10 认证请求的 server.csr，以及包含要创建的证书的 PEM 编码密钥的 server-key.pem。

创建 CertificateSigningRequest 对象以发送到 Kubernetes API

生成 CSR 清单（YAML 格式），并将其发送到 API 服务器。你可以通过运行以下命令来执行此操作

cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: my-svc.my-namespace
spec:
  request: $(cat server.csr | base64 | tr -d '\n')
  signerName: example.com/serving
  usages:
  - digital signature
  - key encipherment
  - server auth
EOF

请注意，在步骤 1 中创建的 server.csr 文件已进行 base64 编码并存储在 .spec.request 字段中。你还请求一个具有“数字签名”、“密钥加密”和“服务器身份验证”密钥用法的证书，由示例 example.com/serving 签名者签名。必须请求特定的 signerName。有关受支持的签名者名称，请参阅文档。

现在，你可以通过运行以下命令查看 CSR 是否在 API 中处于 Pending 状态

kubectl describe csr my-svc.my-namespace

Name:                   my-svc.my-namespace
Labels:                 <none>
Annotations:            <none>
CreationTimestamp:      Tue, 01 Feb 2022 11:49:15 -0500
Requesting User:        yourname@example.com
Signer:                 example.com/serving
Status:                 Pending
Subject:
        Common Name:    my-pod.my-namespace.pod.cluster.local
        Serial Number:
Subject Alternative Names:
        DNS Names:      my-pod.my-namespace.pod.cluster.local
                        my-svc.my-namespace.svc.cluster.local
        IP Addresses:   192.0.2.24
                        10.0.34.2
Events: <none>

获取 CertificateSigningRequest 批准

批准证书签名请求可以通过自动批准流程或由集群管理员一次性手动完成。如果你有权批准证书请求，可以使用 kubectl 手动执行此操作；例如

kubectl certificate approve my-svc.my-namespace

certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved

你应该看到以下内容

kubectl get csr

NAME                  AGE   SIGNERNAME            REQUESTOR              REQUESTEDDURATION   CONDITION
my-svc.my-namespace   10m   example.com/serving   yourname@example.com   <none>              Approved

这意味着证书请求已获得批准，正在等待请求的签名者对其进行签名。

签名 CertificateSigningRequest

接下来，你将扮演证书签名者的角色，颁发证书并将其上传到 API。

签名者通常会监视 CertificateSigningRequest API，查找具有其 signerName 的对象，检查它们是否已获得批准，为这些请求签名，并使用颁发的证书更新 API 对象状态。

创建证书颁发机构

你需要一个机构来为新证书提供数字签名。

首先，通过运行以下命令创建签名证书

cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
{
  "CN": "My Example Signer",
  "key": {
    "algo": "rsa",
    "size": 2048
  }
}
EOF

你应该看到类似以下的输出

2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR
2022/02/01 11:50:39 [INFO] generate received request
2022/02/01 11:50:39 [INFO] received CSR
2022/02/01 11:50:39 [INFO] generating key: rsa-2048
2022/02/01 11:50:39 [INFO] encoded CSR
2022/02/01 11:50:39 [INFO] signed certificate with serial number 263983151013686720899716354349605500797834580472

这将生成一个证书颁发机构密钥文件 (ca-key.pem) 和证书 (ca.pem)。

颁发证书

tls/server-signing-config.json

{
    "signing": {
        "default": {
            "usages": [
                "digital signature",
                "key encipherment",
                "server auth"
            ],
            "expiry": "876000h",
            "ca_constraint": {
                "is_ca": false
            }
        }
    }
}

使用 server-signing-config.json 签名配置以及证书颁发机构密钥文件和证书来签名证书请求

kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \
  base64 --decode | \
  cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \
  cfssljson -bare ca-signed-server

你应该看到类似以下的输出

2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337

这将生成一个签名的服务证书文件，ca-signed-server.pem。

上传已签名的证书

最后，填充 API 对象状态中的已签名证书

kubectl get csr my-svc.my-namespace -o json | \
  jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \
  kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f -

说明

这使用命令行工具 jq 填充 .status.certificate 字段中的 base64 编码内容。如果你没有 jq，也可以将 JSON 输出保存到文件，手动填充此字段，然后上传结果文件。

一旦 CSR 获得批准并且已签名的证书上传，运行

kubectl get csr

输出类似于

NAME                  AGE   SIGNERNAME            REQUESTOR              REQUESTEDDURATION   CONDITION
my-svc.my-namespace   20m   example.com/serving   yourname@example.com   <none>              Approved,Issued

下载证书并使用它

现在，作为请求用户，你可以下载颁发的证书并将其保存到 server.crt 文件，方法是运行以下命令

kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
    | base64 --decode > server.crt

现在，你可以将 server.crt 和 server-key.pem 填充到 Secret 中，稍后可以将其挂载到 Pod 中（例如，用于与提供 HTTPS 的 Web 服务器一起使用）。

kubectl create secret tls server --cert server.crt --key server-key.pem

secret/server created

最后，你可以将 ca.pem 填充到 ConfigMap 中，并将其用作信任根来验证服务证书

kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem

configmap/example-serving-ca created

批准 CertificateSigningRequests

具有适当权限的 Kubernetes 管理员可以手动批准（或拒绝）CertificateSigningRequests，方法是使用 kubectl certificate approve 和 kubectl certificate deny 命令。但是，如果你打算大量使用此 API，你可能需要考虑编写自动证书控制器。

注意

批准 CSR 的能力决定了你的环境中谁信任谁。不应广泛或轻易地授予批准 CSR 的权限。

你应该确保你充分了解批准者所承担的验证要求以及颁发特定证书的后果，然后再授予 approve 权限。

无论是机器还是使用上述 kubectl 的人，批准者 的角色是验证 CSR 满足两个要求

CSR 的主体控制用于签名 CSR 的私钥。这解决了第三方冒充授权主体的问题。在上面的示例中，此步骤将是验证 Pod 控制用于生成 CSR 的私钥。
CSR 的主体被授权在请求的上下文中操作。这解决了不受欢迎的主体加入集群的问题。在上面的示例中，此步骤将是验证 Pod 被允许参与请求的服务。

只有当满足这两个要求时，审批者才应批准 CSR，否则应拒绝 CSR。

有关证书批准和访问控制的更多信息，请阅读证书签名请求参考页面。

配置集群以提供签名

此页面假定已设置签名者以服务于证书 API。Kubernetes 控制器管理器提供签名者的默认实现。要启用它，请将 --cluster-signing-cert-file 和 --cluster-signing-key-file 参数与您的证书颁发机构的密钥对的路径一起传递给控制器管理器。

最后修改时间：2023 年 10 月 02 日晚上 11:58 PST：更新 jq 链接 (e822502654)