このページの改善にご協力ください

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「GitHub でこのページを編集する」リンクを選択してください。

EKS クラスターの認証局 (CA) をローテーションする

公開鍵基盤 (PKI) では、認証局 (CA) はデジタル証明書を発行および署名する信頼されたエンティティです。これらの証明書はアイデンティティを確立し、TLS (Transport Layer Security) を使用してシステム間の暗号化通信を可能にします。クライアントがサーバーに接続すると、サーバーは CA によって署名された証明書を提示します。クライアントは、接続を続行する前に、信頼する CA に対してサーバーの証明書を検証します。

Amazon Elastic Kubernetes Service (Amazon EKS) では、クラスター作成時に各 EKS クラスター用の CA が作成されます。これはアップストリーム Kubernetes と同じモデルに従います。各 EKS クラスターには、API サーバーの証明書に署名する独自の CA があります。これにより、コントロールプレーンコンポーネント、ワーカーノード、およびクライアントが API サーバーに対して認証し、EKS クラスターへの暗号化接続を確立できるようになります。

このような認証局 (CA) には、定義された有効期間があります。CA ローテーションは、EKS クラスターの認証局が有効期限切れになる前に置き換え、クラスターが運用可能かつアクセス可能な状態を維持するようにするプロセスです。このプロセスを自動的に管理する組み込みのセーフガードがあります。CA ローテーションを自身で開始しない場合、既存の CA が有効期限切れになる前に後継 CA を自動的に追加して有効化し、クラスターが引き続き利用できるようにします。

CA ローテーション中に、後継 CA が EKS クラスターに追加されます。EKS は、後継 CA をすべての AWS マネージドコンポーネント (コントロールプレーン、EKS Auto Mode インスタンス、および AWS Fargate ノード) に自動的に配布します。お客様は、お客様が管理するワーカーノード (EKS Auto Mode 以外、Fargate 以外) および外部クライアント (kubeconfig ファイルや CI/CD パイプラインなど) を更新して、後継 CA が有効化される前に後継 CA を信頼させる責任があります。後継 CA が有効化されると、EKS クラスターは後継 CA で証明書に署名するように移行します。その後、既存の CA は廃止されます。

CA には有限の有効期間があるため、CA ローテーションはすべての EKS クラスターで必要です。有効期間は、クラスターの CA が作成された時期によって異なります。詳細については、よくある質問のセクションを参照してください。EKS のセーフガードにより、ローテーションのライフサイクル全体を通じてクラスター自体が利用可能な状態に保たれますが、ローテーションを成功させるには、後継 CA の有効化後も接続を維持できるように、お客様が管理するワーカーノードと外部クライアントを更新することも必要です。

以降のセクションで説明する API、コンソールエクスペリエンス、通知、およびステップバイステップのガイダンスは、このプロセスを通じてお客様を支援するように設計されています。責任の全範囲については、責任共有モデルのセクションで説明します。

CA ローテーションの仕組み

Amazon EKS の CA ローテーションは多段階プロセスです。お客様が操作するかどうかに関係なく、ローテーションのライフサイクル全体を通じて EKS クラスターの可用性を維持するための自動セーフガードを用意しています。すべてのコンポーネントが接続を維持できるローテーションを実現するには、以降のセクションで説明する手順を踏む必要があります。

ステージ 1: 後継 CA を追加する

後継 CA が EKS クラスターに追加されます。この時点から、EKS クラスターは既存の CA と後継 CA の両方を同時に信頼します。証明書は引き続き既存の CA によって発行されます。中断は発生しません。

クラスターがアクティブ状態であれば、AWS CLI、EKS API、コンソール、または AWS CloudFormation などの Infrastructure as Code (IaC) を使用して、いつでも自身で後継 CA を追加できます。追加しない場合、当社がお客様に代わって自動的に追加します。

AWS が EKS 内の AWS マネージドコンポーネントへの配布を完了するまで (ステージ 2)、後継 CA を有効化することはできません。この時点が、更新が必要なワーカーノードと外部クライアントの特定を開始するのに適した時期です。EKS クラスターの API サーバーに接続するすべてのシステムを特定するには時間がかかる場合があります。特に、複数のチーム、CI/CD パイプライン、監視ツールがある環境ではその傾向があります。このプロセスを早めに開始すると、独自のスケジュールで更新を調整する柔軟性が最も高まります。

ステージ 2: 後継 CA を配布する

後継 CA が追加されると、AWS は EKS クラスター内のマネージドコンポーネント (コントロールプレーン、EKS Auto Mode インスタンス、および AWS Fargate ノード) を更新して、両方の CA を認識および信頼するようにします。この進捗状況は、CA の配布ステータスで確認できます。配布が完了するまで、後継 CA を有効化することはできません。

当社がマネージドコンポーネントへの CA 配布を完了した後は、お客様には、後継 CA を信頼させるために、2 つのグループ (お客様が管理するワーカーノード (EKS Auto Mode 以外、Fargate 以外) と外部クライアント) を更新する責任があります。これにより、後継 CA の有効化後もそれらが API サーバーに確実に接続し続けられます。後継 CA の有効化前に一部のコンポーネントが更新されていない場合、残りの更新を完了する間、接続を復元するために CA ロールバックを利用できます。

ステージ 3: 後継 CA を有効化する

EKS 内のすべての AWS マネージドコンポーネントへの後継 CA の配布が完了した後、後継 CA を有効化できます。独自のスケジュールで後継 CA を有効化することをお勧めします。お客様が管理するワーカーノードと外部クライアントを検出および更新し、後継 CA を信頼させるのに十分な時間を確保してください。後継 CA を有効化した後、EKS クラスターは後継 CA によって署名された証明書を発行します。既存の CA は引き続き信頼されますが、署名には使用されなくなります。有効化後、限られた期間だけロールバックウィンドウが利用でき、必要に応じて既存の CA に戻すことができます。ロールバックについては、後のセクションで詳しく説明します。

