帮助改进此页面
想为本用户指南做出贡献? 滚动到页面底部,然后选择在 GitHub 上编辑此页面。您的贡献有助于我们的用户指南为每个人提供更充分的参考。
使用 Kubernetes 证书保护工作负载
Kubernetes 证书 API 会自动化 X.509CertificateSigningRequest
(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 设置为“legacy-unknown”。如果想使用 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
生成服务证书。将此用作您自己环境的指南。
-
运行
openssl genrsa -out myserver.key 2048
命令以生成 RSA 私有密钥。openssl genrsa -out myserver.key 2048
-
运行以下命令以生成证书请求。
openssl req -new -key myserver.key -out myserver.csr -subj "/CN=myserver.default.svc"
-
为 CSR 请求生成
base64
值,并将其存储在变量中,以便在后续步骤中使用。base_64=$(cat myserver.csr | base64 -w 0 | tr -d "\n")
-
要创建名为
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
-
提交 CSR。
kubectl apply -f mycsr.yaml
-
批准服务证书。
kubectl certificate approve myserver
-
验证证书是否已颁发。
kubectl get csr myserver
示例输出如下。
NAME AGE SIGNERNAME REQUESTOR CONDITION myserver 3m20s beta.eks.amazonaws.com/app-serving kubernetes-admin Approved,Issued
-
导出已颁发的证书。
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):
-
运行以下命令。
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签署人,则您需要批准该请求。 -
手动批准 CSR。将
csr-
替换为您自己的值。7znmf
kubectl certificate approve csr-7znmf
要在将来自动批准 CSR,我们建议您编写一个批准控制器,该控制器可自动验证和批准包含 Amazon EKS 无法验证的 IP 或 DNS SAN 的 CSR。