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

Published by:

清水孝郎

Published:

December 2, 2025

Table of contents

本文の内容は、2025年12月2日に Víctor Jiménez Cerrada, Leonardo Grassoが投稿したブログ(https://www.sysdig.com/blog/kubernetes-1-35-whats-new)を元に日本語に翻訳・再構成した内容となっております。

Kubernetes 1.35 がまもなくリリースされ、セキュリティ機能に 17 の変更が加えられます。

新たなバリデーション、旧技術の非推奨化、ユーザーネームスペースのより広範なサポートなどが含まれています。

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

‍

Kubernetes 1.35 で問題を引き起こす可能性のある変更点

#5573 cgroup v1 のサポート削除

SIG group: sig-node

Stage: Net New to Beta

Kubelet Configuration:failCgroupV1Default:true

Linux カーネルの cgroups 機能は、コンテナの分離とリソースクォータの両方の基盤となるものです。Kubernetes も多くの内部処理でこの機能に依存しています。

cgroups v2 が登場してからすでに約 10 年が経ち、より高度なリソース管理と分離を提供してきました。そのため、ついに初期バージョンのサポートを終了する時が来ました。

⚠️ Kubernetes 1.35 以降、cgroups v1 のサポートはデフォルトで無効化されます。これは最終的な非推奨化と完全削除に向けた第一歩です。

✅ Kubernetes 1.35 へアップグレードする前に、Linux サーバーが cgroups v2 を使用しているか確認してください。

$ stat -fc %T /sys/fs/
cgroup/cgroup2fs

#2535 シークレットを使用したイメージ取得

SIG group: sig-node

Stage: Major Change to Beta

Feature Gate:KubeletEnsureSecretPulledImagesDefault:true

これまで、Pod がイメージへアクセスする権限を持っているかどうかのチェックは、イメージをプルするタイミングでのみ行われていました。つまり、一度イメージがプルされてしまえば、適切な権限がなくても Pod がそのイメージへアクセスできてしまう可能性がありました。

これには回避策があります。ImagePullPolicy を Always に設定すると、kubelet にレジストリへの再検証を間接的に強制できます。ただし、この回避策は直感的でもなければ、完全に安全でもありません。

この改善により、imagePullCredentialsVerificationPolicy というフィールドが追加され、クラスター管理者が「いつ認可検証を行うべきか」を定義できるようになります。

ℹ️ この種の追加検証は、マルチテナントクラスターでは必須です。特定のユーザーの Pod が、他のユーザーのイメージにアクセスできてはならないためです。さらに、この設定は存在する以上、誤って構成される可能性があります。これは、コンテナイメージに機密情報を含めるべきではないもう一つの理由でもあります。

チェックを行わない現在の動作を維持したい場合は NeverVerify を使用できます。NeverVerifyAllowlistedImages を使用すると、preloadedImagesVerificationAllowlist に記載されたイメージを許可できます。また、AlwaysVerify はその名のとおり、常に認証情報の再検証を要求します。

‍

⚠️ 新しいデフォルト値は NeverVerifyPreloadedImages です。この設定では、次のケースでは追加検証が行われません：

kubelet の外部でプルされたイメージ
この機能が無効化されていた間に kubelet がプルしたイメージ

しかし、新しくイメージをプルする際には検証が行われるため、Pod 作成の失敗により、一部のワークロードが動作しなくなる可能性があります。

⚠️ この機能によって、イメージプルの回数が増加します。

✅ 事前に準備し、Pod が必要とするすべてのイメージをプルできる認証情報を確実に持っていることを確認してください。問題がすべて解決するまで、機能ゲートを一時的に無効化するか、Pull Policy を NeverVerify に設定することもできます。

✅ イメージプルに関する監視のしきい値を見直し、不必要なアラートが発生しないようにしてください。また、Pod 作成失敗に関するメトリクスを確認し、Pod が継続的に認証情報の問題に直面していないかどうかを把握してください。

‍

#4006 SPDY からWebSocketへの移行

SIG group: sig-api-machinery

‍Stage: Graduating to Stable

Feature Gate: KUBECTL_REMOTE_COMMAND_WEBSOCKETSDefault:true‍

‍Feature Gate:TranslateStreamCloseWebsocketRequestsDefault:true‍

‍Feature Gate:KUBECTL_PORT_FORWARD_WEBSOCKETSDefault:true‍

‍Feature Gate:PortForwardWebsocketsDefault:true‍

‍Feature Gate:AuthorizePodWebsocketUpgradeCreatePermissionDefault:true

2009 年頃のウェブを覚えていますか？「Web 2.0」という言葉が流行し、Google Wave は真にインタラクティブなウェブ体験を約束して私たちをワクワクさせました。このパラダイムシフトを支えるため、Google は HTTP/1.x を新開発の SPDY プロトコルで置き換えることを提案しました。SPDY は非常に人気となり、HTTP/2 の基盤にまでなりました。

それから多くのことが変わりました。きらびやかな Web 2.0 は今では古い HTML5 と呼ばれ、HTTP/2 の WebSocket は、すでに廃止された SPDY を機能面で遥かに上回っています。しかし、Kubernetes の CLI ツールは依然として SPDY に依存しています。

ただし、この移行にはいくつかのセキュリティ上の影響があります。WebSocket 仕様では、すべての接続が GET メソッドで開始される必要があるため、GET から POST への接続アップグレードが許可されています。これは、読み取り専用ユーザーでも kubectl exec のようなコマンドを実行するために権限を昇格できてしまう可能性があることを意味します。

⚠️ この権限昇格を防ぐために、API サーバーは接続アップグレードが要求された場合、ユーザーが create 動詞の権限を持っていることを必須とするようになります。

✅ Kubernetes 1.35 へアップグレードする前に RBAC ポリシーを見直し、create 権限が必要なユーザーに適切に付与されていることを確認してください。

また、一時的な措置として、AuthorizePodWebsocketUpgradeCreatePermission 機能ゲートを false に設定することで、この新しい権限チェックを無効化することも可能です。

この新しいチェックについての詳細は KEP を参照してください。

kubectl における実装については、私たちの「Kubernetes 1.31 - What’s New?」という記事にさらに詳しい情報があります。

‍

#4872 kube-API サーバにおける Kubelet サービング証明書の検証を強化する

SIG group: sig-auth

Stage: Net New to Alpha
Feature Gate:KubeletCertCNValidationDefault:false

‍kube-apiserver flags:--enable-kubelet-cert-cn-validation, --kubelet-certificate-authority.

現在の API サーバーにおける証明書検証プロセスには、以下を可能にしてしまうセキュリティ上の欠陥があります。

攻撃者が古いノードへアクセスでき、
そのノードにまだ有効な証明書が残っており、
ARP ポイズニングやその他のルーティング攻撃によって古いノードの IP を新しいノードの IP と一致するように設定し、
その証明書を利用して API サーバーに対して新しいノードを偽装し、
結果としてトラフィックを自分自身へ迂回させることができてしまう。

これは簡単な攻撃ではありませんが、証明書の有効期限が切れるよりもマシンの変更が早いクラウド環境では可能です。

⚠️ この問題を防ぐために API サーバーが行う対策のひとつは、kubelet のサービング証明書の Common Name（CN）を system:node: と一致させることを要求することです。この場合、nodename は kubelet が報告する Node オブジェクトの名前です。

✅ この機能を有効にする前に、すべての kubelet の証明書がこの要件を満たしていることを確認してください。kubelet が CSR 経由で証明書を要求している場合は問題ありません。すでにその形式で作成されているためです。しかし、手動または他の仕組みで作成した要件を満たさない証明書がある場合は、再発行が必要になります。

ℹ️ この機能はまだ開発中のため、Kubernetes 1.35 にドキュメントは用意されませんが、KEP に詳細がありますので、将来に向けて準備を始めることができます。

‍

Kubernetes 1.35 における新規拡張機能

#5284 制限付きインパーソネーション

SIG group: sig-auth

Stage: Net New to Alpha

Feature Gate:ConstrainedImpersonationDefault:false

Kubernetes のユーザーインパーソネーション（なりすまし）機能は、あるユーザーが別のユーザーとして振る舞うことを可能にします。

これは、たとえば管理者が認可ポリシーをデバッグする際に役立ちます。一時的に他のユーザーとしてインパーソネートすることで、管理者はそのユーザーとしてリクエストを素早く送信し、それが拒否されるかどうかを確認できます。

しかし、現在の仕組みでは、ユーザーが自分より多くの権限を持つユーザーをインパーソネートすることも可能です。そのため、管理者はインパーソネーション権限を付与する際に注意を払う必要があります。

新しい constrained impersonation 機能は、インパーソネート時のユーザー権限を制限するための追加チェックを導入します。ConstrainedImpersonation を有効にすると、ユーザーはインパーソネートした相手の権限であっても、自分自身が実行できない操作は行えなくなります。

‍

#4828 Kubernetes コンポーネント用フラグ

SIG group: sig-instrumentation

Stage: Major Change to Alpha

Feature Gate:ComponentFlagzDefault:false

statusZ ページと同様に、flagz エンドポイントは Kubernetes コンポーネント向けのランタイム診断を提供します。特に、そのコンポーネントを起動する際に使用されたコマンドライン引数を確認できます。

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

ℹ️ 詳細は「Kubernetes 1.32 - What’s New?」の記事をご覧ください。

‍

#5607 ユーザーネームスペースを使用する HostNetwork Pod を許可する

SIG group: sig-node

‍Stage: Net New to Alpha

Feature Gate:UserNamespacesHostNetworkSupportDefault:false

現在、API サーバーのようなサービスが hostNetwork: true を使用してホストのネットワークスタックに直接アクセスしたい場合、hostUsers: true を使用してホストユーザーも利用しなければなりません。

これはセキュリティ上のリスクです。なぜなら、root として実行されている Pod が侵害された場合、攻撃者がホスト上で root 権限を得ることも容易になるためです。

この拡張により、API サーバーは hostNetwork: true かつ hostUsers: false の Pod を許可し、Pod は Kubernetes のユーザーネームスペースによる分離を維持しながら、ホストのネットワークスタックにアクセスできるようになります。

⚠️ ただし、基盤となるコンテナランタイムがこの組み合わせをサポートしている必要があることに注意してください。サポートしていない場合、Pod は ContainerCreating 状態のまま停止し、例外イベントを報告します。

‍

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

SIG group: sig-storage

Stage: Net New to Alpha

Feature Gate:CSIServiceAccountTokenSecretsDefault:false

現在、クラウドバケットのようなボリュームをマウントするためにアカウントトークンを提供する必要がある場合、そのトークンは Pod 名や Namespace などの機微ではない情報と一緒に VolumeContext に保存されています。

この拡張では、この種の機密データを保存するために設計された新しい Secrets フィールド が提供されます。serviceAccountTokenInSecrets フィールドは、CSI ドライバーに対してトークンを secrets フィールドから取得するよう指示します。

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: example-csi-driver
spec:
  # ... existing fields ...
  tokenRequests:
    - audience: "example.com"
      expirationSeconds: 3600
  # New field for opting into secrets delivery
  serviceAccountTokenInSecrets: true  # defaults to false

⚠️ CSIDriver が serviceAccountTokenInSecrets フィールドを false に設定している場合、API サーバーは警告を出します。

⚠️ また、CSI ドライバーの開発者は、これらの新しい Secret のサポートを実装する必要があることにも注意してください。

‍

Kubernetes 1.35 でデフォルトで有効になる既存の拡張機能

#4317 Pod Certificates

SIG group: sig-auth

Stage: Graduating to Beta

Feature Gate:PodCertificateRequestDefault:true

Kubernetes 1.19 では、証明書署名要求（CSR）API がステーブルに昇格し、X.509 証明書を要求・取得するためのシンプルな仕組みが提供されました。

しかし、その証明書をワークロードに提供する簡単な方法はありませんでした。

この拡張では次のものが導入されます：

PodCertificateRequest API：Pod 向けに証明書を発行するための仕組み
PodCertificate ボリュームソース：kubelet に対して、その Pod 用の証明書をプロビジョニングするよう指示する仕組み

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: pod-certificates-example
spec:
  restartPolicy: OnFailure
  automountServiceAccountToken: false
  containers:
  - name: main
		…
    volumeMounts:
    - name: spiffe-credentials
      mountPath: /run/workload-spiffe-credentials
  volumes:
  - name: spiffe-credentials
    projected:
      sources:
      - podCertificate:
          signerName: "row-major.net/spiffe"
          keyType: ED25519
          credentialBundlePath: credentialbundle.pem

この機能は、面倒で繰り返し発生する作業をとても簡単にし、セキュリティの実装も容易にします。好きにならない理由はありませんよね？

‍

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

SIG group: sig-node

‍Stage: Graduating to Beta

Feature Gate:UserNamespacesSupportDefault:true

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

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

このような Pod が侵害され、攻撃者がコンテナからエスケープすることに成功したとしても、ホスト上では非特権ユーザーとして実行されるため、影響は限定的です。

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

ℹ️ 詳しくは「Kubernetes 1.25 - What’s New?」の記事をご覧ください。

‍

#4639 ボリュームソース:OCI アーティファクトおよび/またはイメージ

SIG group: sig-node

Stage: Graduating to Beta

Feature Gate:ImageVolumeDefault:true

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

これにより、開発者はバイナリを構成ファイルやその他のアセットから分離でき、デプロイが簡素化され、イメージの再利用も可能になります。

シンプルなユースケースとしては、nginx のような Web サーバーが挙げられます。現在、Web サイトをデプロイするには、nginx をベースにしたイメージを作成し、その上にすべてのアセットを追加する必要があります。これをすべてのサイトで行うと、多くの重複が生じます。

今回の機能により、すべての Web サイトの Pod で同じベースイメージ（image volumes を使用するよう調整されたもの）を利用し、構成ファイルや Web アセットを別の最小限のイメージに分離してデプロイできるようになります。

これらの oci-volume の定義は、以下のように行います。

kind: Pod
metadata:
  name: example-pod
spec:
  volumes:
  - name: oci-volume
    image:
      reference: "example.com/my-image:latest"
      pullPolicy: IfNotPresent
  containers:
  - name: my-container
    image: busybox
    volumeMounts:
    - mountPath: /data
      name: oci-volume

⚠️ しかし、この方法で OCI イメージをマウントできるようにすると、潜在的な攻撃経路が生まれる可能性があります。

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

ℹ️ 詳しくは「Kubernetes 1.33 - What’s New?」をご覧ください。

‍

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

SIG group: sig-cli

Stage: Graduating to Beta

Environment Variable:KUBECTL_KUBERCDefault:true

Kubernetes CLI に kuberc ファイル（~/.kube/kuberc） が追加されたことで、ユーザーはクラスターの認証情報やサーバー設定を、ユーザー固有の設定から明確に分離できるようになりました。

これは、異なる設定を異なるクライアントに適用できるよう設計されています。たとえば、ローカルクライアントでは削除確認を必須にしつつ、CI パイプラインでは必須にしない、といったことが可能になります。

ℹ️ Kubernetes 1.35 から、新しい credentialPluginPolicy フィールドが利用できるようになり、kubectl がどの認証プラグインを実行できるかを制限できるようになりました。

任意の kubeconfig ファイルは、users[n].exec.command フィールドを定義し、kubectl が代理で実行する「認証プラグイン」実行ファイルを指定できます。これは外部 ID プロバイダーでクラスター認証を行うための補助機能として意図されています。しかし同時に、kubectl が気づかないうちに任意の実行ファイルを実行してしまう可能性があるため、攻撃経路にもなり得ます。

credentialPluginPolicy はデフォルトで AllowAll（すべての実行ファイルを許可）になります。これを DenyAll に設定すると、いかなる実行ファイルも実行されなくなります。この設定はプラグインの棚卸しにも役立ち、kubectl がプラグインを実行しようとするとエラーメッセージが表示されます。

最後に、Allowlist を設定し、さらに credentialPluginAllowlist に定義されたプラグインのみ許可するよう制限することも可能です。

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
credentialPluginPolicy: Allowlist
credentialPluginAllowlist:
  - name: /usr/local/bin/cloudco-login
  - name: get-identity

ℹ️ 詳しくは「Kubernetes 1.31 - What’s New?」の記事をご覧ください。

‍

#5589 Kubernetes の API タイプから gogo protobuf の依存関係を削除する

SIG group: sig-api-machinery

Stage: Major Change to Stable

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

この拡張は、Kubernetes の API オブジェクトからこれらの依存関係を取り除くことに重点を置いています。代わりに、標準の golang protobuf ライブラリが使用されます。

ℹ️ 実装の詳細については KEP を確認するか、PR を参照してください。

‍

#3331 構造化認証設定

SIG group: sig-auth

Stage: Graduating to Stable

Feature Gate:StructuredAuthenticationConfigurationDefault:true

現在、API サーバーの認証は、--oidc-issuer-url、--oidc-client-id、--oidc-username-claim などの複数のコマンドフラグを使用して構成できます。

この拡張により、--authentication-config フラグで指定されたコンフィグファイルを使って認証設定を行えるようになります。

apiVersion: apiserver.config.k8s.io/v1
kind: AuthenticationConfiguration
jwt:
- issuer:
    url: <https://example.com> # Same as --oidc-issuer-url
    audiences:
    - my-app # Same as --oidc-client-id.
  claimMappings:
    username:
      expression: 'claims.username + ":external-user"'
    groups:
      expression: 'claims.roles.split(",")'
    uid:
      expression: 'claims.sub'
    extra:
    - key: 'example.com/tenant'
      valueExpression: 'claims.tenant'
  userValidationRules:
  - expression: "!user.username.startsWith('system:')"
    message: 'username cannot used reserved system: prefix'

この変更の背後にある主な目標は、柔軟性を高め、次のことを可能にすることです。

サーバーを再起動することなく設定を更新できる。
複数の audience クレームを定義できる。
完全一致ではなく式を使用できる。
複数の OIDC プロバイダーを使用できる。

ℹ️ おまけに、この構成を構造ファイルに入れると、構成ミスやセキュリティポリシーのドリフトを簡単にチェックできます。

⚠️ --authentication-config フラグは、従来の --oidc-* コマンドライン引数とは互換性がないことに注意してください。API サーバーはこれを誤った設定として報告し、直ちに終了します。

‍

#859 kubectl コマンドのメタデータを http リクエストヘッダーに含める

SIG group: sig-cli

Stage: Graduating to Stable

Environment Variable:KUBECTL_COMMAND_HEADERSDefault:true

しばらくの間、kubectl は API サーバーへのリクエストに追加の HTTP ヘッダーを含めていました。今回、この機能がステーブルとして扱われるようになりました。

$ kubectl apply -f - -o yaml
Kubectl-Command: apply
Kubectl-Session: 67b540bf-d219-4868-abd8-b08c77fefeca

ℹ️ 同じセッションで実行されたすべてのコマンドを追跡できると、kubectlコマンドから発生したセキュリティインシデントを調査する際のコンテキストがわかります。

ℹ️ 詳しくは「Kubernetes 1.22 - What’s New?」をご覧ください。

‍

#3619 きめ細やかな SupplementalGroups コントロール

SIG group: sig-node

Stage: Graduating to Stable

Feature Gate:SupplementalGroupsPolicyDefault:true

Linux ユーザーは、/etc/group ファイルで定義されている主グループ以外に、複数のグループに所属することがあります。

$ id golo
uid=1000(golo) gid=1000(golo) groups=1000(golo),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),122(lpadmin),135(lxd),136(sambashare),137(vboxusers)