お客様が管理するワーカーノードとクライアントが更新されたことを確認できたら、自身で後継 CA を有効化できます。有効化しない場合、有効期限が近づくと当社が後継 CA を自動的に有効化します。

デュアルトラスト期間

後継 CA を追加してから (ステージ 1)、既存の CA を廃止するまでの期間は、デュアルトラスト期間と呼ばれます。この期間中、EKS クラスターは両方の CA を同時に信頼します。これにより、ローテーションが中断なしで行えるようになります。EKS クラスターはどちらかの CA によって署名された証明書をも受け入れるため、コンポーネントを段階的に更新できます。

デュアルトラスト期間により、すべての変更を同時に調整する必要なく、お客様が管理するすべてのワーカーノードと外部クライアントを特定および更新する時間を確保できます。

後継 CA の有効化が接続にどのように影響するかを理解することが重要です。クライアントが API サーバーに接続すると、サーバーの証明書が信頼する CA によって署名されていることを確認して、サーバーのアイデンティティを検証します。

後継 CA が有効化されると、API サーバーは後継 CA によって署名された証明書を提示します。信頼バンドルを更新して後継 CA を含めたクライアントは、検証に成功し、通常どおり接続できます。信頼バンドルを更新していないクライアントは、サーバーの証明書を認識できず、接続を確立できません。

次の図は、後継 CA の有効化後の TLS 接続フローを示しています。

後継 CA の有効化前にワーカーノードと外部クライアントを更新することが重要なのは、API サーバーのアイデンティティを検証して接続するために、信頼バンドルに後継 CA が必要だからです。デュアルトラスト期間と CA ロールバックは、これを完了するための時間とセーフティネットを提供します。

責任共有モデル

Amazon EKS の CA ローテーションは、AWS 全体に広く適用される同じ責任共有モデルに従います。AWS はクラウドインフラストラクチャのセキュリティと可用性に責任を負い、お客様はその中のワークロードのセキュリティと設定に責任を負います。責任共有が Amazon EKS にどのように適用されるかの詳細については、「EKS のセキュリティのベストプラクティス」を参照してください。

CA ローテーションのコンテキストでは、これは次のことを意味します。

AWS の責任:

お客様の責任:

当社はこれらのアクションをお客様に代わって実行することはできません。外部クライアントは、AWS の運用境界の外に存在します。EKS Auto Mode または Fargate によって管理されていないワーカーノードは、起動時またはお客様のみが制御するブートストラッププロセスを通じて CA 信頼設定が設定されます。これは TLS 信頼の仕組みと一致しています。クライアントは独自のトラストストアを保持し、クライアントの管理者のみがそれを更新できます。

以降のセクションでは、それぞれの側面について詳しく説明します。AWS がお客様のために行うこと、およびお客様が行う必要があることと、その実行方法に関するステップバイステップのガイダンスを扱います。

AWS がお客様のために行うこと

AWS は、EKS クラスターの CA ローテーションのライフサイクル全体を通じて以下を管理します。

CA の自動作成

独自のスケジュールで後継 CA を追加しない場合、EKS クラスターの既存の CA の有効期限が近づくと、当社が自動的に追加します。これにより、有効期限が切れる前にクライアントを検出して更新するための十分な時間を確保して、ローテーションプロセスを開始できます。

コントロールプレーンの更新

当社は EKS クラスターのコントロールプレーンを自動的に更新して、後継 CA を信頼するようにします。後継 CA の有効化後、コントロールプレーンは後継 CA によって署名された証明書を発行します。コントロールプレーンに対してお客様の操作は必要ありません。

EKS Auto Mode と Fargate の更新

当社は EKS Auto Mode ノードと Fargate ポッドを自動的に更新して、後継 CA を信頼するようにします。これらのコンポーネントは当社によって完全に管理されており、CA ローテーション中にお客様の操作は必要ありません。

EKS 機能の更新

当社は EKS 機能 (AWS Controllers for Kubernetes (ACK)、Argo CD、および kro (Kube Resource Orchestrator)) を自動的に更新して、後継 CA を信頼するようにします。これらのマネージドリソースはクラスターの API サーバーと通信し、CA 配布プロセスの一環として更新されます。EKS 機能のマネージドリソースに対してお客様の操作は必要ありません。詳細については、「EKS 機能」を参照してください。

配布ステータスの追跡

当社が EKS クラスター内のマネージドコンポーネントを更新する際、CA の配布ステータスを通じて進捗状況を監視できます。これにより、当社側のローテーションが完了したかどうかを確認できます。配布が完了するまで、後継 CA を有効化することはできません。

組み込みのセーフガード

ローテーション中に EKS クラスターを保護するための組み込みのセーフガードがあります。

このようなセーフガードにより、お客様が操作するかどうかに関係なく、ローテーションのライフサイクル全体を通じて EKS クラスターの可用性が維持されます。

通知

CA ローテーションのライフサイクルの各段階でお客様に通知します。通知は AWS Health、Cluster Insights、および E メールを通じて配信されます。各通知では、何が発生したか、お客様に必要なアクション (ある場合)、および EKS クラスターがローテーションタイムラインのどこにあるかが示されます。

Amazon EventBridge を使用して独自の通知を設定し、CA ローテーションイベントを既存のモニタリングおよびアラートワークフローに統合することもできます。

お客様が行う必要があること (およびその理由)

CA ローテーションを成功させるには、AWS がお客様に代わってアクセスできないコンポーネントを更新する必要があります。これらは 2 つのカテゴリに分かれます。

外部クライアント

