kubectl は VPN 経由で動くのに AKS のスケーリングが止まる理由

許可された IP 範囲が見るのは VPN サーバーのパブリック出口であり、開発者ではありません。プラットフォームの範囲を追加しないと、変更後に自動化とスケーリングが失敗します。

オフィス VPN のパブリックアドレスを AKS API サーバーの許可リストに追加すると、kubectl は動きます。一週間後、node pool のスケールアップが失敗し、CI ジョブはクラスターに到達できず、ポータルには IP 範囲に一切触れていないエラーが表示されます。許可リストは誰も変更していません。有効にした制御は API サーバーの前にあるパブリック IP フィルターであり、誰が呼んでいるかは分からず、呼び出しがどのアドレスから来たかだけを把握します。VPN はクラスターが必要とする複数のアドレスの一つにすぎず、最初に壊れるのはめったにそれではありません。

許可リストが照合するのはアドレスであり、人ではない

--api-server-authorized-ip-ranges CIDR ブロックを受け取り、ユーザーやグループは受け取りません。開発者のリクエストが VPN サーバーを離れて Azure へ向かうとき、API サーバーでの送信元アドレスは VPN サーバーのパブリック出口です。そのため、その VPN 上の全員が一つのエントリを共有し、VPN の外にいる人は認証が起きる前に拒否されます。

つまり、このエントリは意図したより多くの人を通します。VPN アクセスを持つ請負業者、同じコンセントレーター上の個人用ノート PC、侵害されたアカウントは、すべて同じアドレスから来ます。クラスターの承認は変わらないので、呼び出し元が何をできるかは引き続きロールベースのアクセス制御が決めますが、許可リストは ID 制御ではなく、そう説明すべきでもありません。

最初に壊れるのは通常 kubectl ではない

許可リストは API サーバーのパブリックエンドポイントに適用されるため、登録したアドレスの外にあるものはすべて即座に動かなくなります。明らかな被害者は、VPN ルートのない第二オフィス、ホスト型パイプラインの CI ランナー、接続を忘れたノート PC です。これらは人が待っているので気づきやすいのです。

目立たないのは、Azure や自社ツールが動かす自動化です。プラットフォームが開始する一部の操作は、VPN ではないアドレスから API サーバーに到達します。そして、リストを厳しくした直後にその一つが失敗し始めたら、タイミングが手がかりです。対話的なアクセスが動くからといってリストが完全だと決めつけず、クラスターが壊れていると結論づける前に、その機能がリージョンとサブスクリプションに何を要求するかを確認してください。

失敗の兆候が助けになります。リクエストが認証に達しなければ、それはフィルターです。認証を通ってから権限エラーになるなら、フィルターは役目を果たしており、問題はロールベースのアクセス制御です。許可リストはそこには一切関与しません。

リスト全体を一つのコマンドで作る

更新パラメーターはエントリを追加するのではなくリスト全体を置き換えるため、VPN アドレスだけを持つコマンドは、そこにあった他のすべてを黙って落とします。まず現在の値を読み、それを保持してから、和集合を送ってください。

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

これに依存する前に、VPN サーバーには予約されたパブリック IP を使ってください。動的アドレスは再接続で変わり、変更のたびに、まだ許可されているネットワークから誰かがリストを更新するまで、チームは静かにクラスターの外に締め出されます。冗長性のために VPN の出口が二つあるなら、両方を載せてください。フィルターには優先経路という概念がないからです。

最初の許可された試行がそのままテストになるよう、変更を順序立ててください。新しいリストを告知し、適用し、すぐに VPN から接続します。逆の順序で行うと、CIDR ブロックの打ち間違いを直すために誰も API サーバーへ到達できない時間帯が残ります。

許可リストが決してカバーしなかったもの

これは API サーバーをプライベートにはしません。プライベートクラスターはプライベートエンドポイントとプライベート DNS を使い、許可範囲リストはそれを置き換える制御ではありません。また、許可された呼び出し元ができることも変えないので、漏えいした管理者 kubeconfig は許可されたどのアドレスからでも依然として使えます。資格情報をセキュリティ境界、リストをネットワーク上の利便性として扱ってください。

これはワークロードとは無関係です。リストを有効にしたまま Pods と Services は動き続け、VPN 経由でアプリケーションに到達するのは別問題です。クラスター IP しか持たない Service は、ノート PC が開けるようになる前に、内部ロードバランサー、ingress、port-forward のいずれかを依然として必要とします。この二つの設計を混ぜると、開発者を制限すると称しながらアプリケーションについては何も制限しない変更チケットが生まれます。

両側から検証し、それから実際の操作を一つ実行する

VPN 上の新しいクライアントと、その外のクライアントでテストします。外からの試行は名前解決ではなく API サーバーで拒否されるべきです。名前が解決しないなら、あなたは DNS をテストしているだけで、フィルターについては何も学んでいません。次に、対話的な kubectl 呼び出しではない操作、たとえば node pool のスケールやアップグレード確認を実行し、そうなるだろうと仮定するのではなく完了を確認してください。

変更のそばに以前のリスト値を記録し、入力したコマンドを信じるのではなく、更新後に有効な値を読み直してください。AKS の許可 IP 範囲のドキュメントには、サポートされるパラメーターと、同じリストに入れるべきプラットフォーム要件が列挙されています。多くのチケット説明が省くのはまさにこの部分です。

関連記事