使用 Kubernetes 憑證保護工作負載

Kubernetes Certificates 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，CSR API v1beta1 已由 CSR API v1 取代。此 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 "
   ")

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 主體別名 (SANs) kubelet提供憑證，會自動以無法驗證SANs 發出。已佈建的憑證會省略 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，其中 kubernetes.io/kubelet-serving 簽署者是Approved節點Issued的 ，則您需要核准請求。

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

   kubectl certificate approve csr-7znmf

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