クラスターの外部から EKS クラスターの API サーバーに接続するあらゆるシステム。これには、デベロッパーワークステーション、CI/CD パイプライン (Jenkins、GitHub Actions、GitLab、Argo CD)、モニタリングおよびオブザーバビリティツール、オートメーションスクリプト、および kubeconfig を使用して API サーバーと通信するあらゆるアプリケーションが含まれます。

これらのシステムはそれぞれ独自の信頼設定を維持します。後継 CA が有効化されると、API サーバーは後継 CA によって署名された証明書を提示します。後継 CA の有効化前に、これらのクライアントが後継 CA を信頼するように更新することで、接続性が確実に維持されます。クライアントの更新が漏れた場合、CA のロールバックにより、更新が完了するまでアクセスを復元できます。

ワーカーノード (EKS Auto Mode 以外、Fargate 以外)

EKS Auto Mode または Fargate によって管理されていないワーカーノードは、起動時または kubelet ブートストラッププロセスを通じて CA 信頼設定が行われます。これらのノードは、後継 CA を信頼するようにリフレッシュする必要があります。必要なアクションは、ワーカーノードのタイプによって異なります。

マネージドノードグループ

ノードグループのバージョン更新を実行すると、ノードのローリング置き換えがトリガーされます。新しいノードは、更新された CA 信頼設定で自動的にブートストラップされます。

Karpenter 制御ノード

ドリフト検出が有効になっている場合、Karpenter は設定されたドリフトウィンドウ内でノードをサイクルし、新しいノードは手動操作なしで後継 CA を取得します。ドリフト検出が無効になっているか、長いウィンドウに設定されている場合は、これらのノードをセルフマネージド型ノードと同じように扱います。

セルフマネージド型ノード

更新された CA の信頼設定でブートストラップされるように、ノードを置き換えます。通常、これには、更新された CA データで起動テンプレートを更新し、Auto Scaling グループを通じてローリング置き換えをトリガーすることが含まれます。

ハイブリッドノード

各ハイブリッドノードの信頼設定を更新して、後継 CA を含めます。具体的なプロセスは、ハイブリッドノードがどのようにブートストラップされたか、およびその信頼設定がどのように管理されているかによって異なります。

クラスターインサイトを使用して、EKS クラスターで実行されているワーカーノードのタイプを特定できます。各タイプを更新するためのステップバイステップの手順は、後のセクションで説明します。

ワーカーノードの更新が漏れた場合のセーフティネットとして、CA ロールバックを提供しています。ただし、後継 CA の有効化前にすべてのワーカーノードを更新すると、接続の中断を完全に回避できます。後継 CA が有効化される前に更新されていないノードは、置き換えられるか CA ロールバックが実行されるまで、EKS クラスターの API サーバーへの接続を失います。

お客様だけがこれを実行できる理由

外部クライアントは、AWS の運用境界の外に存在します。企業ネットワークで実行されている CI/CD パイプライン、デベロッパーのラップトップ、オンプレミスでホストされているモニタリングツール: AWS にはこれらのシステムにアクセスして信頼設定を更新するメカニズムがありません。

EKS Auto Mode 以外のワーカーノードは、お客様が所有する起動テンプレート、ユーザーデータスクリプト、またはブートストラッププロセスを通じて信頼設定を制御できます。それらを更新するには、ノードを置き換えるか、設定を変更する必要があり、どちらもお客様のインフラストラクチャ内でのアクションです。

これは、現在 Kubernetes で使用されている TLS 信頼モデルの制約です。クライアントが信頼バンドルを更新したかどうかを API サーバーが照会するためのプロトコルレベルのメカニズムはありません。サーバーは、クライアントが接続したときにのみ証明書を提示できます。クライアントが、証明書に署名した CA を信頼している場合、接続は成功します。信頼していない場合、失敗します。AWS がお客様に代わってコンポーネントの準備状況を確認できる、有効化前の検証パスはありません。

いつ開始するか

できるだけ早く外部クライアントの特定を開始してください。これは CA ローテーションの中で最も時間のかかる部分であり、特に複数のチームが EKS クラスターに独立してワークロードをデプロイする環境ではそうです。クライアントの検出を早く開始するほど、プレッシャーなしでチーム間の更新を調整する時間が増えます。

各タイプのクライアントとワーカーノードを更新する方法に関する詳細なガイダンスは、以降のセクションで説明します。

前提条件

CA ローテーションを開始する前に、以下を確認してください。

EKS クラスターの管理に必要な IAM アクセス許可以外に、追加の IAM アクセス許可は必要ありません。現在 EKS クラスターの EKS API を呼び出すことができる場合は、CA ローテーションを実行できます。

開始方法

AWS CLI または Amazon EKS コンソールを使用して CA ローテーションを実行できます。AWS CLI バージョン 2.x 以降を実行していることを確認してください (aws --version で確認)。

AWS CLI の使用

以下のウォークスルーでは、AWS CLI と EKS API を使用したエンドツーエンドの CA ローテーションプロセスについて説明します。

ステップ 1: アクティブな CA を確認する

EKS クラスターのアクティブな認証局を表示します。

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

正常な出力:

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

これは、EKS クラスターの作成時に作成された CA を示します。現在使用中 (証明書に署名) であり、配布が完了しています (EKS 内のすべての AWS 管理コンポーネントがこれを信頼しています)。

ステップ 2: CA の詳細と有効期限を表示する

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

正常な出力:

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

validity ブロックには、CA が作成された日時 (notBefore) と有効期限 (notAfter) が表示されます。rollbackAvailable は、後継 CA の有効化後に以前の CA に戻すことができるかどうかを示します。EKS クラスターで作成された初期 CA の場合、戻す先の以前の CA がないため、これは false になります。

ステップ 3: 後継 CA を追加する

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

