はじめに
2026 年 4 月 20 日、AWS は Amazon Elastic Kubernetes Service（EKS）のクラスター作成・設定 API に対して、7 つの新しい IAM 条件キーを追加する機能拡張を発表しました。
これにより、IAM ポリシーおよび Service Control Policies（SCP）を通じて、クラスターのエンドポイントアクセス設定・暗号化・バージョン管理・削除保護といった構成を、ポリシーレベルで制御できるようになります。
本記事では、「何が変わったのか」「どんな課題が解決されるのか」を中心に解説します。EKS クラスターを運用しているエンジニアや、マルチアカウント環境のセキュリティ・コンプライアンス管理に関心のある方はぜひ読んでみてください。
新機能の概要
今回のアップデートを一言で表すと、「EKS クラスターの設定をポリシーで縛れるようになった」 ということです。
以下の 7 つの IAM 条件キーが新たに追加されました。
| 条件キー | 制御できること |
|---|---|
eks:endpointPublicAccess |
パブリック API エンドポイントの有効 / 無効 |
eks:endpointPrivateAccess |
プライベート API エンドポイントの有効 / 無効 |
eks:encryptionConfigProviderKeyArns |
シークレット暗号化に使用する KMS キー |
eks:kubernetesVersion |
使用を許可する Kubernetes バージョン |
eks:deletionProtection |
クラスターの削除保護の有効 / 無効 |
eks:controlPlaneScalingTier |
コントロールプレーンのスケーリングティア |
eks:zonalShiftEnabled |
ゾーナルシフト機能の有効 / 無効 |
これらの条件キーは、IAM ポリシーの Condition ブロックに記述することで動作します。特に AWS Organizations の SCP（Service Control Policies）と組み合わせることで、複数の AWS アカウントにまたがって一貫したポリシーを強制できる点が大きなポイントです。
追加料金は発生せず、全 AWS 商用リージョンで即日利用可能です。
IAM 条件キーとは？
IAM ポリシーのConditionブロックで使用できるキーで、API リクエストのパラメーター値などをもとにアクセス可否を制御する仕組みです。eks:プレフィックスを持つものが EKS 固有の条件キーになります。4章以降で具体的な動作イメージをつかんでいただけます。
何が変わったのか
従来の課題
これまで EKS クラスターのセキュリティ設定を組織全体で統一するには、大きな壁がありました。
IAM の権限でできるのは「クラスターを作れるか・作れないか」という粒度の制御までで、「どんな設定のクラスターを作れるか」までは踏み込めませんでした。たとえば、「パブリックエンドポイントを有効にしたクラスターは作らせたくない」「KMS キーなしの暗号化なしクラスターはブロックしたい」といったポリシーをデプロイ前に強制する手段がなかったのです。
そのため多くの組織では、クラスターが作られた後に AWS Config のルールで設定違反を検知し、アラートを飛ばして手動で修正する、という事後対応のフローに頼らざるを得ませんでした。マルチアカウント環境ではこの管理がさらに複雑になり、各アカウントへの個別対応が運用負荷を押し上げていました。
今回のアップデートで何が変わるか
今回追加された 7 つの IAM 条件キーにより、クラスターの設定内容そのものをポリシーで制御できるようになりました。
SCP に条件キーを組み込むことで、条件を満たさない API リクエストをデプロイ前に自動でブロックできます。設定違反のクラスターはそもそも作成されないため、事後の検知・修正サイクルから脱却できます。
| 観点 | 変更前 | 変更後 |
|---|---|---|
| ガバナンスの方向 | 事後検知（AWS Config でチェック） | 事前ブロック（SCP で拒否） |
| 制御の粒度 | 「作れる / 作れない」まで | 「どんな設定で作れるか」まで |
| マルチアカウント管理 | アカウントごとに個別対応 | Organizations の SCP で一元管理 |
| 対応コスト | 違反発生後に手動修正 | 違反そのものが発生しない |
適用対象の API
今回の条件キーは、以下の 4 つの EKS API に対して機能します。
-
CreateCluster─ 新規クラスター作成時 -
UpdateClusterConfig─ 既存クラスターの設定変更時 -
UpdateClusterVersion─ Kubernetes バージョンのアップグレード時 -
AssociateEncryptionConfig─ 暗号化設定の追加時
作成時だけでなく、変更・アップグレード時にも制御が効く点が重要です。既存クラスターへの設定変更で意図せずポリシー違反の状態になることも防げます。
7 つの新条件キー詳解
各条件キーの役割・型・対象 API・使いどころを見ていきます。
エンドポイントアクセス制御：eks:endpointPublicAccess / eks:endpointPrivateAccess
この 2 つはセットで使うことが多いため、まとめて説明します。
eks:endpointPublicAccess（Bool）は EKS の API サーバーをインターネットから到達可能にするかどうかを制御し、eks:endpointPrivateAccess（Bool）は VPC 内からのプライベートアクセスを制御します。どちらも CreateCluster と UpdateClusterConfig に適用されます。
「パブリックを禁止 ＋ プライベートを必須」のセットで SCP を構成することで、Kubernetes API サーバーへのアクセスを VPC 内に限定できます。ゼロトラストネットワーク構成を採用している組織では、まず検討したい条件キーです。
シークレット暗号化：eks:encryptionConfigProviderKeyArns
クラスターの Kubernetes シークレット暗号化に使用する KMS キーの ARN 群を制御します。
| 項目 | 内容 |
|---|---|
| 型 | ArrayOfARN |
| 対象 API |
CreateCluster / AssociateEncryptionConfig
|
型が ArrayOfARN（ARN の配列）であるため、複数の KMS キーをまとめて指定できます。ARN のパターンマッチングには ArnLike 演算子が適切です（StringLike は文字列型向けのため不可）。認証情報や API キーなどのシークレットを、組織が管理する特定の KMS キーで暗号化することを必須化でき、金融・医療など規制業界のコンプライアンス要件対応に特に有効です。
バージョン管理：eks:kubernetesVersion
クラスターに使用できる Kubernetes のバージョンを制御します（型：String、対象 API：CreateCluster / UpdateClusterVersion）。
StringEquals で許可バージョンを明示するか、StringLike でパターン指定（例："1.3*"）が可能です。サポート切れバージョンや組織内でまだ検証が済んでいないバージョンへのアップグレードを防ぐ用途に使えます。バージョンを追加・変更する際も SCP の更新だけで全アカウントに反映されるため、プラットフォームチームが承認済みバージョンを一元管理する運用と相性が良いです。
削除保護：eks:deletionProtection
クラスターの削除保護機能の有効 / 無効を制御します（型：Bool、対象 API：CreateCluster / UpdateClusterConfig）。
true を必須とする条件を設定することで、削除保護が無効なクラスターの作成・変更をブロックできます。オペレーターの誤操作による本番クラスターの誤削除を防ぐ、シンプルかつ効果の高い設定です。
スケーリングティアとゾーナルシフト：eks:controlPlaneScalingTier / eks:zonalShiftEnabled
eks:controlPlaneScalingTier（String）は CreateCluster と UpdateClusterConfig に適用され、StringEquals で許可するティアを指定します。本番環境には上位ティアを必須化し、開発環境では下位ティアのみ許可するといった環境ごとの使い分けにより、コストコントロールと性能要件を両立できます。
eks:zonalShiftEnabled（Bool）は同じく CreateCluster / UpdateClusterConfig に適用され、特定の AZ で障害が発生した際に EKS コントロールプレーンのトラフィックを正常な AZ へ自動迂回させる機能の有効化を制御します。SLA 要件が厳しい本番ワークロードでは、有効化を組織標準として強制できます。
ユースケース別解説
現場でどんな場面に使えるか、代表的な困りごとと解決策をセットで紹介します。
ケース 1：パブリックエンドポイントのクラスターを作られてしまう
ゼロトラストポリシーを採用している組織では、EKS の API サーバーをインターネットに露出させることは許容されません。しかし開発者が意図せずデフォルト設定のままクラスターを作成してしまうケースは後を絶たず、デプロイ後に気づいても設定変更のために作業が必要になることもあります。
eks:endpointPublicAccess と eks:endpointPrivateAccess を組み合わせた SCP を Organizations に適用することで、パブリックエンドポイントを有効にしたクラスターの作成・変更リクエストをそもそも拒否できます。開発者がどの AWS アカウントからクラスターを作成しても、ポリシーに反した構成は通りません。
ケース 2：本番クラスターを誤って削除してしまうリスクがある
深夜の障害対応中、あるいは単純なオペレーションミスによって、本番クラスターが削除されてしまうリスクは常に存在します。「削除保護を有効にしてください」とドキュメントに書いても、設定漏れは必ず発生します。
本番アカウントが所属する OU に eks:deletionProtection を true に必須化する SCP を適用することで、削除保護が無効なクラスターはそもそも作成できなくなります。ルールの周知徹底や手動チェックに頼らずにリスクを排除できます。
ケース 3：承認していない Kubernetes バージョンが使われてしまう
プラットフォームチームが検証済みのバージョンを社内標準として定めていても、開発チームが独自のバージョンでクラスターを立ち上げてしまうことがあります。サポート切れバージョンのクラスターが残り続けることは、セキュリティリスクに直結します。
eks:kubernetesVersion に StringEquals で許可バージョンを明示した SCP を適用します。バージョンを追加・変更する際も SCP の更新だけで済むため、管理コストも低く抑えられます。
ケース 4：KMS キーなしのクラスターが作られてしまう
金融・医療など規制業界では、Kubernetes シークレットをカスタマー管理の KMS キーで暗号化することがコンプライアンス要件となる場合があります。暗号化設定はオプションであるため、設定し忘れたままクラスターが運用に入るケースが発生します。
eks:encryptionConfigProviderKeyArns と ArnLike 演算子を組み合わせることで、承認済み KMS キーの ARN パターンを持たないリクエストを拒否できます。「KMS キー未設定」だけでなく「組織管理外のキーを使っている」ケースもブロックできる点が強みです。
ケース 5：開発環境で本番と同等のスペックが使われてコストが膨らむ
開発者にクラスター作成権限を委譲すると、開発・検証環境に本番と同等のコントロールプレーンスケーリングティアが設定されてしまい、不必要なコストが発生することがあります。
eks:controlPlaneScalingTier で環境ごとに許可するティアを制限します。本番 OU には上位ティア、開発 OU には下位ティアのみ許可する SCP を適用することで、コスト管理とパフォーマンス要件の両立をポリシーレベルで実現できます。
注意点・考慮事項
既存クラスターへの影響
今回追加された条件キーは、新規クラスターの作成時だけでなく UpdateClusterConfig などの変更系 API にも適用されます。SCP を導入した後に既存クラスターの設定を変更しようとした場合、変更内容がポリシー条件を満たしていなければリクエストが拒否されます。導入前に既存クラスターの設定状況を AWS Config などで棚卸しし、SCP 適用後も変更操作が問題なく通るかを確認しておくことが重要です。
段階的な導入を推奨
SCP は適用した瞬間から全アカウントに影響が及びます。いきなり Deny ルールを本番環境に適用すると、既存の CI/CD パイプラインや自動化スクリプトが予期せず失敗するリスクがあります。まず CloudTrail のログで対象 API の呼び出しパターンと実際のパラメーター値を把握した上で、非本番環境の OU から適用し、動作を確認してから本番 OU に展開するのが現実的な進め方です。SCP による拒否は API レベルで即時失敗するため、パイプライン側のエラーハンドリングも合わせて整備しておきましょう。
SCP と IAM ポリシーの関係
SCP はアカウントレベルの最大権限を定義するガードレールです。SCP で Deny されたアクションは、アカウント内の IAM ポリシーでどれだけ許可を与えていても実行できません。逆に言えば、SCP で許可されているだけでは不十分で、アカウント内の IAM ポリシーでも許可が必要です。意図しない権限昇格や操作不能を防ぐためにも、両者の関係を理解した上でポリシーを設計してください。
AWS Organizations の利用が前提
今回の条件キーを最大限に活用するには、AWS Organizations による複数アカウント管理と SCP の利用が前提となります。単一アカウントの場合でも IAM ポリシーに条件キーを組み込むことは可能ですが、組織全体への一元適用というメリットは得られません。Organizations をまだ活用していない場合は、この機会に導入を検討する価値があります。
まとめ
今回のアップデートで追加された 7 つの IAM 条件キーは、EKS クラスターのガバナンスを「作られた後に検知する」から「そもそも作らせない」へと一段階引き上げるものです。
特に AWS Organizations の SCP と組み合わせることで、複数アカウントにまたがる環境でも中央から一貫したセキュリティ基準を強制できる点が大きな価値です。追加コストなしで全商用リージョンで即日利用できるため、まずは非本番環境の OU から試してみることをおすすめします。
エンドポイントのアクセス制御・KMS 暗号化・バージョン管理・削除保護など、組織のセキュリティ要件に照らして優先度の高い条件キーから段階的に導入していくのが現実的なアプローチです。