証明書への署名

Kubernetes 認証情報 API により、X.509 認証情報のプロビジョニングを自動化します。この API は、Kubernetes API クライアントが「X.509 証明書」を認証機関 (CA) にリクエストし、取得するためのコマンドラインインターフェイスを備えています。CertificateSigningRequest (CSR) リソースを使用して、示された署名者に証明書への署名を要求できます。リクエストは署名される前に承認または拒否されます。Kubernetes は、明確に定義された動作を持つ組み込み署名者とカスタム署名者の両方をサポートします。この構成により、クライアントは自分の CSR に何が起こるかを予測できます。証明書の署名の詳細については、「signing requests」(リクエストへの署名) を参照してください。

組み込みの署名者の中には、kubernetes.io/legacy-unknown も含まれます。CSR リソースの v1beta1 API では、この未知のレガシー署名者を拒否していません。ただし、CSR の安定版 v1 APIでは、signerName を kubernetes.io/legacy-unknown に設定することはできません。

Amazon EKS バージョン 1.21 以前のバージョンでは、v1beta1 CSR API の signerName として legacy-unknown の値を使用することができました。この 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 とキーの使用の拡張機能を受け入れ、他の拡張機能を破棄します

• 許可された鍵の使用法: ["key encipherment", "digital signature", "server auth"] (鍵暗号化、デジタル署名、サーバー認証) 以外の使用法を含めないでください。

  注記

  クライアント証明書署名はサポートされていません。

• 有効期限/証明書のライフタイム: 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

   返された出力に、ノードに対して Approved ではあるが Issued ではない「kubernetes.io/kubelet-serving」署名者付きの CSR が表示されている場合は、要求を承認する必要があります。

2. CSR を手動で承認します。csr-7znmf を独自の値に置き換えます。

   kubectl certificate approve csr-7znmf
   

将来、CSR を自動承認するには、Amazon EKS で検証できない IP または DNS SAN を含む CSR を自動的に検証および承認できる承認コントローラーを作成することをお勧めします。