これにより、EKS クラスターに後継 CA が追加されます。応答には、進行状況を追跡するために使用できる updateId が含まれます。

ステップ 4: 更新を追跡する

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

更新ステータスが Successful になるまで待機します。

ステップ 5: 配布ステータスを確認する

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

これで 2 つの CA が表示されるはずです。後継 CA には signingStatus: NOT_USED があり、AWS が EKS クラスター内のすべての管理コンポーネントを更新した後、distributionStatus は IN_PROGRESS から COMPLETE に進行します。

後継 CA の配布ステータスが COMPLETE になるまで先に進まないでください。

ステップ 6: kubeconfig を更新する

aws eks update-kubeconfig --name my-cluster --region us-west-2

これにより、ローカルの kubeconfig が両方の CA を信頼するように更新されます。この後、後継 CA が有効化された後も、kubectl コマンドは引き続き機能します。

ステップ 7: お客様が管理するワーカーノードと外部クライアントを更新する

これについては、次のセクションで詳しく説明します。お客様が管理するすべてのワーカーノードと外部クライアントが後継 CA を信頼するように更新されたら、有効化に進みます。

ステップ 8: 後継 CA を有効化する

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

後継 CA を有効化した後、EKS クラスターは後継 CA によって署名された証明書を発行します。接続を確認して、すべてのコンポーネントが期待どおりに動作していることを確認します。

Amazon EKS コンソールの使用

Amazon EKS コンソールは、CA ローテーションのガイド付きエクスペリエンスを提供します。コンソールから直接、CA ステータスの表示、後継 CA の追加、配布の進行状況の監視、後継 CA の有効化を行うことができます。

次の図は、アクティブなローテーション中の Amazon EKS コンソールの認証局の詳細ビューを示しています。アクティブな CA と後継 CA の両方が、署名ステータス、有効期限、および有効期限までの日数とともに表示されます。

次の図は、Amazon EKS コンソールのローテーション進行状況ビューを示しています。ローテーションプロセスの各ステップは、現在の状態とともに表示され、これには追加、配布、ワーカーノードと外部クライアントの更新、有効化、および旧 CA の削除が含まれます。

Kubernetes クライアントを更新する

後継 CA が追加され、AWS が EKS クラスター内の管理コンポーネントへの配布を完了した後 (distributionStatus: COMPLETE)、後継 CA を信頼するように独自のコンポーネントを更新する必要があります。このコンテキストでの「クライアント」とは、EKS クラスターの API サーバーに接続するあらゆるシステムです。これには、ローカルの kubectl 設定、CI/CD パイプライン、モニタリングツール、オートメーションスクリプト、およびワーカーノードが含まれます。

EKS クラスターの更新された CA データ (現在の CA と後継 CA の両方が含まれるようになりました) は、次を使用して取得できます:

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

この値を使用して、以下のサブセクションで各クライアントタイプの信頼設定を更新します。

Kubeconfig (デベロッパーワークステーション、CI/CD パイプライン、オートメーション)

次を実行して、ローカルの kubeconfig を更新します:

aws eks update-kubeconfig --name my-cluster --region us-west-2

これにより、最新の CA データが自動的に取得され、kubeconfig が更新されます。この kubeconfig を使用するすべてのシステムは、両方の CA を信頼します。

独自の kubeconfig を生成する CI/CD パイプラインおよびオートメーションの場合 (例えば、EKS API を直接使用するか、kubeconfig をシークレットとして保存する場合)、describe-cluster から取得した値で certificate-authority-data フィールドを更新します。

マネージドノードグループ

ノードグループのバージョン更新を実行して、ノードのローリング置き換えをトリガーします:

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

新しいノードは、更新された CA データで自動的にブートストラップされます。ローリング置き換えにより、実行中のワークロードを中断することなく、ノードが一度に 1 つずつ置き換えられます。

Terraform または CloudFormation を通じてノードグループを管理している場合、CA ローテーションは IaC 状態にドリフトを発生させません。CA ライフサイクルは、クラスターリソース設定とは別の専用の EKS API を通じて管理されます。CA ローテーションが Infrastructure as Code とどのように相互作用するかの詳細については、「Infrastructure as Code」のセクションを参照してください。

カスタム AMI を使用したカスタム起動テンプレート

ノードグループがカスタム AMI でデプロイされている場合、AWS はユーザーデータをマージしません。更新された CA 信頼バンドルを含む、正しいブートストラップ設定を行う責任はお客様にあります。CA ローテーションはお客様のユーザーデータを自動的に更新せず、後継 CA がないノードはクラスターに参加できません。

ノードが更新後の起動テンプレートで実行されていることを確認する

有効化に進む前に、マネージドノードグループ内のすべてのノードが最新の起動テンプレートバージョンで実行されていることを確認してください。このバージョンには、更新された CA 信頼バンドルが含まれている必要があります。

Karpenter 制御ノード

Karpenter NodePool でドリフト検出が有効になっている場合、Karpenter はノードが古い CA データで実行されていることを自動的に検出し、設定された中断ウィンドウ内でそれらを循環させます。新しいノードは、手動操作なしで後継 CA を取得します。

NodePool の設定でドリフト検出が有効になっていることを確認します:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

disruption が統合ポリシーで設定されている場合、ドリフト検出はデフォルトで有効です。Karpenter は、望ましい状態からドリフトしたノードを置き換えます。これには CA データの変更が含まれます。

ドリフト検出が有効になっている場合は、中断予算によって、後継 CA の有効化日より前にすべての Karpenter 制御ノードが置き換えられることを確認します。予算が過度に制限されている場合 (例えば、置換率の低い狭いメンテナンスウィンドウ)、期限内に置き換えられないノードがある可能性があります。