コンテナイメージが独自のグループを /etc/group ファイル内に定義している場合、Kubernetes はデフォルトで、それを Pod で定義されたグループ情報とマージします。

ℹ️ これは危険です。悪意のあるコンテナイメージが権限昇格を狙って /etc/group ファイルを細工する可能性があるためです。

この（現在はステーブルとなった）機能では、Pod 定義に supplementalGroupsPolicy フィールドが追加されました。デフォルトの Merge ではなく Strict に設定すると、Kubernetes は Pod 設定内で定義されていないグループ構成をすべて無視します。

apiVersion: v1
kind: Pod
metadata:
  name: strict-supplementalgroups-policy
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    supplementalGroups: [4000]
    supplementalGroupsPolicy: Strict
…

ℹ️ 詳細は Kubernetes ブログをご覧ください。

‍

#3983 drop-in kubelet 設定ディレクトリのサポートを追加

SIG group: sig-node

Stage: Graduating to Stable

Config Flag:--config-dirDefault: ''

複数のリリースでベータ版として提供されてきたこの機能は、現在ではステーブルとみなされています。

他の Linux ツールと同様に、kubelet の設定用にドロップインディレクトリ（例：/etc/kubernetes/kubelet.conf.d）を定義できるようになりました。

有効な kubelet 設定は、kubectl proxy と configz エンドポイントを使用して確認できます。

