顧客ごとにKubernetesの名前空間を分けたとき、どこまでを「分離できた」と考えてよいのでしょうか。Amazon EKSで複数の顧客を収容するなら、別の顧客のリソースを操作できないことに加え、そのデータへ到達できないことも説明したくなります。

2026年9月18日に公開されたReadyOnの「Four Walls」事例は、この問いを考える材料になります。給与情報などを扱う同社のHarmonyは、名前空間からデータベースまで複数の層で境界を作っています。

その設計を、テナントAのPodからテナントBへアクセスしようとする場面に沿って読み解きます。どの設定が何を止め、どの前提を運用で守る必要があるのかをつなげていきましょう。

名前空間のRBACは、Podの実行場所や通信先まで決めない

名前空間は、テナントごとのリソースを管理する単位です。そこにRBACを設定すると、利用者やServiceAccountが操作できるKubernetes APIリソースを制限できます。一方で、APIの操作権限を分けるだけでは、Podの実行ノードやネットワーク接続先までは決まりません。Kubernetesのマルチテナンシー解説も、名前空間に追加の制御を組み合わせる設計を説明しています。

ReadyOnはこの管理単位を出発点に、専用ノード、VPCの通信制御、専用Auroraクラスターを重ねています。ここで考えたいのは「壁が何枚あるか」よりも、API操作・実行場所・接続先・データへの権限という異なる問いを、それぞれどこで判定するかです。

たとえば、Aの権限でBのSecretをKubernetes APIから読めないとしても、AのPodからBのデータベースへTCP接続できるかどうかは別の問題です。次はまず、そのPodがどのノードで動けるのかを見ていきます。

専用ノードへの配置には、taintと申告内容の検証を組み合わせる

ReadyOnのKarpenter管理ノードには、テナント識別用とワークロード種別用の2つのtaintがあります。Podには両方に対応するtolerationが必要で、admission controllerが、その申告と名前空間のテナント識別情報が一致するかを検証します。

仕組みを単純化すると、tenant=Aとworkload=frontendを持つノードへ、Aのフロントエンド用Podを配置する考え方です。ただし、tolerationは配置を「許す」条件です。そのノードへの配置を「強制する」条件ではありません。専用ノードだけで実行したい場合には、ラベルと必須のnode affinityなども組み合わせます。taintとtolerationの公式説明で、この違いを確認できます。

ここは設定を移植するときに見落としやすいところですね。

KarpenterのNodePool仕様は、1つのPodが複数のNodePoolに一致しない構成を推奨しています。自分の環境では、テナント用以外のNodePoolも含めて配置先を点検し、他テナントのtolerationを申告しても受理されないことを検証したいところです。ReadyOnのadmission policy全文は公開されていないため、同じ2つのtaintを付けるだけで構成を再現できるとは考えられません。

別ノードに分けた後も、Pod間通信とDB接続を個別に閉じる

実行場所が分かれていても、通信経路が開いていれば別のテナントへ接続できます。ReadyOnは名前空間をまたぐ通信にdefault-denyのNetworkPolicyを使い、Aurora側では、対応するテナントのアプリケーションノードのセキュリティグループを接続元として許可しています。

この2つは異なる場所で通信を制御します。NetworkPolicyには、それを実装するネットワークプラグインが必要です。また、適用されるポリシーの許可は足し合わされるため、default-denyを置いても、別の広い許可で接続可能になります。NetworkPolicyの仕様を踏まえ、DNSや共有サービスへの例外も含めて実際の通信を調べる必要があります。

VPC側でも、セキュリティグループは許可ルールで動き、複数を関連付けた場合はルールが合算されます。テナント専用の設定が狭くても、同じリソースに付いた別のグループが広く許可していれば、その経路が残ります。セキュリティグループのルール仕様が、この確認の根拠です。

Auroraではクラスターに関連付けたセキュリティグループが、そのクラスター内のDBインスタンスにも適用されます。したがって、ノード側の接続元とDB側の許可対象を対にして追うと、境界が見えやすくなります。Auroraの接続制御も、このクラスター単位の関係を説明しています。

Auroraの専用化とIRSAで、接続経路と取得できる認証情報を分ける

ReadyOnはテナントごとにAuroraクラスターとSecrets Managerのシークレットを分け、AWS APIへのアクセスにはテナント単位のIRSAロールを使います。データの格納先を分けることに加え、他テナントの認証情報を取得できないようにする構成です。

ここでは、データベースへの接続認証と、AWS APIを呼ぶための認証を区別したいところです。IRSAはKubernetesのServiceAccountにIAMロールを関連付ける仕組みで、導入しただけでAuroraへの接続がIAMデータベース認証になるわけではありません。Auroraのセキュリティ解説でも、管理操作、ネットワーク接続、DBへのログインは別の制御として扱われています。

さらにIRSAの公式資料は、PodからIMDSへアクセスできると、ノードのIAMロールの認証情報も取得できる点を説明しています。ワークロード用ロールを狭くするだけでなく、ノード側の権限とメタデータへの到達性も、同じアクセス経路の一部として点検する必要があります。

専用化は運用の単位も増やします。ReadyOnは可観測性のバックエンドもテナントごとに分けています。この構成を採用するなら、顧客が増えるたびに管理するDBや監視基盤も増える前提で、更新・復旧・費用を見積もりたいところです。これは設計から導く検討事項であり、事例には費用や性能の比較値は示されていません。

GitOpsで境界をそろえ、テナント越境の拒否を継続して確かめる

設定をそろえても、テナント追加や変更で差が生まれると、境界の説明は崩れます。ReadyOnはArgo CD ApplicationSetでテナント用リソースを生成し、GitOpsで宣言した状態へ収束させています。また、テナントPodから別テナントへ越境する試験を継続しています。

この考え方を自分の環境へ持ち込むなら、正常系の疎通と拒否される経路を対にすると、検証結果を解釈しやすくなります。次は、そのための検証項目例です。実測結果を示すものではありません。

検証する経路	同一テナントで確かめる動作	別テナントに対して確かめる拒否
Pod配置	指定した専用ノードで起動する	他テナントを申告した配置要求が通らない
DB接続	必要な接続とクエリが成功する	別テナントのDBへ接続できない
シークレット取得	自分のシークレットを取得できる	別テナントのシークレットを取得できない
可観測性	自分のログやメトリクスを参照できる	別テナントの監視データを参照できない

ただし、四層を完全に独立した防御として数えることはできません。ReadyOn自身も、admission control、GitOps、EKSのコントロールプレーン、IAMには共有する管理基盤があると説明しています。これらを変更できる権限は、複数の境界へ影響し得ます。

冒頭の「どこまで分離できたか」への答えは、名前空間の有無だけでは出ません。どの主体が、どの経路で、どのリソースへ到達できるかを示し、その許可と拒否を変更後も確かめられることが必要です。Four Wallsを設計の参考にする価値は、サービス名を四つ並べることよりも、その説明と検証を運用に組み込む考え方にあります。

出典

• Title: ReadyOn’s Four Walls of tenant isolation on Amazon EKS
• URL: https://aws.amazon.com/blogs/architecture/readyons-four-walls-of-tenant-isolation-on-amazon-eks/