证书签名 - Amazon EKS
CSR 示例Kubernetes 1.24 中的 CSR

证书签名

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。