< ブログ一覧に戻る

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

清水 孝郎
Kubernetes 1.37 - 新しいセキュリティ機能
執筆者
清水 孝郎
Kubernetes 1.37 - 新しいセキュリティ機能
@
linkedin
Kubernetes 1.37 - 新しいセキュリティ機能
Published:
August 27, 2026
この記事の内容
シスディグによるファルコフィード

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

さらに詳しく
Green background with a circular icon on the left and three bullet points listing: Automatically detect threats, Eliminate rule maintenance, Stay compliant, with three black and white cursor arrows pointing at the text.

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

‍

Kubernetes 1.37 がリリースされ、67の機能強化がもたらされました。

セキュリティの観点では、ボリュームのマウントに関する新しいセキュリティ機能、スナップショットの改善、webhook のデフォルト認証など、セキュリティに影響する19件の変更を確認しています。

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

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

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

SIG group: sig-storage
Stage: Graduating to Stable

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

この最適化により、クラスター管理者は SELinux でクラスターを強化しやすくなります。

⚠️ Kubernetes 1.37 では、この機能強化の最後の部分である SELinuxMount が安定版に移行し、この最適化が対象となるすべてのボリュームに適用されるようになります。これにより、異なる SELinux ラベルや権限レベルを持つ Pod が同じボリュームを共有するような、稀なケースで問題が発生する可能性があります。

ℹ️ SELinuxMount の破壊的変更について詳しく見る。

ℹ️ 詳細は Kubernetes 1.30 - What’s new? をご覧ください

#5343 nftables を kube-proxy のデフォルトバックエンドにする

SIG group: sig-network
#5343 Stage: Net New to Alpha

1.33 以降、kube-proxy 向けの nftables バックエンドモード（#3866）は安定していると見なされており、1.40 でデフォルトになります。1.37 では、現在デフォルトとして iptables を使用している場合、警告が表示されるようになります。

⚠️ 今すぐ移行を進めている場合は、セキュリティツールが新しい設定ファイルをカバーしていることを確認してください。

関連情報： また、このリリースでは ipvs モードが非推奨に向けた最初の一歩を踏み出しています（#5495）。

#140226 Kubelet：静的 Pod は Secret や ConfigMap を参照できなくなりました

静的 Pod が Secret や ConfigMap を参照できてしまうバグが修正され、関連する PreventStaticPodAPIReferences フィーチャーゲートは削除されました。

新しい API で公開される情報

いつものように、この新しい Kubernetes リリースでは、API に新たなデータを公開する複数の機能強化が導入されています。いくつか挙げると：

このデータは通常、クラスター管理者がクラスターの健全性を監視したり、意思決定を行ったり、問題をトラブルシューティングしたりするのに役立つことを目的としています。

⚠️ しかし、この追加データは攻撃者がインフラをより深く理解する助けにもなり得ます。

✅ 誰が API へのアクセス権を持っているかを確認し、必要なデータのみにアクセスできるようにしてください。

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

#4939 gRPC プローブでの TLS 認証情報のサポート

SIG group: sig-node
Stage: Net New to Alpha
Feature Gate: GRPCContainerProbeTLS Default: false

Kubernetes 1.37 のクラスターは、TLS を必要とする gRPC ヘルスサーバーをネイティブにプローブできるようになります。これまでは、コマンドを実行する exec プローブを使ってこれを回避する必要がありました。

ℹ️ 新しい mode フィールドを使用します：

livenessProbe:
  grpc:
    port: 8443
    mode: TLS

#5502 emptyDir ボリュームへの stickyBit サポートの追加

SIG group: sig-storage
Stage: Net New to Alpha
Feature Gate: FOO Default: false

この新しい機能強化により、デフォルトの 0777 の代わりに、0000 から 01777 までの権限モードを持つ EmptyDirVolumeSource を作成できるようになります。

ℹ️ 新しい mode フィールドを使用します：

volumes:
  - name: app-data
    emptyDir:
      mode: 01777

#5823 Pod レベルのチェックポイント／リストア

SIG group: sig-node
Stage: Net New to Alpha
Feature Gate: PodLevelCheckpointRestore Default: false

現行の Kubelet Checkpoint API は、実行中のコンテナのステートフルなコピーを作成できます。しかし、Kubernetes のワークロードは多数のコンテナの組み合わせです。

これにより、クラスター管理者は Pod レベルでチェックポイントを作成・復元できるようになります。

これは起動を高速化する上で有用です。想定される使い方としては、まず Pod がロードされた時点でチェックポイントを作成し、Pod が再び必要になったときにコールドスタートの代わりにそれをリストアするというものです。

もう一つの利用例、そしてこれを取り上げた理由は、障害発生時にクラスターをより速く復旧できることです。復旧時間はセキュリティの分野で見落とされがちですが、レジリエンスの重要な要素です。

ℹ️ 特定の条件が満たされた時点で PodCheckpoint を作成するように設定できます：

apiVersion: checkpoint.k8s.io/v1alpha1
kind: PodCheckpoint
metadata:
  name: myapp-snapshot-01
  namespace: team-a
