Kubernetes 1.37 – 新たなセキュリティ機能

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

SIGグループ: sig-storage
ステージ: Stableへ昇格

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

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

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

ℹ️ SELinuxMountの互換性を破る変更について詳しくはこちら。

ℹ️ Kubernetes 1.30 – 新機能でも詳しく解説しています。

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

SIGグループ: sig-network
#5343 ステージ: Alpha</strong として新規追加

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

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

関連情報: また、今回のリリースではipvsモードが非推奨化への第一歩を踏み出しています（#5495）。

#140226 Kubelet: 静的PodがSecretやConfigMapを参照できなくなる問題

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

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

SIGグループ: sig-node
ステージ: Alphaとして新規追加
フィーチャーゲート: GRPCContainerProbeTLS デフォルト: false

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

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

livenessProbe:
  grpc:
    port: 8443mode: TLS

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

SIGグループ: sig-storage
ステージ: Alphaとして新規追加
フィーチャーゲート: FOO デフォルト: false

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

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

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

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

SIGグループ: sig-node
ステージ: Alphaとして新規追加
フィーチャーゲート: PodLevelCheckpointRestore デフォルト: false

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

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

これは起動の高速化に役立ちます。想定される使い方としては、まずPodが読み込まれた時点でチェックポイントを作成しておき、そのPodが再び必要になった際にコールドスタートではなくそこから復元する、という流れです。

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

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

apiVersion: checkpoint.k8s.io/v1alpha1
kind: PodCheckpoint
metadata:
  name: myapp-snapshot-01namespace: team-a
status:
  nodeName: node-1checkpointLocation:
    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グループ: sig-node
ステージ: Alphaとして新規追加
フィーチャーゲート: VolumeBindMountOptions デフォルト: false

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

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

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

#5936 アトミック書き込みボリュームへのuserフィールド追加

SIGグループ: sig-storage
ステージ: Alphaとして新規追加
フィーチャーゲート: AtomicWriteVolumeUserFields デフォルト: false

これで、ConfigMap、Secret、DownwardAPI、Projected volumesといったアトミック書き込みボリュームのファイルについて、所有権を制限できるようになりました。

これまではrestrictedのPodセキュリティを実装しているクラスターではこれが不可能で、それ以外の場合でも手間のかかる回避策が必要でした。

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

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

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

SIGグループ: sig-storage
ステージ: Alphaとして新規追加
フィーチャーゲート: VolumeSnapshotTopology デフォルト: 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-123456789Events:             <none>

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

SIGグループ: sig-auth
ステージ: Alphaとして新規追加
フィーチャーゲート: APIServerAuthenticationToWebhooks デフォルト: false

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

この機能強化では、（フィーチャーゲートが有効な場合に）デフォルトでこの認証を有効にするだけでなく、TokenRequest APIを利用することで、この認証の実装に手動での作業を必要としないようにしています。

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

#2033 Kubelet-in-userns（通称rootlessモード）

SIGグループ: sig-node
ステージ: Betaへの大規模変更
フィーチャーゲート: KubeletInUserNamespace デフォルト: true

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

Kubernetes 1.22からAlphaとして存在していましたが、1.37ではいくつかの整理作業が行われました。

• kubectl get nodes -o yamlのrunningInUserNamespaceフィールドを確認することで、ノードがユーザー名前空間で動作しているかどうかを確認できます。
• Kubernetes CI/CDテストがrootlessクラスターで実行されるようになりました。

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

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

SIGグループ: sig-storage
ステージ: Betaに昇格
フィーチャーゲート: PersistentVolumeClaimUnusedSinceTime デフォルト: true

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

Alphaとして1リリースを経て、この機能強化は大きな機能変更なくBetaに昇格しました。

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

SIGグループ: sig-api-machinery
ステージ: Betaへ昇格
フィーチャーゲート: ManifestBasedAdmissionControlConfig デフォルト: true
フィーチャーゲート: ExcludeAdmissionWebhookVirtualResources デフォルト: true

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

Kubernetes 1.37では、アドミッションWebhookがTokenReviewやSubjectAccessReviewといった、永続化されない（仮想的な）認証・認可リソースを除外するようにもなりました。これはValidatingAdmissionPolicyやMutatingAdmissionPolicyの挙動を踏襲したもので、Webhookがクラスター自身の認証・認可リクエストをブロックしてしまう事態を防ぎます。

✅ 以下を追加してAdmissionConfigurationファイルを有効にしましょう。

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

ℹ️ Kubernetes 1.36 – 新たなセキュリティ機能で詳しく解説しています。

#4412 Kubelet Image Credential Providers向けのProjectedサービスアカウントトークン

SIGグループ: sig-auth
ステージ: Betaへの大規模変更
フィーチャーゲート（kubelet）: KubeletServiceAccountTokenForCredentialProviders デフォルト: true
フィーチャーゲート（kube-apiserver）: ServiceAccountNodeAudienceRestriction デフォルト: true

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

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

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グループ: sig-auth
ステージ: Stableへ昇格

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

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

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

SIGグループ: sig-network
ステージ: Stableへ昇格

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

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

#5295 KYAML

SIGグループ: sig-cli
ステージ: Stableへ昇格

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

✅ 曖昧な値による設定ミスを避けるため、可能な場合はKYAMLを使用しましょう。

ℹ️ Kubernetesブログにも注目してください。今後の記事でKYAMLとそれが解消する曖昧さについて詳しく取り上げる予定です。