はじめに
2026 年 8 月 20 日、AWS は Amazon EKS に対して certificate authority(CA)rotation を発表しました。クラスターの CA を、有効期限切れ前にマネージドなライフサイクルと自動化されたセーフガードのもとでローテーションできるようになったことが、今回のアップデートの大きな特徴です。
EKS でクラスターを運用している方の中には、「2018 年や 2019 年頃に作ったクラスターを、今も特に手を入れずに使い続けている」というケースもあるのではないでしょうか。今回のアップデートは、この CA の有効期限問題への対応を目的としています。
本記事では、何が変わったのか、CA ローテーションがどのような仕組みで進むのか、そして自社のクラスターがいつ・どのように対応すべきかを中心に解説します。EKS を運用するインフラ・プラットフォームエンジニアの方や、SRE として証明書のライフサイクル管理に関わる方を想定読者としています。
何が変わったのか
Amazon EKS の各クラスターは、Kubernetes API サーバーへの暗号化接続を実現するために、それぞれ独自の CA を持っています。EKS が発表された 2018 年以降に作成されたクラスターの CA は 10 年間の有効期限を持っており、当時作成されたクラスターは、まさに今、その期限が現実味を帯びてくる時期に差し掛かっています。
| 項目 | 従来 | CA rotation 導入後 |
|---|---|---|
| ローテーションの手段 | 標準化された機能はなく、手動かつ複雑な対応が必要 | マネージドなライフサイクルと AWS コンソール・CLI・API から実行可能 |
| 期限切れリスクの管理 | 顧客自身が個別に把握・管理する必要があった | 期限切れ前の事前通知など、自動化されたセーフガードが提供される |
| 移行に失敗した場合の対応 | 明確なロールバック手段がなかった | 前の CA に戻すロールバック機能が用意されている |
従来の課題
これまで EKS には、クラスターの CA を安全にローテーションするための標準化された機能がありませんでした。そのため、CA の有効期限を把握し、期限切れ前に何らかの対応を取るかどうかの判断は、すべて顧客側に委ねられていました。特に 2018 年前後にクラスターを作成し、そのまま長期間運用してきた組織にとっては、CA の期限切れというリスクが十分に可視化されないまま蓄積してきた側面があります。CA が期限切れになれば Kubernetes API サーバーへの接続が成り立たなくなるため、これはクラスターの可用性そのものに関わる問題です。
CA rotation による解決
今回のアップデートにより、EKS が CA ローテーションのライフサイクルを管理し、顧客とのあいだで責任を分担する形が整理されました。
| 責任範囲 | 内容 |
|---|---|
| AWS 側の責任 | ローテーションのライフサイクル管理、AWS 管理コンポーネントの後継 CA への自動更新、EKS Auto Mode インスタンスおよび Fargate ノードの自動更新 |
| 顧客側の責任 | ワーカーノードの置き換え、外部クライアント(kubectl 設定、CI/CD パイプライン、監視ツールなど)を後継 CA を信頼するよう更新すること |
この責任分担を前提に、EKS は以下のセーフガードを提供します。CA の有効期限が近づくと事前に通知が届き、顧客が後継 CA を自ら作成しなかった場合は自動的に追加されます。また、顧客が独自のスケジュールでアクティベーションを行わなかった場合も、AWS 側で自動的にアクティベーションが実行されます。万が一、後継 CA への移行中に問題が発生した場合は、前の CA に戻すロールバック機能も用意されています。
CA rotation は追加コストなしで、すべての商用 AWS リージョンで利用できます。
CA ローテーションの仕組み
CA ローテーションは、いきなり CA が切り替わるわけではありません。「後継 CA の追加」「配布」「アクティベーション」という 3 つのステージを経て進行し、その過程で新旧 2 つの CA が同時に信頼される期間が設けられています。この仕組みによって、クラスターを止めることなく段階的に移行できるようになっています。
ステージ 1:後継 CA の追加
最初のステージでは、クラスターに後継 CA が追加されます。この時点でクラスターは、これまで使ってきた CA(outgoing CA)と、新しく追加された後継 CA の両方を信頼するようになります。ただし証明書の発行自体は、引き続き outgoing CA が行うため、この時点ではまだ何も壊れません。
後継 CA は、クラスターが active 状態であれば、AWS CLI・EKS API・コンソール・CloudFormation などから自分のタイミングで追加できます。もし顧客側が何もしなければ、AWS が自動的に追加します。このステージは、ワーカーノードや外部クライアントの棚卸しを始める良いタイミングでもあります。
ステージ 2:後継 CA の配布
後継 CA が追加されると、AWS はコントロールプレーン、EKS Auto Mode インスタンス、AWS Fargate ノードといった AWS 管理コンポーネントに対して、後継 CA を信頼するよう自動的に更新していきます。この配布の進捗は distribution status として確認でき、配布が完了するまでは次のステージ(アクティベーション)には進めません。
配布が完了した後は、顧客側の番です。顧客が管理するワーカーノードと外部クライアントを、後継 CA を信頼するように更新していく必要があります。
ステージ 3:後継 CA のアクティベーション
すべての AWS 管理コンポーネントへの配布が完了すると、後継 CA をアクティベートできる状態になります。アクティベーションのタイミングは、顧客が自分で管理しているワーカーノードと外部クライアントの更新が終わったことを確認したうえで、自分の裁量で選ぶことが推奨されています。もし顧客が何もしなければ、有効期限が近づいた段階で AWS が自動的にアクティベートします。
アクティベーション後は、クラスターが発行する証明書はすべて後継 CA によって署名されたものに切り替わります。outgoing CA は信頼された状態のまま残りますが、証明書の発行には使われなくなります。この直後には一定期間のロールバックウィンドウが用意されており、問題があれば outgoing CA に戻すことができます。
デュアルトラスト期間
後継 CA が追加されてから outgoing CA が完全に廃止されるまでの期間は、デュアルトラスト期間と呼ばれます。この間、クラスターは 2 つの CA を同時に信頼しているため、ワーカーノードや外部クライアントを一斉に切り替える必要がなく、順番に少しずつ更新していくことができます。これが、CA ローテーションを無停止で進められる理由です。
アクティベーション後、接続がどう変わるか
クライアントが API サーバーに接続する際は、サーバーが提示する証明書が、クライアント自身が信頼している CA によって署名されているかどうかを確認します。後継 CA がアクティベートされると、API サーバーは後継 CA で署名された証明書を提示するようになります。
このとき、事前に後継 CA を信頼するよう更新済みのクライアントは、問題なく接続を確立できます。一方、更新がまだのクライアントは、提示された証明書の署名元を信頼できないため、接続を確立できません。ワーカーノードや外部クライアントをアクティベーション前に更新しておくことが重要なのは、このためです。
なお、最初にクラスター作成時に発行される CA の有効期限は 10 年ですが、ローテーションによって作られる後継 CA からは有効期限が 5 年に変わります。つまり、一度ローテーションを経験したクラスターは、その後 5 年ごとにこのサイクルを繰り返すことになります。
自社クラスターの見極め方
CA ローテーションは、いずれすべての EKS クラスターが通る道です。ここでは、自社のクラスターがいつ頃対応を考えるべきか、そしてその対応を AWS の自動化に任せるか自分たちで主導するか、という 2 つの判断軸について整理します。
いつ着手すべきか
自社クラスターの CA がいつ期限を迎えるかは、describe-certificate-authority で確認できます。2018〜2019 年頃に作成したクラスターであれば、2028〜2029 年頃が一つの目安になります。
自分で何も操作しなくても、AWS は以下のようなスケジュールで通知とセーフガードを提供します。
| タイミング | 内容 |
|---|---|
| CA 有効期限の 2.5 年前 | 期限切れリマインダーの通知が届く |
| CA 有効期限の 2 年前 | 後継 CA が(自分で作成していなければ)自動的に追加される |
| 後継 CA の配布完了後 | AWS 管理コンポーネントへの配布が完了した旨の通知が届く |
| アクティベーションの 60 日前 | もうすぐ自動アクティベーションが行われる旨の警告が届く |
| CA 有効期限の 6 か月前 | (自分でアクティベートしていなければ)後継 CA が自動的にアクティベートされる |
| CA 有効期限の 45 日前 | ロールバック後であっても、この時点で最終的な自動アクティベーションが行われる |
なお、2018〜2019 年に作成されたクラスターについては、この標準スケジュールをそのまま適用すると計算上の起点が今回の機能提供開始よりも前になってしまうため、個別に調整されたスケジュールで通知が届きます。まずは通知が届くのを待つのではなく、describe-certificate-authority で自社クラスターの有効期限を確認しておくことをおすすめします。
自動に任せるか、自主管理するか
CA ローテーションには、大きく分けて 2 つの進め方があります。
1 つ目は、AWS の自動化に任せる方法です。何もしなければ、有効期限の 2 年前に後継 CA が自動的に追加され、6 か月前には自動的にアクティベートされます。EKS Auto Mode インスタンスや Fargate ノードのように AWS が全面的に管理しているコンポーネントであれば、この自動パスだけで完結します。
2 つ目は、自分たちで主導する方法です。create-certificate-authority を使えば、AWS の自動タイムラインを待たずに、任意のタイミングで後継 CA を追加できます。早めに着手するほど、ワーカーノードや外部クライアントの棚卸しと更新に、余裕を持って取り組めます。
ここで意識しておきたいのは、この 2 つの選択が「クラスターが止まるかどうか」ではなく、「個々のクライアントが接続を失うかどうか」に関わってくるという点です。AWS の自動化はクラスター(コントロールプレーン)自体の可用性を守るためのセーフガードであり、これは自動パスでも自主管理パスでも変わりません。しかし、顧客が管理するワーカーノードや外部クライアント側の更新は、どちらのパスを選んでも顧客自身が行う必要があります。自動アクティベーションのタイミングまでにこれらの更新が終わっていなければ、クラスター自体は稼働していても、更新が済んでいないクライアントは API サーバーへの接続を失うことになります。
複数のチームや CI/CD パイプラインが同じクラスターに接続しているような環境では、外部クライアントの洗い出しそのものに時間がかかることが多いため、自動タイムラインに追われる前に自主的に着手しておく方が、落ち着いて対応できます。
有効化の手順
ここからは、実際に AWS CLI を使って CA ローテーションを進める手順を見ていきます。必要なのは AWS CLI バージョン 2.x 以降と、普段 EKS API を呼び出す際に使っている IAM 権限だけです。CA ローテーション専用の追加権限は必要ありません。
現在の CA を確認する
まずは、クラスターに現在設定されている CA を確認します。
aws eks list-certificate-authorities --cluster-name <cluster-name> --region <region>
続けて、その CA の有効期限を確認します。
aws eks describe-certificate-authority \
--cluster-name <cluster-name> \
--certificate-authority-id <ca-id> \
--region <region>
レスポンスの validity.notAfter に有効期限が表示されます。
後継 CA を追加する
準備ができたら、後継 CA を追加します。
aws eks create-certificate-authority --cluster-name <cluster-name> --region <region>
レスポンスに含まれる updateId を使って、処理の進捗を追跡できます。
aws eks describe-update --name <cluster-name> --update-id <update-id> --region <region>
ステータスが Successful になるまで待ちます。
配布状況を確認する
再度 list-certificate-authorities を実行すると、2 つの CA が表示されるようになります。後継 CA の distributionStatus が IN_PROGRESS から COMPLETE に変わるまでは、次のアクティベーションには進めません。
aws eks list-certificate-authorities --cluster-name <cluster-name> --region <region>
kubeconfig を更新する
配布が完了したら、自分の kubeconfig を更新しておきます。
aws eks update-kubeconfig --name <cluster-name> --region <region>
これで、後継 CA がアクティベートされた後も kubectl コマンドが問題なく動くようになります。
ワーカーノードと外部クライアントを更新する
ここが、「顧客側の責任」にあたる部分です。ワーカーノードの種類によって、必要な操作が異なります。
| ワーカーノードの種類 | 必要な操作 |
|---|---|
| マネージドノードグループ |
aws eks update-nodegroup-version でノードグループのバージョン更新を行い、ローリングでノードを入れ替える |
| Karpenter 管理ノード | drift detection が有効なら自動で入れ替わる。無効・期間が長い場合は kubectl cordon / kubectl drain で手動対応 |
| セルフマネージドノード | 起動テンプレートの CA データを更新し、Auto Scaling グループ経由でローリング置換する |
| AWS Fargate | AWS のパッチ処理により Pod が自然に入れ替わるため、対応不要 |
| EKS Auto Mode | AWS が自動更新するため、対応不要 |
外部クライアント(kubectl 設定、CI/CD パイプライン、監視ツールなど)については、以下のコマンドで取得できる最新の CA データを、それぞれの信頼設定に反映します。
aws eks describe-cluster \
--name <cluster-name> --region <region> \
--query 'cluster.certificateAuthority.data' --output text
後継 CA をアクティベートする
管理しているワーカーノードと外部クライアントの更新が終わったら、後継 CA をアクティベートします。
aws eks activate-certificate-authority \
--cluster-name <cluster-name> \
--certificate-authority-id <successor-ca-id> \
--region <region>
アクティベート後は、クラスターが後継 CA で署名した証明書を発行するようになります。kubectl get nodes などを実行して、接続が問題なく維持されているか確認しておくと安心です。
コンソールから行う場合
同じ操作は、Amazon EKS コンソールからも実行できます。CA の状態や有効期限、ローテーションの進捗(追加・配布・ワーカーノードと外部クライアントの更新・アクティベーション・旧 CA の廃止)がガイド付きの画面で確認できるため、CLI に慣れていない場合はこちらが扱いやすいかもしれません。
もし更新前にアクティベートしてしまったら
万が一、ワーカーノードや外部クライアントの更新が終わる前に後継 CA がアクティベートされてしまった場合は、ロールバックで元の CA に戻すことができます。
aws eks activate-certificate-authority \
--cluster-name <cluster-name> \
--certificate-authority-id <previous-ca-id> \
--region <region>
ロールバックが可能かどうかは、describe-certificate-authority の rollbackAvailable フィールドで確認できます。ただし、ロールバックが使えるのは、有効期限 45 日前の最終自動アクティベーションより前に限られる点には注意してください。
まとめ
Amazon EKS の CA rotation は、これまで顧客側が個別に管理するしかなかった CA の有効期限問題に対し、マネージドなライフサイクルと自動化されたセーフガードを提供するアップデートです。後継 CA の追加・配布・アクティベーションという 3 つのステージと、その間のデュアルトラスト期間によって、クラスターを止めることなく段階的に CA を切り替えられるようになっています。
ただし、AWS の自動化が守るのはクラスター自体の可用性までであり、ワーカーノードや外部クライアントの更新は引き続き顧客側の作業として残ります。まずは describe-certificate-authority で自社クラスターの CA 有効期限を確認し、外部クライアントの棚卸しから早めに着手することをおすすめします。