status:
  nodeName: node-1
  checkpointLocation:
    type: NodeLocal
    nodeLocal:
      path: checkpoint-myapp_team-a-2026-05-28T10:14:22Z
  checkpointedPodTemplate:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: registry.example.com/myapp:v1.4.0
      # ...scheduling constraints, resources, and security contexts as captured.
  conditions:
  - type: Ready
    status: "True"
    reason: CheckpointCompleted
    message: "checkpoint archive written successfully"
    observedGeneration: 1

その後、それらを Pod で使用します。restoreFrom フィールドに注目してください：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-restored
  namespace: team-a
spec:
  restoreFrom: myapp-snapshot-01
  # No nodeName: admission injects a required node affinity for the checkpoint's
  # node and the scheduler binds the Pod there.
  containers:
  - name: app
    image: registry.example.com/myapp:v1.4.0
    # ...rest of spec must match the spec inside myapp-snapshot-01

#5855 volumeMounts へのバインドマウントオプション（noexec、nodev、nosuid）サポートの追加

SIG group: sig-node
Stage: Net New to Alpha
Feature Gate: VolumeBindMountOptions Default: false

この機能強化では、volumeMounts に新しい bindMountOptions フィールドが導入され、noexec、nodev、nosuid といったセキュリティ関連のフラグを定義できるようになります。

ℹ️ 例えば、攻撃者がダウンロードした直後の悪意あるファイルに対して chmod +x を実行して実行可能にする（よく使われる手法です）ことを防ぐために、/tmp にマウントされたボリュームに noexec フラグを追加できます。

volumes:
  - name: tmp
    emptyDir: {}
containers:
  - name: app
    volumeMounts:
      - name: tmp
        mountPath: /tmp
        bindMountOptions: [noexec, nosuid]

#5936 atomic write ボリュームへの user フィールドの追加

SIG group: sig-storage
Stage: Net New to Alpha
Feature Gate: AtomicWriteVolumeUserFields Default: false

ConfigMap、Secret、DownwardAPI、Projected volumes などから生成される atomic write ボリュームのファイルの所有権を、制限できるようになりました。

これは、restricted の Pod セキュリティを実装しているクラスターでは不可能であり、それ以外のクラスターでも保守負荷の高い回避策が必要でした。

ℹ️ user フィールドと defaultUser フィールドに注目してください：

volumes:
- name: volA
  configMap:
    defaultUser: 1000
    name: cm1
    items:
    - key: foo // Owner=defaultUser
      path: foo
    - key: bar // Owner=user
      path: bar
      user: 1001

#5943 ボリュームスナップショットのトポロジー

SIG group: sig-storage
Stage: Net New to Alpha
Feature Gate: VolumeSnapshotTopology Default: false

災害復旧というテーマの延長として、管理者はボリュームスナップショットにトポロジーデータを含められるようになりました。

このデータは、災害復旧の要件に沿うようにスナップショットの保存場所を決める際にも、復旧を高速化するために復元先を決める際にも活用できます。

ℹ️ トポロジー情報は、VolumeSnapshotClass の allowedTopologies フィールドで定義されます：

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-aws-vsc
driver: ebs.csi.aws.com
deletionPolicy: Delete
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/region
        values:
          - us-west-2

そして、VolumeSnapshotContent の Node Affinity フィールドで利用できるようになります：

Name:         snapcontent-123-456-789
[…]
Spec:
[…]
  Source Volume Mode:          Filesystem
  Volume Snapshot Class Name:  csi-aws-vsc
[…]
  Node Affinity:
    - matchLabelExpressions:
        - key: topology.kubernetes.io/region
          values:
            - us-west-2
        - key: topology.kubernetes.io/zone
          values:
            - us-west-2a
            - us-west-2b
Status:
  Creation Time:    1234567890000000
  Ready To Use:     true
  Restore Size:     4294967296
  Snapshot Handle:  snap-123456789
Events:             <none>

#6060 API サーバーから webhook への認証

SIG group: sig-auth
Stage: Net New to Alpha
Feature Gate: APIServerAuthenticationToWebhooks Default: false

これまで、kube-apiserver はデフォルトでアドミッション webhook に対して認証を行っていませんでした。ネットワークアクセスを持つ攻撃者は、webhook をプローブしてポリシー情報を取得したり、意図しない副作用を引き起こしたり、webhook の権限を悪用したりすることができました。

この機能強化では、（フィーチャーゲートが有効な場合に）デフォルトでこの認証を有効にするだけでなく、TokenRequest API を使用するため、この認証の実装に手動の手順は必要ありません。

ℹ️ JWT ペイロードと認証フローの実装の詳細についてはKEPを確認してください。

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

#2033 Kubelet-in-userns（別名 rootless モード）

SIG group: sig-node
Stage: Major Change to Beta
Feature Gate: KubeletInUserNamespace Default: true

この機能強化により、kubelet を非 root ユーザーとして（ユーザーネームスペース内で）実行できるようになり、コンテナブレイクアウトの脆弱性からホストを保護します。

