【AWS新機能】EKSのCA（証明書機関）自動ローテーション機能が登場！10年の「有効期限切れ」に備える運用のポイントを徹底解説

By /

はじめに

Amazon Elastic Kubernetes Service（Amazon EKS）を利用しているプラットフォームエンジニアやインフラエンジニアの皆さんに、非常に重要なアップデートが届きました。Amazon EKSにおいて、クラスターの証明書機関（CA：Certificate Authority）のローテーション機能がサポートされ、自動化されたライフサイクル管理と保護機能が提供されるようになりました。

2018年にAmazon EKSがローンチされてから約10年が経過しようとしています。実は、EKSクラスターのCAの有効期限は「10年間」に設定されています。つまり、初期の頃から稼働し続けている長寿クラスターは、そろそろCAの有効期限切れという重要なマイルストーンに直面することになります。今回のアップデートは、クラスターの安全な通信を維持しつつ、無停止でのCA更新を強力に支援するものです。

この機能の概要とメリット

各EKSクラスターは、Kubernetes APIサーバーへの暗号化接続をセキュアに行うために、独自のCAを保持しています。このCAが期限切れになると、クラスターへのアクセスやノード間の通信が一切できなくなってしまいます。

今回追加された「CAローテーション機能」には、以下のような大きなメリットがあります。

  • 自動化されたライフサイクル管理： AWSがローテーションのライフサイクルを管理し、AWSマネージドなコンポーネントが新しいCA（後継CA）を自動的に信頼するように更新します。
  • 強力な自動セーフガード（保護機能）： ユーザーが何もしなくても、CAの有効期限が近づくと事前通知が行われます。また、ユーザーが新しいCAを作成しない場合は自動的に後継CAが追加され、手動で有効化（アクティベート）しなかった場合も自動でアクティベーションが実行されます。
  • 安心のロールバック機能： 万が一、ローテーションの移行期間中に接続エラーなどの問題が発生した場合、以前のCAに処理を巻き戻す（ロールバックする）ことができます。
  • 追加費用なし： すべての商用AWSリージョンにおいて、無料で利用可能です。

EKS CAローテーションの「共有責任モデル」

EKSのCAローテーションを安全に行うためには、AWSとユーザーがそれぞれの責任範囲を理解しておく必要があります。まさに「共有責任モデル」が適用される部分です。

AWSが自動で行うこと

  • 新しいCAの生成とライフサイクル管理
  • EKSのコントロールプレーンやAWSマネージドコンポーネント（APIサーバーなど）の更新
  • AWS FargateノードおよびEKS Auto Modeインスタンスの自動更新

ユーザー（あなた）が対応すること

  • ワーカーノードの入れ替え： Managed Node Groups（通常版）やSelf-managedノードを使用している場合、新しいCAを信頼させるためにノードを再作成（ローリングアップデートなど）する必要があります。
  • 外部クライアントの更新： クラスターのAPIサーバーに接続する外部クライアント（開発者のPCの kubeconfig、CI/CDパイプライン、外部の監視ツールなど）に、新しいCAを信頼させるよう更新します。

想定されるユースケース

1. 2018〜2019年頃から稼働している長寿クラスターの延命

長期間稼働し、アップグレードを繰り返しながら維持してきた本番環境のEKSクラスターにおいて、CAの10年期限を迎える前に、安全かつ無停止でCAを更新したい場合。

2. エンタープライズ企業のセキュリティコンプライアンス対応

社内のセキュリティポリシーにより、「暗号化キーやCAは数年ごとに定期ローテーションしなければならない」と規定されている場合。これまでは困難だったEKSクラスターCAの定期運用タスクを自動化プロセスに組み込めます。

使い方と注意点（従来の機能との違い）

これまでは、EKSクラスターのCAをローテーションすることは極めて困難であり、事実上「新しいクラスターを作成してワークロードを移行する」というブルーグリーンデプロイに近い力技が必要でした。今回のアップデートにより、インプレース（既存クラスターのまま）でのローテーションが可能になります。

CAローテーションの流れ（CLIのイメージ）

CAローテーションは、AWSコンソール、AWS CLI、EKS API、AWS CloudFormationから開始できます。例えば、AWS CLIを使用してローテーションを開始・管理するステップは以下のようになります（※実際のコマンドの詳細はAWS公式ドキュメントを参照してください）。

1. ローテーションの開始（新しいCAを準備状態にする）：

aws eks start-ca-rotation --name my-cluster

2. このフェーズで、ユーザーはワーカーノードの更新や外部クライアント（kubeconfig）のアップデートを行います。新旧両方のCAが一時的に信頼される状態になります。

3. 移行が完了したら、新しいCAを完全に有効化（アクティベート）します：

aws eks complete-ca-rotation --name my-cluster

運用の注意点

  • Fargate / Auto Mode 以外のノードは手動対応が必要： Fargateや新機能のEKS Auto ModeはAWSが自動でノードを更新してくれますが、通常のマネージドノードグループや自己管理型ノード（Karpenterなどで管理している場合を含む）は、ノードのローテーション（作成・削除）をユーザー自身が実行する必要があります。
  • クライアントの証明書更新忘れに注意： kubectl を使っている開発者のPCや、GitHub ActionsなどのCI/CDランナーに古いCAが残っていると、最終アクティベーション後にAPIサーバーへの接続ができなくなります。事前のアナウンスと kubeconfig の再配布計画を立てておきましょう。

まとめ

Amazon EKSのCAローテーションサポートは、特に長期間EKSを運用している企業にとって待ちに待った「救世主」とも言えるアップデートです。10年の期限が迫っている古いクラスターを抱えているチームは、ぜひこの機会にテスト環境でCAローテーションの挙動（ノードの入れ替えやロールバックの手順など）を検証し、本番環境のメンテナンス計画に組み込んでみてください！

Related Posts

上部へスクロール