はじめに
2026 年 7 月 27 日、AWS は Amazon EKS の OIDC エンドポイントに対する AWS PrivateLink 対応を発表しました。IAM Roles for Service Accounts (IRSA) が利用する OIDC ディスカバリーエンドポイントおよび JWKS エンドポイントに、インターネットエグレスを介さず VPC 内から privately にアクセスできるようになったことが、今回のアップデートの特徴です。
EKS を閉域網要件の厳しい環境で運用している方の中には、VPC 内から IRSA をセットアップしようとした際に、OIDC エンドポイントへ到達できず苦労した経験がある方もいるのではないでしょうか。今回のアップデートは、その課題に直接応えるものです。
本記事では、何が変わったのか、直近発表された customer-routed control plane egress とは何が違うのか、どのような組織にとって意味のあるアップデートなのか、そしてどう有効化すればよいのかを中心に解説します。EKS を運用するインフラ・プラットフォームエンジニアの方や、セキュリティ・コンプライアンス要件の検討に関わる方を想定読者としています。
何が変わったのか
EKS のクラスターは、IRSA 用に OIDC ディスカバリーエンドポイントと JWKS を公開しています。実はこのエンドポイント、これまではパブリックなインターネット経由でしかアクセスできませんでした。
| 項目 | 従来 | 今回のアップデート |
|---|---|---|
| OIDC エンドポイントへのアクセス経路 | インターネット経由のみ | VPC 内から PrivateLink 経由でもアクセス可能 |
| 閉域網環境での IRSA セットアップ | インターネットエグレスが必須 | インターネットエグレスなしで完結 |
| EKS 管理 VPC エンドポイントのプライベート DNS 有効時の挙動 | 名前解決に失敗するケースがあった | 正しく解決される |
従来の課題
閉域網要件を持つ組織では、EKS の VPC エンドポイント (com.amazonaws.<region>.eks) をプライベート DNS 有効の状態で作成すると、OIDC エンドポイント (oidc.eks.<region>.amazonaws.com) への名前解決が失敗するという問題がありました。この状態で VPC 内から eksctl や Terraform を使って IRSA をセットアップしようとすると NXDOMAIN エラーとなってしまい、CloudShell など VPC 外から実行する、あるいは split-horizon の DNS リゾルバーを構築するといった回避策を取らざるを得ませんでした。
OIDC エンドポイントの PrivateLink 対応による解決
com.amazonaws.<region>.oidc-eks サービス向けにインターフェイス VPC エンドポイントを作成することで、OIDC ディスカバリードキュメントおよび JWKS へのアクセスが VPC 内で完結するようになりました。インターネットエグレスのない環境でも eksctl や Terraform、カスタムトークンバリデーターなどのツールから IRSA のセットアップとトークン検証が行えるようになり、EKS 管理 VPC エンドポイントでプライベート DNS を有効にしている場合の名前解決の問題も解消されます。
この機能は、標準の AWS PrivateLink 料金以外の追加コストなしで利用できます。リージョン展開については、発表では EKS が利用可能なリージョンでは基本的に利用できるとされている一方、EKS のユーザーガイドでは「多くのリージョンで利用可能」という表現にとどまっているため、利用予定のリージョンで提供されているかどうかは事前に確認しておくと安心です。
customer-routed control plane egress との違い
直近発表された customer-routed control plane egress と今回のアップデートは、どちらも「EKS」「OIDC」「プライベート」というキーワードが並ぶため、混同しやすい組み合わせです。しかし実際には、トラフィックの向きも解決する課題も異なります。
customer-routed control plane egress は、EKS のコントロールプレーンが発信する送信トラフィックをユーザー自身の VPC 経由でルーティングできるようにする機能でした。対象には admission webhook へのコールバックや、社内に構築した OIDC プロバイダーへの問い合わせなどが含まれます。データ境界要件やコンプライアンス上の要件を持つ組織が、VPC 内からしかアクセスできないプライベートな OIDC プロバイダーや webhook サーバーにコントロールプレーンから到達できるようにするための機能で、有効化には controlPlaneEgressMode を CUSTOMER_ROUTED に設定します。
一方、今回のアップデートが対象とするのは、EKS クラスター自身が発行する OIDC ディスカバリーエンドポイントと JWKS です。これは IRSA が Pod に紐づく IAM ロールの署名検証に使うものであり、eksctl や Terraform、カスタムトークンバリデーターといった VPC 内のツールがこのエンドポイントにアクセスする側、つまり着信のトラフィックが対象になります。
| customer-routed control plane egress | OIDC エンドポイントの PrivateLink 対応 | |
|---|---|---|
| 対象となる OIDC | ユーザーが持つ外部の OIDC プロバイダー（クラスター認証用） | EKS クラスターが発行する OIDC エンドポイント（IRSA 用） |
| トラフィックの向き | コントロールプレーンからの発信 | VPC 内のツールからの着信 |
| 解決する課題 | 社内の OIDC プロバイダーや webhook サーバーが VPC 内に閉じており、コントロールプレーンから到達できない | パブリックにしか公開されていなかった OIDC エンドポイントに、VPC 内のツールがインターネット経由でしかアクセスできない |
両者は独立した機能であり、片方を有効化してももう片方の課題が解決するわけではありません。すでに customer-routed control plane egress を導入している環境であっても、VPC 内で IRSA をセットアップする際に OIDC エンドポイントへのアクセスに悩んでいるのであれば、今回のアップデートは別途検討する価値があります。
この機能が必要なのはどんな組織か
すべての EKS ユーザーにとって必須のアップデートというわけではありません。恩恵を受けやすいのは、VPC からインターネットへのエグレスを制限している、あるいは完全に禁止している組織です。
代表的なのは、セキュリティポリシー上 VPC からのインターネット向け通信を厳しく制限している金融機関や医療機関、官公庁系のシステムです。これまでは IRSA を使いたくても、VPC 内から OIDC エンドポイントに到達する手段がインターネット経由しかなく、NAT ゲートウェイ経由のエグレスを許可するか、IRSA の利用自体を諦めるかの選択を迫られるケースがありました。インターネットエグレスを一切開けることなく IRSA をセットアップできるようになる点が、こうした組織にとっての価値です。
すでに EKS の管理 VPC エンドポイントをプライベート DNS 有効の状態で運用しており、名前解決の問題に心当たりがある組織にとっても、直接的に役立つアップデートです。CloudShell からの手動実行や split-horizon DNS リゾルバーといった回避策を維持し続ける必要がなくなります。
また、VPC 内で動作する CI/CD ランナーや Terraform の実行環境から、eksctl や Terraform を使って IRSA のセットアップを自動化しているパイプラインにとっても意味があります。インターネットエグレスなしでも OIDC プロバイダーの作成やトークン検証が完結するため、閉域ネットワーク内で完結した IaC パイプラインを組みやすくなります。
逆に、VPC から通常のインターネットエグレスが許可されている環境であれば、これまで通りパブリックの OIDC エンドポイントで特に問題なく運用できているはずです。そうした環境では、今回のアップデートは必須ではなく、あくまで選択肢が増えたという位置づけになります。
有効化の手順
有効化の方法自体はシンプルです。対象の VPC に、OIDC エンドポイント用のインターフェイス VPC エンドポイントを 1 つ作成するだけで完結します。
インターフェイス VPC エンドポイントの作成
サービス名には com.amazonaws.<region-code>.oidc-eks を指定します。AWS CLI であれば、次のようなコマンドで作成できます。
aws ec2 create-vpc-endpoint \
--vpc-id <vpc-id> \
--service-name com.amazonaws.<region-code>.oidc-eks \
--vpc-endpoint-type Interface \
--subnet-ids <subnet-id-1> <subnet-id-2> \
--security-group-ids <security-group-id> \
--private-dns-enabled
可用性を確保するため、複数の AZ にまたがるサブネットを指定しておくことをおすすめします。プライベート DNS は EKS のインターフェイスエンドポイントではデフォルトで有効になりますが、上記のように明示的に指定しておくと意図が伝わりやすくなります。VPC 側の enableDnsHostnames と enableDnsSupport が有効になっていれば、追加の設定なしで oidc.eks.<region-code>.amazonaws.com がこのエンドポイントに解決されるようになります。IPv6 クラスターの場合は、デュアルスタックのホスト名 oidc-eks.<region-code>.api.aws が使われます（AWS 中国リージョンでは oidc-eks.<region-code>.api.amazonwebservices.com.cn になります）。
アクセス制御について
ここで一点、注意が必要です。EKS API 向けのインターフェイスエンドポイントとは異なり、この OIDC エンドポイント用のインターフェイスエンドポイントは VPC エンドポイントポリシーに対応していません。OIDC ディスカバリードキュメントと JWKS は、OpenID Connect の仕様上、認証情報を伴わない匿名リクエストとして配信される仕組みになっており、IAM プリンシパルやアクションを持たないリクエストに対してエンドポイントポリシーで評価する対象がないためです。このエンドポイントはデフォルトのフルアクセスポリシーのみを受け付けます。
アクセスを絞りたい場合は、エンドポイントポリシーではなく、エンドポイントのネットワークインターフェイスに付与するセキュリティグループと、サブネットのルーティングで制御します。たとえば、次のようにインバウンドの 443 番ポートを VPC の CIDR に限定する設定が基本になります。
aws ec2 authorize-security-group-ingress \
--group-id <security-group-id> \
--protocol tcp \
--port 443 \
--cidr <vpc-cidr>
動作確認
エンドポイント作成後は、VPC 内のインスタンスから名前解決ができているかを確認します。
nslookup oidc.eks.<region-code>.amazonaws.com
インターネットエグレスのない VPC 内でこのコマンドが正しく解決されれば、エンドポイントが機能しています。あわせて、実際に次のようなコマンドを VPC 内から実行し、以前発生していたような名前解決エラーが起きずに IAM OIDC プロバイダーの作成が完了することを確認しておくと安心です。
eksctl utils associate-iam-oidc-provider --cluster <cluster-name> --approve
手順に関する補足
このエンドポイントが担うのは、あくまで OIDC ディスカバリードキュメントと JWKS の配信を VPC 内に閉じることまでです。ワークロードが sts:AssumeRoleWithWebIdentity を呼び出して実際に IAM ロールの一時的なクレデンシャルを取得する処理は、AWS STS が内部で完結させており、この OIDC エンドポイントを経由しません。そのため、ワークロードから STS への呼び出し自体もプライベートに保ちたい場合は、別途 AWS STS 向けのインターフェイスエンドポイントを作成し、リージョナルな STS エンドポイントを使うように設定する必要があります。
活用シーン
閉域網環境での IRSA セットアップ
インターネットエグレスを一切許可していない VPC で EKS を運用している場合、これまでは IRSA のセットアップ自体を諦めざるを得ないケースがありました。VPC 内に OIDC エンドポイント用のインターフェイスエンドポイントを 1 つ用意するだけで、eksctl や Terraform、AWS CLI から IAM OIDC プロバイダーを作成でき、VPC 内で動かす独自のトークンバリデーターからも直接 JWKS を取得できるようになります。NAT ゲートウェイなど、この用途のためだけにインターネットエグレスの経路を用意する必要がなくなる点も実務上のメリットです。
EKS 管理 VPC エンドポイントとの併用時に起きていた DNS 競合の解消
EKS の管理 VPC エンドポイントをプライベート DNS 有効の状態で運用しており、名前解決の競合に悩まされていた環境でも、OIDC エンドポイント専用のインターフェイスエンドポイントを別途作成するだけで解消します。CloudShell からの手動実行や split-horizon DNS リゾルバーといった回避策を、維持し続ける必要がなくなります。
VPC 内で完結する IaC パイプラインでの IRSA 自動化
VPC 内で動作する CI/CD ランナーから Terraform や eksctl を使って IRSA のセットアップを自動化しているパイプラインにも活用できます。パイプラインの実行環境そのものにインターネットエグレスを許可したくない、というセキュリティ要件を持つチームでも、OIDC エンドポイントへのアクセスだけを VPC 内に閉じたインターフェイスエンドポイント経由に切り替えることで、クラスターの IAM OIDC プロバイダー作成をパイプラインに組み込みやすくなります。
まとめ
EKS クラスターの OIDC ディスカバリーエンドポイントと JWKS に、AWS PrivateLink 経由で VPC 内から直接アクセスできるようになりました。これまでインターネットエグレスが前提だった IRSA のセットアップが、閉域網環境でも完結するようになります。
直近発表された customer-routed control plane egress とは、対象とする OIDC も解決する課題も異なるアップデートです。閉域網要件のある環境で EKS を運用している方は、この機会に自分たちの環境で活かせないか確認してみてください。