ドリフト検出が無効になっている場合、または中断予算がローテーションのタイムラインを超えるウィンドウに置換を制限している場合は、ノードを遮断およびドレインすることで手動でノードの置換をトリガーできます:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter は、更新された CA データでブートストラップする置換ノードをプロビジョニングします。

セルフマネージド型ノード

セルフマネージド型ノードの場合は、ノードがブートストラップ時に使用する起動テンプレートまたはユーザーデータスクリプト内の CA データを更新する必要があります:

新しいノードは、更新された CA データでブートストラップし、現在の CA と後継 CA の両方を信頼します。

AWS Fargate ポッド (EKS Fargate 起動タイプ)

EKS クラスター内の AWS Fargate ポッドは、他の EKS データプレーンの起動モード (マネージド型ノードグループ、セルフマネージド型ノード、Karpenter 制御ノード) とは異なる動作をします。

ポッドが API サーバーに接続すると、2 つのことが起こります。ポッドはサービスアカウントトークンを使用して自身を認証し (API サーバーに対して自身のアイデンティティを証明)、ポッドはサーバーの証明書が信頼する CA によって署名されていることを確認することで API サーバーのアイデンティティを検証します。ポッドの環境に保存されている CA データが、この検証を可能にします。API サーバーが、ポッドが信頼していない後継 CA によって署名された証明書を提示し始めると、ポッドは接続を拒否します。

他の EKS データプレーンの起動モード (マネージド型ノードグループ、セルフマネージド型ノード、Karpenter 制御ノード) では、CA データはノード上に存在します。ノードを置き換えると、新しいノードは更新された CA データでブートストラップします。その新しいノードにスケジュールされたポッドは、更新された CA データを受け取り、どの CA が証明書に署名したかに関係なく API サーバーを検証できるようになります。

Fargate では、各ポッドは独自の kubelet プロセスで専用のコンピューティング環境で実行されます。この kubelet は、ポッドの作成時の CA データでブートストラップします。その下に共有ノードはなく、基盤となるコンピューティングに直接アクセスすることはできません。

CA ローテーション中、EKS の AWS Fargate ノードに対してお客様の操作は必要ありません。 AWS は、パッチ適用プロセスを通じて Fargate ノードのポッドを自然にリサイクルします。後継 CA が追加されると、既存の Fargate ポッドはこのプロセスの一部としてリサイクルされます。お客様が何も操作しなくても、それらは後継 CA を信頼するようになります。AWS は、EKS で AWS が開始する CA 有効化のタイムラインよりもはるかに早く後継 CA を追加するため、AWS が後継 CA を有効化するまでに、Fargate ポッドはリサイクルされ、後継 CA を信頼するようになります。Fargate ポッドがリサイクルを完了するまで後継 CA の有効化を防ぐ組み込みのセーフガードがあります。

つまり、EKS クラスターの両方のマネージドデータプレーンオプション (EKS Auto Mode と Fargate) は、CA ローテーションに関して同じユーザーエクスペリエンスを持ちます。ワーカーノードに対してお客様の操作は必要ありません。API サーバーに接続する外部クライアントの更新については、引き続きお客様の責任となります。

これはエッジケースです。ローテーションのタイムライン (有効期限の数年前に後継 CA が追加される) を考慮すると、大多数のシナリオで、自然なパッチ適用サイクルは後継 CA の有効化よりもはるかに早く完了します。このセーフガードは、お客様が早期に有効化を試みるという可能性の低いケースに対する予防措置として存在します。

外部クライアント (監視ツール、サードパーティ統合)

kubeconfig または証明書信頼設定を使用して EKS クラスターの API サーバーに接続するアプリケーションまたはツールは、更新された CA データで更新する必要があります。これには、以下が含まれます。

これらのそれぞれについて、保存されている CA データを describe-cluster からの更新された値に置き換えます。

クライアントが更新されたことを確認する方法

クライアントを更新した後、それが API サーバーとまだ通信できることを確認します:

kubectl get nodes

コマンドが成功した場合、kubeconfig はアクティブな CA データを信頼します。後継 CA の有効化後に、同じコマンドを実行して接続が継続していることを確認します。

Infrastructure as Code

ドリフトを作成したり、IaC 設定の変更を必要としたりすることなく、既存の Infrastructure as Code (IaC) と併せて CA ローテーションを実行できます。

CA ローテーションが IaC の状態に影響しない理由

CA のライフサイクルは、EKS クラスターリソースの設定とは完全に別個の専用 EKS API (create-certificate-authority、activate-certificate-authority、delete-certificate-authority) を通じて管理されます。CA ローテーションがお客様によって開始されるか、AWS によって自動的に開始されるかに関係なく、EKS クラスターリソース上で IaC ツールが追跡するプロパティは変更されません。

つまり、次のようになります。

describe-cluster によって返される certificateAuthority.data フィールドは読み取り専用の出力です。これは現在の結合された信頼バンドル (デュアルトラスト期間中は両方の CA) を反映しますが、設定可能なプロパティではありません。IaC ツールは、それを調整すべきものとして追跡しません。

各 CA レコードの属性フィールド (createdBy、activatedBy) を使用すると、お客様が開始した操作と AWS が自動的に開始した操作を区別でき、監査および変更管理のワークフローをサポートします。

CA ローテーションで CloudFormation を使用する

CA ローテーションは、AWS::EKS::Cluster リソースの WriteOnly プロパティを使用して CloudFormation を通じてトリガーできます。このプロパティは有効化をトリガーしますが、スタックの状態には保存されないため、これを含まない後続のスタック更新で元に戻したり無効化したりしようとすることはありません。

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

この最初のスタック更新は、クラスターに後継 CA を追加します。続行する前に、後継 CA の配布ステータスが COMPLETE に達するまで待ちます。

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