Kubernetes 1.22 以降 Alpha の状態でしたが、1.37 ではいくつかのクリーンアップ作業が行われました：

  • kubectl get nodes -o yaml の runningInUserNamespace フィールドを確認することで、ノードがユーザーネームスペースで実行されているかどうかを確認できます。
  • Kubernetes の CI/CD テストは、現在 rootless クラスターで実行されています。

ℹ️ 追加の注意事項、制約、注意点についてはKEPを確認してください。

#5541 PVC における最終使用時刻の報告

SIG group: sig-storage
Stage: Graduated to Beta
Feature Gate: PersistentVolumeClaimUnusedSinceTime Default: true

PersistentVolumeClaim のステータス条件に新しい条件タイプ Unused が追加され、クラスター管理者が未使用の PVC を特定するのに役立ちます。クラスター管理者は、これらの PVC を削除するクリーンアップポリシーを実装でき、クラスターの攻撃対象領域を減らすことができます。

Alpha を1リリース経て、この機能強化は大きな機能上の変更なく Beta へ移行します。

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

SIG group: sig-api-machinery
Stage: Graduating to Beta
Feature Gate: ManifestBasedAdmissionControlConfig Default: true
Feature Gate: ExcludeAdmissionWebhookVirtualResources Default: true

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

Kubernetes 1.37 では、アドミッション webhook は TokenReview や SubjectAccessReview のような非永続化（virtual）の認証・認可リソースも除外するようになります。これは ValidatingAdmissionPolicy や MutatingAdmissionPolicy の動作を反映したもので、webhook がクラスター自身の認証・認可リクエストをブロックしてしまうことを防ぎます。

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

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

ℹ️ 詳細は Kubernetes 1.36 - New security features をご覧ください

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

#4412 Kubelet のイメージ認証情報プロバイダー向けの Projected サービスアカウントトークン

SIG group: sig-auth
Stage: Major Change to Beta
Feature Gate （kubelet）: KubeletServiceAccountTokenForCredentialProviders Default: true
Feature Gate （kube-apiserver）: ServiceAccountNodeAudienceRestriction Default: true

この機能強化により、Kubernetes Service Account（KAS）はイメージの pull に短期間の認証情報を使用できるようになります。長期間有効な認証情報と比較して、これらの短期的な認証情報は開発者や管理者にとってシークレット管理を簡素化しつつ、漏えいした場合に悪意ある行為者がそれを利用できる時間も制限します。

次のようにプロバイダーを設定できます：

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
providers:
  - name: acr-credential-provider
    matchImages:
      - "*.registry.io/*"
    defaultCacheDuration: "10m"
    apiVersion: credentialprovider.kubelet.k8s.io/v1
    tokenAttributes:
      serviceAccountTokenAudience: my-audience
      cacheType: Token
      # Only invoke the plugin if the pod has a service account
      requireServiceAccount: true
      # Invoke the plugin if all these annotations are present, and pass the values.
      requiredServiceAccountAnnotationKeys:
      - domain.io/identity-id
      - domain.io/identity-type
      # If present, these annotations are also passed.
      optionalServiceAccountAnnotationKeys:
      - domain.io/some-optional-annotation
      - domain.io/annotation-that-does-not-exist

ℹ️ Kubernetes 1.37 では、複数のイメージの取得を最適化するための新しいキャッシュオプションが実装されています。

✅ 可能な限り、長期間有効な認証情報を短期間の認証情報に置き換えてください。

#3257 ClusterTrustBundles（旧称 Trust Anchor Sets）

SIG group: sig-auth
Stage: Graduating to Stable

ClusterTrustBundle オブジェクトは、X.509 のトラストアンカー（ルート証明書）を保持するクラスタースコープのコンテナです。Pod は clusterTrustBundle プロジェクションを使用してこれらのオブジェクトをマウントし、署名者を検証できます。

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

#4317 ポッド証明書

SIG group: sig-auth
Stage: Graduating to Stable

この機能強化により、証明書署名リクエスト API を使用してワークロード向けの証明書を提供できるようになります。

ℹ️ 詳細は Kubernetes 1.36 - New security features をご覧ください

#4762 任意の FQDN を Pod のホスト名として設定可能に

SIG group: sig-network
Stage: Graduating to Stable

HostnameOverride により、開発者は Pod のホスト名として任意の完全修飾ドメイン名（FQDN）を設定できるようになります。

これは、認証のためにホスト名解決を正確に処理する必要がある、Kerberos レプリケーションデーモン（kpropd）のような古いサービスにとって有用です。

#5295 KYAML

SIG group: sig-cli
Stage: Graduating to Stable

KYAML は、Kubernetes の設定ファイル向けに設計された、より安全で曖昧さの少ない YAML のサブセットです。サブセットであるため、入力としては既にサポートされています。しかし、この機能強化により、json や yaml に加えて KYAML での出力を要求するオプションが追加されます。

✅ 曖昧な値による設定ミスを避けるため、可能な限り KYAML を使用してください。

ℹ️ Kubernetes blog に注目していてください。今後の記事で KYAML とそれが解決する曖昧さについて詳しく取り上げます。

まとめ

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

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

About the author

Kubernetes & Container Security
featured resources

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

デモを申し込む