このページの改善にご協力ください
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。
Kubernetes 証明書でワークロードを保護する
Kubernetes Certificates API により、X.509CertificateSigningRequest
(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
の配信用証明書の生成方法を示します。これは、実際の環境を構築するためのガイドとして使用できます。
-
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 " ")
-
次のコマンドを実行して、
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
返された出力に、ノードに対して
Approved
ではあるがIssued
ではない kubernetes.io/kubelet-serving署名者付きの CSR が表示されている場合は、要求を承認する必要があります。 -
CSR を手動で承認します。
csr-
を独自の値に置き換えます。7znmf
kubectl certificate approve csr-7znmf
将来、CSR を自動承認するには、Amazon EKS で検証できない IP または DNS SAN を含む CSR を自動的に検証および承認できる承認コントローラーを作成することをお勧めします。