憑證簽署 - Amazon EKS
CSR 範例Kubernetes 1.24 中的 CSR

協助改善此頁面

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

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

憑證簽署

Kubernetes 憑證 API 可實現 X.509 憑證佈建的自動化程序。API 具有一個命令列介面，可供 Kubernetes API 用戶端從憑證授權機構 (CA) 請求和獲取 X.509 憑證。您可以使用 CertificateSigningRequest (CSR) 資源來請求受指示的簽署者簽署憑證。您的請求會在簽署之前獲核准或拒絕。Kubernetes 支援具有明確定義行為的內建簽署者與自訂簽署者。透過這種方式，客戶可以預測其 CSR 會發生什麼情況。如需憑證簽署的相關資訊，請參閱 Certificate Signing Requests (憑證簽署請求)。

其中一個內建簽署者是 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

    如果傳回的輸出顯示具有 kubernetes.io/kubelet-serving 簽署者的 CSR 已 Approved 但尚未 Issued，以用於您的節點，則您需要核准該請求。

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

    kubectl certificate approve csr-7znmf

若要在未來自動核准 CSR，建議您編寫核准控制器，該控制器可自動驗證並核准包含 Amazon EKS 無法驗證之 IP 或 DNS SAN 的 CSR。