证书签名 - Amazon EKS
CSR 示例Kubernetes 1.24 中的 CSR
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

帮助改进此页面

想为本用户指南做出贡献？ 滚动到页面底部，然后选择在 GitHub 上编辑此页面。您的贡献有助于我们的用户指南为每个人提供更充分的参考。

证书签名

Kubernetes 证书 API 会自动化 X.509 凭证预置。API 具有一个命令行界面，供 Kubernetes API 客户端从证书颁发机构（CA）请求和获取 X.509 证书。您可以使用 CertificateSigningRequest（CSR）资源请求指示签署人对证书进行签名。您的请求在签署前被批准或拒绝。Kubernetes 支持内置签署人和具有明确定义行为的自定义签署人。这样，客户端就可以预测 CSR 会发生什么。要了解有关证书签名的更多信息，请参阅签名请求。

内置签署人之一是 kubernetes.io/legacy-unknown。CSR 资源的 v1beta1 API 遵循这个旧版未知的签署人。但是，CSR 的稳定 v1 API 不允许 signerName 被设置为 kubernetes.io/legacy-unknown。

Amazon EKS 版本 1.21 和早期版本允许将 legacy-unknown 值作为 v1beta1 CSR API 中的 signerName。此 API 使 Amazon EKS 证书颁发机构（CA）能够生成证书。但是，在 Kubernetes 版本 1.22 中，v1beta1 CSR API 被 v1 CSR API 替换。此 API 不支持“旧版未知”的 signerName。如果想使用 Amazon EKS CA 在集群上生成证书，则您必须使用自定义签署人。它已在 Amazon EKS 版本 1.22 中引入。要使用 CSR v1 API 版本并生成新证书，必须迁移任何现有清单和 API 客户端。使用现有 v1beta1 API 创建的现有证书在证书到期之前有效且正常运行。这包括以下这些：

  • 信任分配：无。在 Kubernetes 集群中，此签署人没有标准的信任或分配。

  • 允许的主题：任何

  • 允许的 x509 扩展：遵循 subjectAltName 和密钥使用扩展，并丢弃其他扩展

  • 允许的密钥用法：不得包括 [“密钥加密”、“数字签名”、“服务器身份验证”] 以外的用法

    注意

    不支持客户端证书签名。

  • 到期/证书使用寿命：1 年（默认值和最大值）

  • 允许/不允许 CA 位：不允许

使用 signerName 生成 CSR 示例

这些步骤介绍如何使用 signerName: beta.eks.amazonaws.com/app-serving 为 DNS 名称 myserver.default.svc 生成服务证书。将此用作您自己环境的指南。

  1. 运行 openssl genrsa -out myserver.key 2048 命令以生成 RSA 私有密钥。

    openssl genrsa -out myserver.key 2048

  2. 运行以下命令以生成证书请求。

    openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"

  3. 为 CSR 请求生成 base64 值，并将其存储在变量中，以便在后续步骤中使用。

    base_64=$(cat myserver.csr | base64 -w 0 | tr -d "\n")

  4. 要创建名为 mycsr.yaml 的文件，请运行以下命令。在以下示例中，beta.eks.amazonaws.com/app-serving 是 signerName。

    cat >mycsr.yaml <<EOF
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myserver
spec:
  request: $base_64
  signerName: beta.eks.amazonaws.com/app-serving
  usages:
    - digital signature
    - key encipherment
    - server auth
EOF

  5. 提交 CSR。

    kubectl apply -f mycsr.yaml

  6. 批准服务证书。

    kubectl certificate approve myserver

  7. 验证证书是否已颁发。

    kubectl get csr myserver

    示例输出如下。

    NAME       AGE     SIGNERNAME                           REQUESTOR          CONDITION
myserver   3m20s   beta.eks.amazonaws.com/app-serving   kubernetes-admin   Approved,Issued

  8. 导出已颁发的证书。

    kubectl get csr myserver -o jsonpath='{.status.certificate}'| base64 -d > myserver.crt

将集群升级到 Kubernetes 1.24 之前的证书签名注意事项

在 Kubernetes 1.23 及早期版本中，具有不可验证的 IP 和 DNS 使用者备用名称（SAN）的 kubelet 服务证书会自动使用不可验证的 SAN 进行颁发。预置的证书中省略了 SAN。在 1.24 及更高版本的集群中，如果无法验证 SAN，则不会颁发 kubelet 服务证书。这会阻止 kubectl exec 和 kubectl logs 命令发挥作用。

将集群升级到 1.24 之前，请完成以下步骤，以确定集群中是否存在尚未批准的证书签名请求（CSR）：

  1. 运行以下命令。

    kubectl get csr -A

    示例输出如下。

    NAME        AGE   SIGNERNAME                      REQUESTOR                                                  REQUESTEDDURATION   CONDITION
csr-7znmf   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-42-149.region.compute.internal      <none>              Approved
csr-9xx5q   90m   kubernetes.io/kubelet-serving   system:node:ip-192-168-65-38.region.compute.internal      <none>              Approved, Issued

    如果返回的输出显示 CSR，其具有为节点 Approved 而非 Issued 的 kubernetes.io/kubelet-serving 签署人，则您需要批准该请求。

  2. 手动批准 CSR。将 csr-7znmf 替换为您自己的值。

    kubectl certificate approve csr-7znmf

要在将来自动批准 CSR，我们建议您编写一个批准控制器，该控制器可自动验证和批准包含 Amazon EKS 无法验证的 IP 或 DNS SAN 的 CSR。