この 2 回目のスタック更新は、後継 CA の有効化をトリガーします。ActiveCertificateAuthorityId は WriteOnly プロパティであるため、読み取り時に返されず、CloudFormation 外でアクティブ CA が変更された場合 (例えば、AWS による自動有効化)、CloudFormation はドリフトを検出しません。

重要: CA ローテーションの CloudFormation 統合は、一般的な CloudFormation リソースとは異なるパターンに従います。EKS の認証局は、独自の ARN を持つ独立したリソースではありません。これはクラスターの証明書ライフサイクルの一部として存在し、クラスター自体を通じて承認されます。これは、IAM ロールポリシーが親ロール (AWS::IAM::RolePolicy) を通じて承認される方法や、EIP 関連付けがインスタンス (AWS::EC2::EIPAssociation) を通じて承認される方法に似ています。CloudFormation を通じて CA ローテーションを管理するお客様は、この違いを認識しておく必要があります。

マネージドノードグループと IaC

更新された CA 信頼設定でノードを更新するためにノードグループのバージョン更新を実行することは、運用アクションです。新しいノードは、クラスターからのアクティブな CA 信頼データで自動的にブートストラップします。IaC テンプレートが起動テンプレートまたはユーザーデータに CA データをハードコードしていない場合、テンプレートの変更は必要ありません。

CA ロールバック

後継 CA を有効化した後、管理するワーカーノード (EKS Auto Mode 以外、Fargate 以外) または外部クライアントで接続の問題が発生した場合、以前の CA にロールバックできます。ロールバックすると、EKS クラスターの署名機関として以前の CA が再び有効化されます。

CA ロールバックが利用可能な場合

CA ロールバックは、次の条件が満たされる限り、CA の有効化後に利用できます:

describe-certificate-authority によって返される rollbackAvailable フィールドを使用して、CA ロールバックがいつでも利用可能かどうかを確認できます:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

CA ロールバックが利用できない場合

最終自動有効化後は、CA ロールバックは利用できません。AWS が後継 CA を最後に有効化する場合 (CA の有効期限の 45 日前)、ローテーションは前進させなければなりません。最終自動有効化は、最初の自動有効化が以前にロールバックされた場合にのみ発生します。これは、有効な CA が設定されていないまま EKS クラスターが CA の有効期限に達しないようにするための最後の手段のセーフガードとして存在します。

ロールバックする方法

ロールバックするには、以前の CA を再び有効化します:

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

CA ロールバック中に何が起こるか

CA ロールバックを検討すべき場合

CA ロールバックは、後継 CA の有効化によって事前に把握できなかった接続の問題が明らかになった状況に対する安全メカニズムです:

ロールバック後は、後継 CA を再び有効化する前に問題を特定して修正するための完全なデュアルトラスト期間が保持されます。

CA ロールバックなしでの復旧

マネージドノードグループを更新する前に後継 CA を有効化し、CA ロールバックウィンドウが利用できなくなった場合 (例えば、最終自動有効化の期限後)、影響を受けるノードグループでローリング更新を実行することで復旧できます。ただし、切断されたノードは API サーバーからポッドのエビクションコマンドを受信できないため、最初のローリング更新の試行は失敗します。

復旧手順

考慮事項と制限事項

リージョン別の可用性

CA ローテーションは、Amazon EKS がサポートされているすべての AWS 商用リージョンで利用できます。

最大 2 つの CA

EKS クラスターは、いつでも最大 2 つの CA (アクティブ CA と 1 つの後継 CA) を持つことができます。以前のローテーションが完了するまで、2 つ目の後継 CA を追加することはできません。

証明書の失効なし

CA ローテーションは、個々の証明書の失効をサポートしていません。これは、証明書の失効 (CRL または OCSP) を実装していないアップストリームの Kubernetes と一致しています。ローテーションは CA 全体を置き換え、これにより、旧 CA が信頼バンドルから削除された後、旧 CA によって署名されたすべての証明書が自然に無効になります。

AWS が追加した CA は削除できません

AWS が後継 CA を自動的に追加した場合、それを削除することはできません。このセーフガードにより、誤った削除によってローテーションプロセスが中断されないようにします。お客様が追加した CA は、アクティブな署名 CA でない限り削除できます。

CA の有効期間

クラスターとともに作成された元の CA の有効期間は 10 年間です。ローテーションプロセスを通じて作成された後継 CA の有効期間は 5 年間です。クラスターの今後のすべての CA の有効期間は 5 年間です。describe-certificate-authority を使用して CA の有効期限を確認します。

デュアルトラスト期間中の EC2 ユーザーデータサイズ

デュアルトラスト期間中は、2 つの CA 証明書が含まれるため、クラスターの信頼バンドルのサイズが増加します (合計で約 2.8 KB、gzip 圧縮では約 1.9 KB)。カスタムユーザーデータが EC2 起動テンプレートで提供されるワーカーノードの場合、合計ユーザーデータサイズが EC2 ユーザーデータの制限である 16KB を超えていないことを確認します。既存のユーザーデータがこの上限に近い場合、2 つ目の CA の追加により起動テンプレートの作成が失敗し、新しいノードがプロビジョニングされなくなる可能性があります。サイズを削減するために、gzip を使用してユーザーデータの内容を圧縮することを検討してください。

CA ローテーション中のバージョンアップグレード

EKS クラスターのバージョンアップグレードと CA ローテーションは独立した操作です。ただし、両方を同時に実行することはできません。CA ローテーション操作が進行中の場合、CA 操作が完了するまでバージョンアップグレードは拒否され、その逆も同様です。

BYOCA (自分の CA を使用する)

独自の AWS プライベート CA を使用して EKS クラスターの証明書を支えることは、現在サポートされていません。

よくある質問

CA ローテーションを開始するにはどうすればよいですか?

