Kubernetes 1.36 - 新しいセキュリティ機能

執筆者

清水孝郎

デモを申し込む

Published:

April 15, 2026

この記事の内容

本文の内容は、2026年4月15日に Victor Jimenez Cerrada が投稿したブログ(https://www.sysdig.com/blog/kubernetes-1-36-new-security-features)を元に日本語に翻訳・再構成した内容となっております。

‍

Kubernetes 1.36はまもなくリリースされ、60の機能強化がもたらされます。特に注目すべきは、動的リソース割り当て（DRA）の改善に向けた取り組みです。

セキュリティの観点では、アドミッションコントロールの設定や証明書の取り扱いなどにまたがる22の変更があります。

それでは詳しく見ていきましょう！

‍

Kubernetes 1.36における、問題を引き起こす可能性のあるセキュリティの変更

#5707 service.spec.externalIPs を非推奨

SIG group: sig-network
Stage: 非推奨から非推奨／削除へ
Feature Gate:AllowServiceExternalIPsDefault:true

service.spec.externalIPs は、適切な認可や検証なしに、非特権ユーザーが任意のアドレスを取得できるようにしていました。これは中間者攻撃やその他の悪用を可能にするため、長らくセキュリティリスクと見なされてきました。

⚠️ Kubernetes 1.36 から、このフィールドは非推奨となります。このプロセス全体は4つの段階で実施されます：

1.36では、AllowServiceExternalIPsフィーチャーゲートが追加され、kube-proxyがexternalIPsのためのルールを設定しないようにします。
1.40頃には、このフィーチャーゲートはデフォルトで無効になります。
1.43頃には、このフィーチャーゲートは完全に無効化され、関連するコードはkube-proxyから削除されます。
1.46頃には、AllowServiceExternalIPsフィーチャーゲートおよびDenyServiceExternalIPsアドミッションコントローラーが削除されます。

✅ AllowServiceExternalIPsフィーチャーゲートをできるだけ早く無効にしてください。現在externalIPsを積極的に使用している場合は、より安全な代替手段の導入を計画してください。

‍

#3104 kubectlのユーザー設定をクラスター設定から分離

SIG group: sig-cli
Stage: Major Change to Beta
Feature Gate:StorageVersionMigratorDefault:true

Kubernetes 1.35 から、新しい kuberc 設定ファイルにより、クラスタの認証情報やサーバー設定が、ユーザー固有の設定と明確に分離されるようになりました。

Kubernetes 1.36 では、kubectl kuberc set を介した認証情報プラグインのポリシー／許可リストのサポートなど、いくつかの機能が追加されています。

⚠️ アルファ版からの重要な変更：command の別名と見なされていた name フィールドは、現在非推奨となっています。

✅ 設定ファイルを確認し、ユーザー固有の設定では name フィールドを command に置き換えてください。

‍

#4317 ポッド証明書

SIG group: sig-auth
Stage: Major Change to Beta
Feature Gate:PodCertificateRequestDefault:true

Kubernetes 1.35 では、この機能強化により、証明書署名リクエスト API を使用してワークロード向けの証明書を提供できるようになりました。これには、PodCertificateRequest API と PodCertificate ボリュームソースが含まれていました。

⚠️ Kubernetes 1.36 では、PKIXPublicKey フィールドと ProofOfPossession フィールドが、新しい StubPKCS10Request フィールドに統合されます。これにより、証明書発行時に入力として PKCS10 リクエストを必要とする、最も一般的な CA 実装により適した形になります。

✅ PodCertificateRequest の設定を確認し、1.36 へのアップグレード時に設定を更新してください。

#4858 IP/CIDR 検証の改善

SIG group: sig-network
Stage: Graduating to Beta
Feature Gate:StrictIPCIDRValidationDefault:true

この機能強化により、IP および CIDR の検証が強化され、CVE-2021-29923 で説明されているようなセキュリティインシデントにつながる可能性のある曖昧な値を回避できるようになります。

特に、012.000.001.002 のような先頭にゼロが付いたアドレスや、::ffff:1.2.3.4 のような IPv6 にマッピングされた IPv4 アドレスが対象となります。

⚠️ 既存の値によってクラスターが壊れることはありませんが、新たに無効な値を含む設定を適用するとエラーが発生します。

✅ 設定を確認し、必要に応じて値を修正してください。

‍

#4817 DRA: 標準化された可能性のあるネットワークインターフェースデータを含むリソースクレームステータス

SIG group: sig-node
Stage: Major Change to Beta
Feature Gate:DRAResourceClaimDeviceStatusDefault:true
Feature Gate:DRAResourceClaimGranularStatusAuthorizationDefault:true

動的リソース割り当て（DRA）は、GPU や FPGA などの特殊なハードウェアへのアクセスをより適切に割り当てるために Kubernetes に追加された機能です。Pod は ResourceClaim オブジェクトを作成することで、これらのリソースへのアクセスを要求できます。

この機能強化では、DRA ドライバーがこれらの ResourceClaim オブジェクト内でデバイスのステータスデータをどのように報告できるかが定義されています。例えば、共有ネットワークインターフェースは、それに割り当てられた IP アドレスを一覧表示できます。これは次のようになります：

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: macvlan-eth0
spec:
...
status:
  allocation:
    devices:
      results:
      - device: eth0
        driver: resource-driver.example.com
        pool: nic-worker-a
        request: macvlan-eth0
        shareID: 8e7acdf9-0290-4ecd-a801-a654b021d2b7
        consumedCapacity:
          resource-driver.example.com/bandwidth: 1G
  devices:
  - conditions:
    - lastTransitionTime: "2025-10-21T08:38:17Z"
      message: Device successfully allocated and assigned to the pod
      reason: NetworkReady
      status: "True"
      type: NetworkReady
    device: eth0
    driver: resource-driver.example.com
    networkData:
      hardwareAddress: 00:01:ec:84:fb:51
      interfaceName: net1
      ips:
      - 10.10.1.2/24
      - 2001:db8::1/64
    pool: nic-worker-a
    shareID: 8e7acdf9-0290-4ecd-a801-a654b021d2b7

⚠️ Kubernetes 1.36 から、これまで resourceclaims/status を更新するために update または patch 権限のみが必要だったコンポーネントは、追加の権限も必要になります。この動作は DRAResourceClaimGranularStatusAuthorization フィーチャーゲートによって制御されます。

✅ 移行ガイドを確認し、必要な追加権限を付与するよう設定を更新してください。

‍

その他の非推奨事項

これらは、Kubernetes 1.36 にアップグレードする際に併せて留意すべき、いくつかの既存の非推奨事項です：

#5040 gitRepo ボリュームドライバーは、v1.11 以降非推奨となっていた後、削除されました。
Ingress NGINX も廃止されました。
WebSockets が SPDY に置き換えられており、RBAC ポリシーの更新が必要になる場合があります。

‍

Kubernetes 1.36 で新たに強化されたセキュリティ機能

#5793 マニフェストベースのアドミッションコントロール設定

SIG group: sig-api-machinery
Stage: Net New to Alpha
Feature Gate:ManifestBasedAdmissionControlConfigDefault:false

この変更は、現在 etcd に保存されているアドミッションコントロール設定を、kube-apiserver のファイルベースのマニフェストへ移行することを目的としています。

これまで Kubernetes は、セキュリティルールを含め、etcd を信頼できる情報源として扱ってきました。これは、保護対象と同じ場所にセキュリティシステムが保存されているという循環依存の問題を意味します。これにはいくつかの問題があります：

起動時のギャップ：これらのオブジェクトはアドミッションコントローラーによって作成されますが、起動時にはアクティブではありません。つまり、ポリシーがまだ適用されていない時間帯が存在し、脆弱性が生じます。
ポリシーの削除：十分な権限を持つ悪意のある行為者が、アドミッションポリシーを削除できる可能性があります。
起動時の etcd 依存：起動時に etcd が破損している、または利用できない場合、アドミッションポリシーが正しく読み込まれません。

⚠️ この変更を有効にするには、フィーチャーフラグをオンにするだけでは不十分です。admission-config.yaml ファイルを追加する必要があります。

✅ 以下の設定を追加して AdmissionConfiguration ファイルを有効にしてください：

--admission-control-config-file=/etc/kubernetes/admission-config.yaml

‍

Kubernetes 1.36 では、これらのセキュリティ機能がデフォルトで有効になります

#4828 Kubernetes コンポーネントのための Flagz

SIG group: sig-instrumentation
Stage: Graduating to Beta
Feature Gate:ComponentFlagzDefault:true

statusZ ページと同様に、flagz エンドポイントは Kubernetes コンポーネントのランタイム診断情報を提供します。特に、コンポーネントの起動時に使用されたコマンドライン引数を提供します。

クラスター管理者は、このツールを使用して、すべてのコンポーネントが期待どおりの設定で実行されていること、およびセキュリティポリシーからの逸脱がないことを確認できます。

ℹ️　詳細は Kubernetes 1.32 - 新機能をご覧ください

‍

#5284 制約付きなりすまし

SIG group: sig-auth
Stage: Graduating to Beta
Feature Gate:ConstrainedImpersonationDefault:true

なりすまし（Impersonation）は、ユーザーが別のユーザーとして振る舞うことを可能にするもので、管理者が認可ポリシーをデバッグするなどの内部ツールにおいて有用です。

問題は、現在の仕組みでは、本来意図されていた以上の権限を持つ他のユーザーになりすますことも可能になってしまう点です。そのため、新しい制限付きなりすまし機能では、なりすまし時のユーザー権限を制限するための追加のチェックが導入されています。

‍

ℹ️ 詳細は Kubernetes 1.35 - 新機能をご覧ください

‍

Kubernetes 1.36 における既存機能のその他の変更

#4192 ストレージバージョンマイグレーターをインツリーへ移動

SIG group: sig-api-machinery
Stage: Major Change to Beta
Feature Gate:StorageVersionMigratorDefault:true

Kubernetes 1.30 では、この機能強化により、保存されたデータを内部的に移行できるようになりました。これ以前は、新しいスキーマバージョンや新しい暗号化キーへ移行するには、データを手動で抽出して書き換える必要がありました。

kubectl get <resource> | kubectl replace -.

これはスケーラブルではないだけでなく、これらすべてのデータを抽出すること自体がセキュリティリスクでもあります。

この機能強化により、現在は kubectl apply -f を実行するだけで済むようになりました。

⚠️ Kubernetes 1.36 から、CRD の status.storedVersions フィールドには、管理者が古いバージョンを削除できるように、リソースの最新バージョンのみが含まれるようになります。

‍

ℹ️ 詳細については、この機能のドキュメントをご確認ください。

‍

#5607 HostNetwork Pod がユーザーネームスペースを使用できるようにする

SIG group: sig-node
Stage: Major Change to Alpha
Feature Gate:UserNamespacesHostNetworkSupportDefault:false

Kubernetes 1.35 から、hostNetwork: true によってホストネットワークに直接接続する Pod は、hostUsers: false を指定することで、ホストのユーザー名前空間の代わりにユーザーネームスペースも使用できるようになりました。ユーザーネームスペースを使用すると、侵害されたコンテナからの脱出に成功した攻撃者が、ホストレベルで持つ権限は制限されます。

ℹ️ Kubernetes 1.36 では、hostNetwork: true かつ hostUsers: false を使用するノードは、この機能のサポートを明示的に宣言しているノードにのみスケジュールされます。

‍

Kubernetes 1.36 のセキュリティ機能がステーブルに移行しました

#127 Pod におけるユーザーネームスペースのサポート

SIG group: sig-node
Stage: Graduating to Stable

ユーザーネームスペースは、コンテナ内でプロセスを実行するユーザーとホスト上のユーザーを分離することで、Pod の分離性を高めます。

これは特に、root として実行する必要がある Pod にとって有用です。ユーザーネームスペースを活用することで、Pod 内では root としてプロセスを実行しながら、ホスト上では非特権ユーザーとして実行されるようにできます。

このような Pod が侵害され、攻撃者がコンテナからの脱出に成功した場合でも、攻撃者は非特権ユーザーとなるため、影響は限定的になります。

この機能は、Pod の定義で hostUsers: false を設定することで有効にできます。

ℹ️ 詳細は Kubernetes 1.25 - 新機能をご覧ください

‍

#740 サービスアカウントトークンの外部署名のための API

SIG group: sig-auth
Stage: Graduating to Stable

しばらくの間、kube-apiserver は外部の鍵管理ソリューションを使用してサービスアカウントの認証情報に署名および検証を行うことができました。この機能は現在、安定版と見なされています。

ℹ️ 詳細についてはドキュメントをご確認ください。

‍

#1710 再帰的な SELinux ラベル変更の高速化

SIG group: sig-storage
Stage: Graduating to Stable

この機能は、SELinux を使用する際の PersistentVolume のマウントを高速化します。マウント時に context オプションを使用することで、ファイルごとに再帰的にコンテキストを変更するのではなく、ボリューム全体にセキュリティコンテキストを適用します。

この機能強化は Kubernetes 1.24 から開発が進められており、ついに安定版と見なされるようになりました。

ℹ️ 詳細は Kubernetes 1.30 - 新機能をご覧ください

‍

#2862 きめ細かな Kubelet API 認可

SIG group: sig-node
Stage: Graduating to Stable

この改善により、ノードエンドポイントに対する現在のアクセス制御に、より細かな粒度が与えられます。例えば、ノード上の Pod を一覧表示する必要があるエージェントがあったとします。従来は、nodes/proxy の権限を付与する必要がありました。これは明らかに最小権限の原則に反しています。

きめ細かな Kubelet API 認可により、次のようなリソースへのアクセスを付与できるようになります：

nodes/configz
nodes/healtz
nodes/pods

ℹ️ 詳細は Kubernetes 1.33 - 新機能をご覧ください

‍

#3962 ミューテーティングアドミッションポリシー

SIG group: sig-api-machinery
Stage: Graduating to Stable

アドミッションコントローラーが行う変更のほとんどは、ラベルやフィールドの設定、サイドカーの追加などの単純な編集です。この機能強化により、Common Expression Language（CEL）を使用して、これらの変更を YAML 内で直接定義する仕組みが追加され、ほとんどの場合で webhook が不要になります。

ℹ️ 詳細は Kubernetes 1.31 - 新機能をご覧ください

‍

#2258 Node log query

SIG group: sig-windows
Stage: Graduating to Stable

この機能強化により、ノード上で稼働しているシステムのログを表示するための kubelet ネイティブ API が導入され、ログを確認するためにノードへ SSH 接続する必要がなくなりました。

例えば、ノードから kubelet のログを取得するには、次を使用できます：

‍

kubectl get --raw "/api/v1/nodes/node-1/logs?query=kubelet"

‍

ℹ️ 詳細は Kubernetes 1.27 - 新機能をご覧ください

‍

#4205 cgroupv2 に基づく PSI のサポート

SIG group: sig-node
Stage: Graduating to Stable

PSI（Pressure Stall Information）は、2018年に導入された Linux カーネルの機能であり、以下を測定します：

CPU プレッシャー
メモリプレッシャー
I/Oプレッシャー

使用率（例：CPU 使用率 45%）に依存する代わりに、プレッシャーはタスクがリソースを待機している時間を測定するため、一部のアプリケーションにおいてはより正確な指標となる可能性があります。

ℹ️ この機能を使用するには、PSI をサポートする Linux 上で実行していること（通常は該当します）と、cgroup v2 を有効にしている必要があることに注意してください。

‍

#4265 ProcMount オプションを追加

SIG group: sig-node
Stage: Graduating to Stable

Linux システムにおいて、/proc ファイルシステムはカーネルのデータ構造へのインターフェースであり、以下に関する情報を提供します：

プロセス
ハードウェア
システム状態
そして、もっと

Kubernetes では、セキュリティを確保するために、ホスト情報の不意な露出を防ぐ目的で /proc の一部がマスクされています。しかし、特定の部分をアンマスクしたいケースもあります。

その一例が、コンテナ内でさらにコンテナを実行するようなシナリオです。これは、Kubernetes の Pod 内でコンテナイメージをビルドする必要がある CI/CD パイプラインでよく見られます。このような場合、親コンテナはネストされたコンテナの /proc に書き込む必要があります。

この機能が登場する以前は、ユーザーは完全に特権を持つコンテナを実行する必要があり、これはより危険な状況でした。

この機能では、securityContext の定義に新たに ProcMountType という文字列が追加され、Default と Unmasked の2つの値を指定できます。

ℹ️ ProcMountType の変更を行うには hostUsers: false を使用する必要があり、そうでない場合は API サーバーによって拒否されます。

‍

#4639 VolumeSource：OCI アーティファクトおよび／またはイメージ

SIG group: sig-node
Stage: Graduating to Stable

Kubernetes は現在、OCI アーティファクトおよびイメージをボリュームソースとして使用できるようになりました。

シンプルなユースケースとしては、nginx のような Web サーバーが挙げられます。これにより、すべての Web サイト Pod は同じベースイメージ（イメージボリュームを使用するように調整されたもの）を使用し、設定や Web アセットは別の最小限のイメージとしてデプロイできるようになります。

⚠️ このように OCI イメージのマウントを許可することは、潜在的な攻撃経路を開く可能性があります。

✅ この機能を有効にする前に、セキュリティポリシーを強化し、信頼されていないレジストリからのイメージや実行可能なコンテンツを含むイメージのマウントを許可しないようにしてください。イメージボリュームを定義する Pod をブロックすることも検討してください。

ℹ️ 詳細は Kubernetes 1.35 - 新機能をご覧ください

‍

#5018 DRA: ResourceClaims および ResourceClaimTemplates のための AdminAccess

SIG group: sig-node
Stage: Graduating to Stable

動的リソース割り当て（DRA）は、GPU や FPGA などの特殊なハードウェアへのアクセスをより適切に割り当てるために Kubernetes に追加された機能です。実際には、これは他のユーザーがすでに使用しているデバイスへの特権アクセスを取得することを意味します。

この機能強化により、セキュリティを損なうことなく、この特権アクセスを実現できます。

ResourceClaim および ResourceClaimTemplate に新しい adminAccess フラグを指定することで、アクセスを要求できます：

apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
  name: admin-resource-claim
  namespace: admin-namespace
spec:
  devices:
    requests:
      - deviceClassName: admin-resource-class
        adminAccess: true

また、これらのクレームの作成を許可するには、ネームスペースに admin-access を付与する必要があります：

resource.kubernetes.io/admin-access: "true"

‍

#5538 secrets フィールドを介したサービスアカウントトークンに対する CSI ドライバーのオプトイン

SIG group: sig-storage
Stage: Graduating to Stable

この機能強化では、クラウドバケットのマウントに使用されるアカウントトークンなどの機密データを安全に保存するための、新しい Secrets フィールドが導入されます。serviceAccountTokenInSecrets フィールドが true の場合、CSI ドライバーは Secrets フィールド内でトークンを検索します。

ℹ️ 詳細は Kubernetes 1.35 - 新機能をご覧ください

‍

#5589 Kubernetes API 型における gogo protobuf 依存関係の削除

SIG group: sig-api-machinery
Stage: Major Change to Stable

Kubernetes API は gogo protobuf に依存しています。しかし、このライブラリは 2021 年に非推奨となりました。これはセキュリティリスクなどの問題を引き起こすため、この依存関係を削除する取り組みが進められています。

この機能強化は、Kubernetes API オブジェクトからこれらの依存関係を削除することに焦点を当てています。代わりに、標準の golang protobuf ライブラリが使用されます。

ℹ️ Kubernetes 1.36 では、ProtoMessage メソッドの削除に重点が置かれています。詳細については KEP の実装内容を確認するか、PR を参照してください。

‍

まとめ

これを気に入っていただけたなら、これまでの「Kubernetes の新機能」シリーズもぜひご覧ください：

Kubernetes 1.35 - What’s new?
Kubernetes 1.33 - What’s new?
Older releases: 1.32, 1.31, 1.30, 1.27, 1.26, 1.25, 1.24, 1.23, 1.22, 1.21, 1.20, 1.19, 1.18, 1.17, 1.16, 1.15, 1.14, 1.13, 1.12.

‍

Kubernetes プロジェクトに参加してください。

プロジェクトのホームページをご覧ください。
GitHub で Kubernetes プロジェクトをチェックしてください。
Kubernetes コミュニティに参加してください。
Kubernetes Slack でメンテナーに会いましょう。
X で @Kubernetes.io をフォローしてください。

About the author

Cloud Security

featured resources

セキュリティの専門家と一緒に、クラウド防御の最適な方法を探索しよう

デモを申し込む

Kubernetes 1.36 - 新しいセキュリティ機能

Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。

Kubernetes 1.36における、問題を引き起こす可能性のあるセキュリティの変更

#5707 service.spec.externalIPs を非推奨

#3104 kubectlのユーザー設定をクラスター設定から分離

#4317 ポッド証明書

#4858 IP/CIDR 検証の改善

#4817 DRA: 標準化された可能性のあるネットワークインターフェースデータを含むリソースクレームステータス

その他の非推奨事項

Kubernetes 1.36 で新たに強化されたセキュリティ機能

#5793 マニフェストベースのアドミッションコントロール設定

Kubernetes 1.36 では、これらのセキュリティ機能がデフォルトで有効になります

#4828 Kubernetes コンポーネントのための Flagz

#5284 制約付きなりすまし

Kubernetes 1.36 における既存機能のその他の変更

#4192 ストレージバージョンマイグレーターをインツリーへ移動

#5607 HostNetwork Pod がユーザーネームスペースを使用できるようにする

Kubernetes 1.36 のセキュリティ機能がステーブルに移行しました

#127 Pod におけるユーザーネームスペースのサポート

#740 サービスアカウントトークンの外部署名のための API

#1710 再帰的な SELinux ラベル変更の高速化

#2862 きめ細かな Kubelet API 認可

#3962 ミューテーティングアドミッションポリシー

#2258 Node log query

#4205 cgroupv2 に基づく PSI のサポート

#4265 ProcMount オプションを追加

#4639 VolumeSource：OCI アーティファクトおよび／またはイメージ

#5018 DRA: ResourceClaims および ResourceClaimTemplates のための AdminAccess

#5538 secrets フィールドを介したサービスアカウントトークンに対する CSI ドライバーのオプトイン

#5589 Kubernetes API 型における gogo protobuf 依存関係の削除

まとめ

About the author

セキュリティの専門家と一緒に、クラウド防御の最適な方法を探索しよう