EKS API を VPN の内側に置く：作業順序

プライベートエンドポイントを有効にし、kubectl がそこに到達したことを証明してから、パブリック側を閉じます。各手順の間のコマンドと確認をまとめた段階的な実行手順です。

この変更の危険なやり方は、一つのコマンドでエンドポイントを切り替え、同時にすべての管理者を締め出すものです。安全なやり方は、両方の経路を開いたままにし、プライベート経路が VPN から機能することを証明してから、はじめてパブリックエンドポイントを廃止します。既存のクラスター、その VPC への承認済みトンネル、すでに機能している kubeconfig を前提とします。目的は Kubernetes API へのプライベートアクセスであり、プライベートノードでも新しい権限モデルでもありません。以下の各手順には、安全に失敗できる確認があります。

1. エンドポイントを棚卸しし、戻る道を確保する

変更する前に現在の状態を記録します。パブリック CIDR の許可リストとクラスターのセキュリティグループも含めます。何かが動かなくなったときに比較するのはこの二つであり、許可リストはプライベート経路が誤っていた場合のロールバック経路でもあります。

aws eks describe-cluster --region REGION --name CLUSTER \
  --query 'cluster.{endpoint:endpoint,public:resourcesVpcConfig.endpointPublicAccess,private:resourcesVpcConfig.endpointPrivateAccess,cidrs:resourcesVpcConfig.publicAccessCidrs}'

ここで REGION と CLUSTER はプレースホルダーです。プライベートフラグが現在何を示しているかを確認してください。プライベートアクセスを有効にして作成されたクラスターは、一度も有効にしたことのないクラスターとは異なる最初の手順が必要です。移行中は、承認済みの管理経路を少なくとも一つ開いたままにします。同じクラスターに到達できることに依存する VPN は復旧経路ではありません。

2. ネットワーク経路を用意してからプライベートアクセスを有効にする

フラグをオンにするのは簡単な半分です。トンネルにはエンドポイントのプライベートアドレスへの経路が必要で、クラスターのセキュリティグループには VPN が実際に提示する送信元からの TCP 443 が必要です。Client VPN の関連付け、サイト間ゲートウェイ、ピア接続された VPC はそれぞれ異なる送信元アドレスを提示するため、一般的なプライベート範囲ではなく、実際にデプロイしたモデルを使ってください。

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

aws eks describe-update --region REGION --name CLUSTER --update-id UPDATE_ID

更新は非同期です。固定の秒数だけ待って決めつけるのではなく、更新 ID が成功を報告するまでポーリングします。その間、ノードとコントロールプレーンのトラフィックには手を付けません。クラスターのセキュリティグループ全体をノート PC 用のルールに置き換えると、稼働中のデータプレーンが二次障害になります。

EKS エンドポイントのドキュメント は一度全文を読む価値があります。プライベート専用のアクセスは VPC または接続されたネットワークから来られる、と書かれているからです。その一文こそがこの移行を可能にする理由であり、次の手順が存在する理由でもあります。

3. ワークステーションがプライベート経路を使ったことを証明する

両方のエンドポイントが有効な状態では、kubectl get ns が成功してもどちらが応答したかは証明できません。エンドポイントのホスト名を解決し、得られたアドレスがプライベート範囲かパブリック範囲かを確認します。接続されたネットワークが DNS 経由でプライベート側の名前解決を受け取らない場合、コマンドはパブリックエンドポイント経由で成功し、誤った証拠でパブリック経路を廃止してしまいます。これがこの移行で最もよくある失敗であり、成功とまったく同じに見えます。

nslookup HASH.gr7.REGION.eks.amazonaws.com
kubectl cluster-info
kubectl get ns --request-timeout=10s

ホスト名と証明書の検証はそのままにします。kubeconfig でプライベート IP に置き換え、TLS 検証を省略するのは、変更記録に書いた移行ではありません。エンドポイントが更新された瞬間にまた失敗します。

4. パブリックアクセスを意図的に廃止する

プライベート経路が実証され、復旧手順が承認されたら、パブリックエンドポイントを閉じます。これはプレビューではなく実際の変更なので、本当に意図したアカウントと設定に対して実行します。

aws eks update-cluster-config --region REGION --name CLUSTER \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

プライベート専用モードでは、パブリック DNS 名は VPC の内側からエンドポイントのプライベートアドレスに解決されるため、名前解決と到達性は同じではなくなります。パブリックアドレスに依存していたもの、たとえば CI ランナーや別ネットワークのノート PC は、それぞれ独自の入口経路が必要になります。

5. ネットワークポリシーとアイデンティティポリシーを分けておく

パブリックアクセスの CIDR リストが制御するのはパブリックエンドポイントだけです。プライベートエンドポイントは制限せず、そちらはクラスターのセキュリティグループと接続ネットワークのポリシーで制限されます。パブリックエンドポイントを残す場合、その許可リストは API クライアントとノードが実際に使うパブリック egress と一致していなければなりません。VPN プールのアドレスがその送信元になることはほとんどありません。

これらのどれも IAM や Kubernetes RBAC を変えません。エンドポイント設定は管理操作であり、一般ユーザーが API に到達するためだけに境界を緩める権限を受け取るべきではありません。最終状態、日付、復旧経路を実行手順に書き、まだ簡単なうちに復旧経路を一度テストします。

関連記事