開始するには、aws eks list-certificate-authorities --cluster-name my-cluster を実行してアクティブな CA とその有効期限を表示します。ローテーションを開始する準備ができたら、aws eks create-certificate-authority --cluster-name my-cluster を実行して後継 CA を追加します。段階的なプロセス全体は「開始方法」セクションで説明されています。Amazon EKS コンソールを通じて CA ローテーションを実行することもできます。

CA ローテーションに関連するコストは発生しますか?

いいえ。CA ローテーションは、すべての EKS クラスターで追加コストなしに利用できます。

CA の有効期限が切れる前に CA をローテーションしないとどうなりますか?

有効な CA が存在しない状態で EKS クラスターが CA の有効期限切れに達することを防ぐ自動保護機能があります。お客様自身が CA ローテーションを開始しない場合、有効期限が切れる前に後継 CA を自動的に追加して有効化し、クラスターが引き続き利用できるようにします。

ただし、ローテーションを成功させるには、お客様が管理するワーカーノード (EKS Auto Mode 以外、Fargate 以外) と外部クライアントを、後継 CA を信頼するように更新する必要もあります。これらのコンポーネントが後継 CA の有効化前に更新されていない場合、API サーバーへの接続性を失います。

Kubernetes では、CA の有効期限が切れる前に CA をローテーションしないと、その CA によって署名されたすべての証明書が無効になります。どのクライアントからも API サーバーに到達できなくなり、クラスターは利用できなくなります。

CA ローテーションを完了するためにどのくらいの時間がありますか?

CA ローテーションを完了するまでの総時間は、AWS の自動保護機能とお客様自身の更新プロセスの両方に左右されます。

AWS は、自らが管理する対象について確実なタイムラインを示します。後継 CA は、既存の CA の有効期限が切れる約 2 年前に追加されます。お客様自身が後継 CA を有効化しない場合、有効期限の約 6 か月前に自動的に有効化します。自動有効化後にロールバックした場合、有効期限の 45 日前に最終自動有効化を実行します。これらの保護機能により、お客様が操作するかどうかに関係なく、EKS クラスターは利用可能なままです。

CA ローテーションを成功させるには、後継 CA の有効化前に、お客様が管理するワーカーノード (EKS Auto Mode 以外、Fargate 以外) と外部クライアントを後継 CA を信頼するように更新することも必要です。これにかかる時間は、データプレーンのワーカーノード設定、外部クライアントの規模、およびこれらのコンポーネントの検出と更新にかかる時間に左右されます。

CA ローテーションによってクラスターにダウンタイムが発生しますか?

いいえ。EKS クラスターは、CA ローテーションライフサイクル全体を通じて引き続き利用できます。コントロールプレーンは、すべての段階でリクエストの処理を続けます。デュアルトラスト期間中は、既存の CA と後継 CA の両方が同時に信頼されるため、クラスター運用を中断することなくコンポーネントを段階的に更新できます。クライアント側の問題を検出したために以前の CA にロールバックした場合、AWS はセーフガードとして、既存の CA の有効期限が切れる約 45 日前に最終ロールフォワードを実行します。

EKS クラスター (コントロールプレーン) とデータプレーンコンポーネントを区別することが重要です。コントロールプレーンは AWS によって完全に管理されており、ローテーション中も利用可能なままです。

EKS Auto Mode と Fargate の場合、AWS がワーカーノードを自動的に更新します。これらのデータプレーン起動モードでは、ワーカーノードの接続性が失われるリスクはありません。API サーバーに接続する外部クライアントの更新については、引き続きお客様の責任となります。

マネージド型ノードグループ、セルフマネージド型ノード、Karpenter 制御インスタンス (ドリフト検出が有効になっていない場合)、およびハイブリッドノードでは、後継 CA の有効化前にそれらのノードを置き換えるか更新する責任はお客様にあります。置き換えられていない場合、コントロールプレーン自体は完全に動作し続けますが、後継 CA の有効化後にそれらのノードはコントロールプレーンへの接続を失います。

CA ローテーション中にワークロードは中断されますか?

実行中のワークロード (ポッド) は、CA ローテーション自体によって中断されません。ポッドはクラスターネットワークを通じて相互に通信し、このネットワークは CA の変更による影響を受けません。CA は、コンポーネントと API サーバー間の通信に使用され、ポッド間トラフィックには使用されません。

後継 CA を信頼するようにワーカーノードを更新する一環としてノードを置き換える必要がある場合 (例えば、マネージド型ノードグループがローリング更新を実行する場合や、Karpenter がドリフトしたノードを置き換える場合)、それらのノード上のポッドは通常のノード置き換えプロセスの一部として再スケジュールされます。これはノード置き換え時の標準的な Kubernetes の動作であり、CA ローテーションの副作用ではありません。ノード置き換え時にポッドがどのようにエビクションされるかを制御するため、重要なワークロードにはポッド中断予算 (PDB) を設定するようにしてください。

クラスターの CA の有効期限はいつ切れますか?

クラスターの CA の有効期限がいつ切れるかは、AWS CLI、EKS API、または Amazon EKS コンソールを使用して確認できます。例えば、次のコマンドを実行できます。

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

aws eks list-certificate-authorities --cluster-name my-cluster を実行して、CA の ID を確認できます。

クラスターの CA の有効期間はどのくらいですか?

クラスターとともに作成された元の CA の有効期間は 10 年間です。ローテーションプロセスを通じて作成された後継 CA の有効期間は 5 年間です。クラスターの今後のすべての CA の有効期間は 5 年間です。describe-certificate-authority を使用して、CA の有効期限を確認できます。

AWS が自動的に実行する前に、自分で CA ローテーションを開始できますか?