$ kubectl proxy
Starting to serve on 127.0.0.1:8001

$ curl -X GET <http://127.0.0.1:8001/api/v1/nodes/><node-name>/proxy/configz | jq .
{
  "kubeletconfig": {
    "enableServer": true,
    "staticPodPath": "/var/run/kubernetes/static-pods",
…

ℹ️ この手法が Linux で広く使われているのには理由があります。設定の透明性が高まり、保守しやすく、誤りが発生しにくくなるためです。Kubernetes においても、OWASP Top 10 for Kubernetes に沿った構成管理のベストプラクティスを支援します。

ℹ️ 詳細は「Kubernetes 1.32 - What’s new?」または Kubernetes ドキュメントをご覧ください。

‍

まとめ

このブログを気に入った方は、ぜひ過去の『Kubernetesの新機能』エディションもチェックしてみてください。Kubernetes プロジェクトに参加しましょう:

Kubernetes プロジェクトに参加しましょう:

‍

About the author

Open Source

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

デモを申し込む

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

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

Kubernetes 1.35 で問題を引き起こす可能性のある変更点

#5573 cgroup v1 のサポート削除

#2535 シークレットを使用したイメージ取得

#4006 SPDY からWebSocketへの移行

#4872 kube-API サーバにおける Kubelet サービング証明書の検証を強化する

Kubernetes 1.35 における新規拡張機能

#5284 制限付きインパーソネーション

#4828 Kubernetes コンポーネント用フラグ

#5607 ユーザーネームスペースを使用する HostNetwork Pod を許可する

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

Kubernetes 1.35 でデフォルトで有効になる既存の拡張機能

#4317 Pod Certificates

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

#4639 ボリュームソース:OCI アーティファクトおよび/またはイメージ

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

#5589 Kubernetes の API タイプから gogo protobuf の依存関係を削除する

#3331 構造化認証設定

#859 kubectl コマンドのメタデータを http リクエストヘッダーに含める

#3619 きめ細やかな SupplementalGroups コントロール

#3983 drop-in kubelet 設定ディレクトリのサポートを追加

まとめ

About the author

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