使用 保護工作負載 Kubernetes certificates - Amazon EKS
CSR 範例CSRs 在 中 Kubernetes 1.24

協助改善此頁面

想要為此使用者指南做出貢獻？ 捲動至此頁面底部，然後在 上選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合所有人。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

使用 保護工作負載 Kubernetes certificates

所以此 Kubernetes 憑證會API自動化 X.509 憑證佈建。API 具有 的命令列介面 Kubernetes API 用戶端向憑證授權單位 （CA） 請求和取得 X.509 憑證。您可以使用 CertificateSigningRequest（CSR） 資源來請求指定簽署者簽署憑證。您的請求在簽署之前獲得核准或拒絕。Kubernetes 支援具有定義明確的行為的內建簽署者和自訂簽署者。如此一來，用戶端可以預測其 會發生什麼情況CSRs。如需憑證簽署的相關資訊，請參閱 Certificate Signing Requests (憑證簽署請求)。

其中一個內建簽署者是 kubernetes.io/legacy-unknown。CSR 資源v1beta1API的 承兌了此舊式未知的簽署者。不過，穩定 v1 API CSR不允許 signerName 設定為 kubernetes.io/legacy-unknown。

Amazon EKS版本 1.21和更早版本允許 legacy-unknown值作為 signerName中的 v1beta1 CSR API。這API可讓 Amazon EKS Certificate Authority （CA） 產生憑證。不過，在 Kubernetes 版本 1.22，v1beta1CSRAPI已由 v1 CSR 取代API。這API不支援「舊版未知」 signerName 的 。如果您想要使用 Amazon EKS CA 在叢集上產生憑證，則必須使用自訂簽署者。它在 Amazon EKS版本 中引入1.22。若要使用 CSRv1API版本並產生新憑證，您必須遷移任何現有的資訊清單和API用戶端。使用現有 建立的現有憑證v1beta1API在憑證過期之前都是有效的 和 功能。這包含下列項目：

  • 信任分佈：無。此簽署者在 中沒有標準信任或分佈 Kubernetes 叢集。

  • 允許的主體：任何

  • 允許的 x509 擴充功能：榮譽 subjectAltName 和金鑰用量擴充功能，並捨棄其他擴充功能

  • 允許的金鑰使用方式：不得包括 [「金鑰加密」、「數位簽章」、「伺服器身分驗證」] 以外的用法

    注意

    不支援用戶端憑證簽署。

  • 到期/憑證生命週期：1 年 (預設和最長)

  • 允許/不允許 CA 位元：不允許

使用 CSR產生範例 signerName

這些步驟說明如何myserver.default.svc使用 產生DNS名稱的服務憑證signerName: beta.eks.amazonaws.com/app-serving。將此作為您自己環境的指南。

  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

In (入) Kubernetes 1.23 和更早版本，使用無法驗證的 IP 和DNS主體別名 （SANs） kubelet提供憑證會自動以無法驗證的 發出SANs。從佈建的憑證中省略 SANs 。在 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的kubernetes.io/kubelet-serving簽署者是節點Issued，Approved但不是節點，則您需要核准請求。

  2. 手動核准 CSR。使用您自己的值取代 csr-7znmf。

    kubectl certificate approve csr-7znmf

若要CSRs在未來自動核准，建議您撰寫核准控制器，該控制器可以自動驗證和核准包含 IP CSRs 或 Amazon EKS 無法驗證DNSSANs的 IP。