はい。aws eks create-certificate-authority --cluster-name my-cluster を使用して、いつでも後継 CA を追加できます。AWS がローテーションを開始するのを待つ必要はありません。早期に開始すると、自分のスケジュールでワーカーノードと外部クライアントを特定して更新するための時間をより多く確保できます。

後継 CA を有効化した後にロールバックできますか?

はい。後継 CA の有効化後でも、ロールバックウィンドウが期限切れになっていなければ、CA ロールバックを利用できます。CA ロールバックは、以前の CA を署名機関として再度有効化します。最終自動有効化後 (CA の有効期限切れの 45 日前) は利用できません。describe-certificate-authority を使用して、CA の rollbackAvailable フィールドを確認できます。詳細については、CA ロールバックのセクションを参照してください。

後継 CA を有効化しても安全な時期は、どうすればわかりますか?

お客様が管理するすべてのワーカーノード (EKS Auto Mode 以外、Fargate 以外) と外部クライアントが後継 CA を信頼するように更新されたら、後継 CA を有効化しても安全です。これを確認するには、各クライアントが更新された信頼設定を使用して API サーバーと正常に通信できることを確認します。AWS は外部システムを参照できないため、すべてのクライアントの準備が完了したことを示す単一の指標は提供しません。すべてのクライアントを特定する時間を確保するために、できるだけ早く検出プロセスを開始してください。

複数のクラスターにまたがる CA ローテーションの進行状況を監視するにはどうすればよいですか?

AWS CLI または EKS API を使用して、プログラムでこれを実行できます。各クラスターに対して aws eks list-certificate-authorities を使用します。次のフィールドは、フリートレベルの監視における状況把握に役立ちます。

次のサンプルスクリプトは、クラスターのリスト全体で CA ローテーションのステータスを確認します。

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

これを拡張して複数のリージョンとアカウントを対象にし、後継 CA が追加されているクラスター、お客様の操作を待っているクラスター、または自動有効化の期限が近づいているクラスターをフィルタリングできます。

通知は、ローテーションライフサイクルの各段階で、AWS Health とメールを通じてクラスターごとにも配信されます。

すべてのクライアントを更新する前に後継 CA を有効化するとどうなりますか?

後継 CA を信頼するように更新されていないクライアントは、EKS クラスターへの接続性を失います。後継 CA の有効化後、API サーバーは後継 CA によって署名された証明書を提示します。それを信頼しないクライアントは TLS 検証に失敗し、接続できなくなります。これが発生した場合は、以前の CA にロールバックして (ロールバックウィンドウがまだ利用可能な場合)、残りのクライアントを修正する間、接続を復元できます。

CA の有効期限に間に合わなかった場合はどうなりますか?

AWS がこれを防ぎます。自動保護機能により、有効な CA が存在しない状態で EKS クラスターが CA の有効期限切れに達することはありません。お客様が追加していない場合は当社が後継 CA を追加し、有効期限の約 6 か月前に自動的に有効化します。最初の自動有効化後にロールバックした場合、AWS は有効期限の 45 日前に最終ロールフォワードを実行します。クラスターは引き続き利用可能です。

ただし、自動有効化が発生するまでに、お客様が管理するワーカーノード (EKS Auto Mode 以外、Fargate 以外) と外部クライアントが後継 CA を信頼するように更新されていない場合、それらのコンポーネントは API サーバーへの接続を失います。

CA ローテーション中にクラスターへのアクセスを失うことはありますか?

EKS クラスター (コントロールプレーン) は、CA ローテーションライフサイクル全体を通じて利用可能なままです。AWS のセーフガードにより、クラスター自体が利用できなくなることはありません。

ただし、お客様が管理する個々のクライアントは、後継 CA の有効化前に後継 CA を信頼するように更新されていない場合、アクセスを失う可能性があります。例えば、kubeconfig、CI/CD パイプライン、または監視ツールが依然として既存の CA のみを参照している場合、後継 CA の有効化後にそれらのクライアントは接続できなくなります。これが発生した場合、影響を受けるクライアントを更新する間、CA ロールバックによってアクセスを復元できます。

ポッドを再起動する必要はありますか?

実行中のワークロードポッドは、CA ローテーションによる直接的な影響を受けません。各ノードの kubelet が API サーバーとの通信を処理するため、ノードが更新されている限り、ワークロードポッドは中断なく実行され続けます。ただし、client-go を使用して API サーバーと通信するクラスター内のコントローラーとオペレーターは、後継 CA の有効化後に再起動が必要になる場合があります。client-go は CA 信頼バンドルを動的に再読み取りしないためです。特に AWS Fargate ノードの場合、AWS が通常のポッドリサイクルプロセスを通じて更新を自動的に処理します。

ローテーション中に信頼バンドルは変更されますか?

はい。CA ローテーション中、クラスターの信頼バンドルには、既存の CA と後継 CA の 2 つの認証局が同時に含まれます。これはデュアルトラスト期間中の想定された動作であり、ローテーションプロセスがすべてのコンポーネントの接続性を維持する方法です。

アプリケーションとクライアントは、単一の CA 証明書にピン留めするのではなく、CA バンドルを信頼するように設定する必要があります。CA のピン留め (単一の CA に対する厳密な検証) は、信頼バンドルが更新されたときに障害を引き起こすため、推奨されません。これは、EKS クラスターの API サーバーに接続するすべてのクライアント側 TLS 設定に適用されます。

通知のタイムラインがこのドキュメントの説明と異なるのはなぜですか?

クラスターが 2018 年から 2019 年に作成された場合、クラスターは調整されたタイムラインで自動通知を受け取ります。最初の通知には、クラスターに固有の関連日付と次のステップが含まれます。標準の通知マイルストーンは、クラスターの CA の有効期限を基準に計算されます。この範囲のクラスターでは、計算された日付がこの機能の提供開始より前になるため、調整されたスケジュールが適用されます。