セキュリティに関する情報

Kubernetes Engine に関連するセキュリティ情報は随時リリースされます。Google Kubernetes Engine に関するすべてのセキュリティ情報は、ここで説明されています。

脆弱性に関する情報は多くの場合、影響を受けた当事者が対処するまで、情報制限により非公開となります。このような場合、GKE のリリースノートには、情報制限が解除されるまで「セキュリティ更新」が記載されます。リリースノートは情報制限が解除された時点で更新され、パッチによって対処された脆弱性の情報が反映されます。

GKE セキュリティ情報を購読する。 購読

2019 年 2 月 11 日(runc)

説明 重大度

先ごろ、Open Containers Initiative(OCI)によって runc に新しいセキュリティ上の脆弱性 CVE-2019-5736 が存在することが発見されました。この脆弱性により、コンテナがエスケープ処理を行ってホストノードのルート権限を奪ってしまうおそれがあります。

この脆弱性の影響を受けるのは Google Kubernetes Engine(GKE)Ubuntu ノードです。Ubuntu ノードをご利用のお客様は、できるだけ早く最新のパッチ バージョンにアップグレードすることをおすすめします。詳細については、以下をご覧ください。

必要な対策

ご使用のノードをアップグレードするには、まずマスターを最新バージョンにアップグレードする必要があります。このパッチは Kubernetes 1.10.12-gke.7、1.11.6-gke.11、1.11.7-gke.4、1.12.5-gke.5、およびそれ以降のリリースで入手できます。パッチの提供状況については、リリースノートをご覧ください。

影響を受けるのは GKE の Ubuntu ノードだけです。COS を実行しているノードは影響を受けません。

新しいバージョンの runc はメモリ使用量が以前より増加しているため、メモリ上限を低く(16 MB 未満に)設定している場合はコンテナに割り当てられるメモリを更新しなければならないことがあります。

このパッチで対処される脆弱性

このパッチで緩和される脆弱性は以下のとおりです。

CVE-2019-5736 は runc の脆弱性であり、悪意のあるコンテナが(exec の形式での最小限のユーザー インタラクションで)ホストの runc バイナリを上書きすることにより、ホストノードでルート権限のコードを実行できてしまうというものです。root として実行されているコンテナを対象とするこの脆弱性の重大度評価は高です。

CVE-2019-5736

2019 年 2 月 11 日(Go)

説明 重大度

先ごろ、Go プログラミング言語に新しいセキュリティ上の脆弱性 CVE-2019-6486 が存在することが発見されました。これは P-521 と P-384 の楕円曲線の暗号および楕円に関する実装に問題があり、サービス拒否攻撃(DoS)を受ける可能性があるというものです。Google Kubernetes Engine(GKE)に影響があるこの脆弱性を利用して、悪意のあるユーザーは、Kubernetes API サーバーの CPU を大量に消費するリクエストを送りつけ、クラスタ コントロール プレーンの可用性を低下させてしまうおそれがあります。詳細については、Go プログラミング言語の開示情報をご覧ください。

この脆弱性の影響を受けるのは、すべての Google Kubernetes Engine(GKE)マスターです。最新バージョンのパッチには、この脆弱性の緩和対策が含まれています。定期的なアップグレード サイクルの一環として、クラスタ マスターは、今後数週間以内にパッチ適用済みバージョンに自動アップグレードされる予定です。

必要な対策

ご対応は必要ありません。GKE マスターは、定期的なアップグレード サイクルで自動的にアップグレードされます。マスターをすぐにアップグレードすることをご希望の場合は、手動でマスター アップグレードを開始することもできます。

このパッチは GKE 1.10.12-gke.7、1.11.6-gke.11、1.11.7-gke.4、1.12.5-gke.5、およびそれ以降のリリースで入手できます。

このパッチで対処される脆弱性

このパッチで緩和される脆弱性は以下のとおりです。

CVE-2019-6486 は、P-521 と P-384 の楕円曲線の暗号および楕円の実装における脆弱性です。悪意のあるユーザーがこの脆弱性を利用して、CPU を大量に消費するリクエストを送りつけることができてしまいます。

CVE-2019-6486

2018 年 12 月 3 日

説明 重大度

先ごろ、Kubernetes にセキュリティ上の脆弱性 CVE-2018-1002105 が存在することが発見されました。これは、比較的権限の低いユーザーが kubelet の API に対する権限付与をバイパスして、クラスタ内のポッドやノードに対して任意のオペレーションを実行できてしまうというものです。詳細については、Kubernetes の開示情報をご覧ください。 この脆弱性の影響を受けるのは、すべての Google Kubernetes Engine(GKE)マスターです。Google では、すでにクラスタを最新のパッチ バージョンにアップグレード済みです。ご対応は必要ありません。

必要な対策

ご対応は必要ありません。GKE マスターはすでにアップグレード済みです。

このパッチは GKE 1.9.7-gke.11、1.10.6-gke.11、1.10.7-gke.11、1.10.9-gke.5、1.11.2-gke.18、およびそれ以降のリリースで入手できます。

このパッチで対処される脆弱性

このパッチで緩和される脆弱性は以下のとおりです。

脆弱性 CVE-2018-1002105 は、比較的権限の低いユーザーが kubelet の API に対する権限付与をバイパスできてしまうというものです。これにより、ユーザーはアップグレード可能なリクエストを作成してエスカレーションし、kubelet の API を任意に呼び出せてしまいます。この Kubernetes の脆弱性は重大と評価されています。GKE の実装では未認証のエスカレーション パスを防ぐことに注意が払われているため、この脆弱性は高と評価されています。

CVE-2018-1002105

2018 年 11 月 13 日

説明

2018 年 11 月 16 日更新: 影響を受けた可能性のあるすべてのトークンの取り消しと入れ替えが完了しました。以後の対応は特に必要はありません。

特定の構成にて機密情報を記録できる Calico Container Network Interface(CNI)プラグインに問題が見つかりました。この問題は Tigera Technical Advisory TTA-2018-001 で追跡されています。

  • Calico CNI プラグインをデバッグレベルのロギングで実行する場合、Kubernetes API クライアントの構成がログに書き込まれます。
  • CNI ネットワーク構成で「k8s_auth_token」フィールドが設定されている場合、Calico CNI は Kubernetes API トークンも情報レベルでログに書き込みます。
  • さらに、デバッグレベルのロギングで実行する場合、Calico で読み取られた Calico 構成ファイルか、Calico で使用される環境変数にサービス アカウント トークンが明示的に設定されていると、Calico コンポーネント(calico/node、felix、CNI)がその情報をログファイルに書き込みます。

これらのトークンには、次の権限があります。


bgpconfigurations.crd.projectcalico.org     [create get list update watch]
bgppeers.crd.projectcalico.org              [create get list update watch]
clusterinformations.crd.projectcalico.org   [create get list update watch]
felixconfigurations.crd.projectcalico.org   [create get list update watch]
globalbgpconfigs.crd.projectcalico.org      [create get list update watch]
globalfelixconfigs.crd.projectcalico.org    [create get list update watch]
globalnetworkpolicies.crd.projectcalico.org [create get list update watch]
globalnetworksets.crd.projectcalico.org     [create get list update watch]
hostendpoints.crd.projectcalico.org         [create get list update watch]
ippools.crd.projectcalico.org               [create get list update watch]
networkpolicies.crd.projectcalico.org       [create get list update watch]
nodes                                       [get list update watch]
pods                                        [get list watch patch]
namespaces                                  [get list watch]
networkpolicies.extensions                  [get list watch]
endpoints                                   [get]
services                                    [get]
pods/status                                 [update]
networkpolicies.networking.k8s.io           [watch list]
      

クラスタ ネットワーク ポリシーと Stackdriver Logging が有効になっている Google Kubernetes Engine クラスタが、Calico サービス アカウント トークンを Stackdriver に記録していました。ネットワーク ポリシーが有効になっていないクラスタは影響を受けていません。

警告レベルでのみログを記録するように Calico CNI プラグインを切り替え、新しいサービス アカウントを使用する修正プログラムを導入しました。パッチが適用された Calico コードは、今後のリリースで導入される予定です。

影響を受けた可能性のあるトークンの取り消しを、来週中に段階的に実施していく予定です。取り消しが完了次第、こちらの情報も更新いたします。お客様側でのご対応は特に必要ありません (このトークン入れ替え作業は 2018 年 11 月 16 日に完了しました)。

これらのトークンをすぐに入れ替えたい場合は、次のコマンドを実行してください。サービス アカウントの新しいシークレットが数秒以内に自動で再作成されます。


kubectl get sa --namespace kube-system calico -o template --template '&#123&#123(index .secrets 0).name&#125&#125' | xargs kubectl delete secret --namespace kube-system
      

検出

GKE は、API サーバーへのアクセスをすべて記録します。Google Cloud で想定されている IP 範囲外から Calico トークンが使用されたかどうかを判断するには、次の Stackdriver クエリを実行します。このクエリは、GCP のネットワーク外から行われた呼び出しの記録のみを返す点にご留意ください。また、必要に応じて、ご使用の環境に合わせてカスタマイズしてください。


resource.type="k8s_cluster"
protoPayload.authenticationInfo.principalEmail="system:serviceaccount:kube-system:calico"
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.34.208.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.192.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "8.35.200.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.59.80.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.208.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.216.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.220.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "108.170.222.0/24")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.224.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.216.148.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "162.222.176.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "173.255.112.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "192.158.28.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.192.112.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.232.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "199.223.236.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.236.48.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "23.251.128.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.204.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.208.0.0/13")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.167.160.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "107.178.192.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.2.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "146.148.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.240.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.8.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.16.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.32.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.64.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.128.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.154.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "104.196.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "208.68.108.0/23")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.184.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.188.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.202.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.192.0/19")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.192.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.196.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.198.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.199.128.0/18")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.200.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "2600:1900::/35")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.190.224.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.232.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.234.0.0/16")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.0.0/17")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.235.192.0/20")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.236.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.240.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.203.232.0/21")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "130.211.4.0/22")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.220.0.0/14")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.242.0.0/15")
NOT ip_in_net(protoPayload.requestMetadata.callerIp, "35.244.0.0/14")
      

2018 年 8 月 14 日

説明 重大度

Intel により次の CVE が開示されました。

これらの CVE は「L1 Terminal Fault(L1TF)」と総称されます。

これらの L1TF 脆弱性は、投機的実行を悪用してプロセッサ レベルのデータ構造の構成を攻撃します。「L1」とは、レベル 1 データ キャッシュ(L1D)と呼ばれるコア内の小さなリソースで、メモリアクセスを高速化するために使用されます。

これらの脆弱性と Compute Engine の緩和策の詳細については、Google Cloud ブログの記事をご覧ください。

Google Kubernetes Engine への影響

Kubernetes Engine を実行しお客様のクラスタとノードを相互に分離するインフラストラクチャは、既知の攻撃から保護されています。

Google の Container-Optimized OS(COS)イメージを使用していて自動アップグレードが有効な場合、COS イメージのパッチ適用済みバージョンが 2018 年 8 月 20 日の週から利用可能になると、Kubernetes Engine ノードプールがそのバージョンに自動更新されます。

自動アップグレードが無効な場合、COS イメージのパッチ適用済みバージョンが利用可能になったら、Kubernetes Engine ノードプールを手動でアップグレードする必要があります。

2018 年 8 月 6 日、最終更新日: 2018 年 9 月 5 日

説明 重大度

2018 年 9 月 5 日更新

CVE-2018-5391 が先ごろ公表されました。これは、CVE-2018-5390 と同様にカーネルレベルのネットワーク脆弱性で、脆弱性のあるシステムがサービス拒否(DoS)攻撃を受ける可能性が高まります。主な違いは、CVE-2018-5391 は IP 接続上で悪用されることです。両方の脆弱性に対応するために、この情報を更新しました。

説明

CVE-2018-5390(「SegmentSmack」)はカーネルレベルのネットワーク脆弱性で、脆弱性のあるシステムが TCP 接続でサービス拒否(DoS)攻撃を受ける可能性が高まります。

CVE-2018-5391(「FragmentSmack」)はカーネルレベルのネットワーク脆弱性で、脆弱性のあるシステムが IP 接続でサービス拒否(DoS)攻撃を受ける可能性が高まります。

Google Kubernetes Engine への影響

2018 年 8 月 11 日現在、Kubernetes Engine ではすべてのマスターが両方の脆弱性から保護されています。また、自動的にアップグレードするように構成されているどの Kubernetes Engine クラスタも、両方の脆弱性から保護されています。自動アップグレードするように構成せず、2018 年 8 月 11 日より前に最後に手動でアップグレードした Kubernetes Engine ノードプールは、両方の脆弱性の影響を受けます。

パッチを適用したバージョン

この脆弱性の重大性により、パッチが利用可能になったらすぐにノードを手動でアップグレードすることをおすすめします。

2018 年 5 月 30 日

説明 重大度

先ごろ、Git に脆弱性が存在することが発見されました。この脆弱性により、権限のないユーザーによる gitRepo ボリュームを使用したポッド作成が許可されている場合、Kubernetes で権限をエスカレーションできてしまうおそれがあります。CVE はタグ CVE-2018-11235 で識別されます。

影響を受けるかどうか

この脆弱性は、以下のすべてに当てはまる場合に影響します。

  • 信頼できないユーザーがポッドを作成できる(またはポッド作成をトリガーできる)。
  • 信頼できないユーザーによって作成されたポッドに、(PodSecurityPolicy などを使用して)ホストの root アクセス権を防止する制限がある。
  • 信頼できないユーザーによって作成されたポッドで、gitRepo ボリューム タイプの使用が許可されている。

すべての Kubernetes Engine ノードに脆弱性があります。

必要な対策

gitRepo ボリューム タイプの使用を禁止します。PodSecurityPolicy を利用して gitRepo ボリュームを禁止するには、PodSecurityPolicy の volumes ホワイトリストから gitRepo を除外します。

同等の gitRepo ボリュームの動作を実現するには、Git リポジトリを initContainer から EmptyDir ボリュームに複製します。


apiVersion: v1
kind: Pod
metadata:
  name: git-repo-example
spec:
  initContainers:
    # This container clones the desired git repo to the EmptyDir volume.
    - name: git-clone
      image: alpine/git # Any image with git will do
      args:
        - clone
        - --single-branch
        - --
        - https://github.com/kubernetes/kubernetes # Your repo
        - /repo # Put it in the volume
      securityContext:
        runAsUser: 1 # Any non-root user will do. Match to the workload.
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
      volumeMounts:
        - name: git-repo
          mountPath: /repo
  containers:
    ...
  volumes:
    - name: git-repo
      emptyDir: {}

この脆弱性に対処するパッチ

パッチは今後の Kubernetes Engine リリースに含まれます。詳細については、随時こちらでご確認ください。

2018 年 5 月 21 日

説明 重大度

先ごろ、Linux カーネルにいくつかの脆弱性が存在することが発見されました。こうした脆弱性により、権限のないプロセスからの権限エスカレーションや(カーネルのクラッシュによる)サービス拒否を実行できてしまうおそれがあります。各 CVE はタグ CVE-2018-1000199CVE-2018-8897CVE-2018-1087 で識別されます。これらの脆弱性の影響を受けるのはすべての Kubernetes Engine ノードですので、最新のパッチ バージョンにアップグレードすることをおすすめします。詳細については、以下をご覧ください。

必要な対策

アップグレードするには、まずマスターを最新バージョンにアップグレードする必要があります。このパッチは Kubernetes Engine 1.8.12-gke.1、Kubernetes Engine 1.9.7-gke.1、Kubernetes Engine 1.10.2-gke.1 で入手できます。これらのリリースには、Container-Optimized OS と Ubuntu の両方のイメージのパッチが含まれています。

その前に新しいクラスタを作成する場合、使用するにはパッチ適用済みバージョンを指定する必要があります。ノードの自動アップグレードを有効にしており、手動でアップグレードしないお客様は、数週間以内にノードがパッチ適用済みバージョンにアップグレードされます。

このパッチで対処される脆弱性

このパッチで緩和される脆弱性は以下のとおりです。

CVE-2018-1000199: この脆弱性は Linux カーネルに影響を及ぼします。権限のないユーザーまたはプロセスがシステム カーネルをクラッシュできるようになり、DoS 攻撃や権限エスカレーションが発生します。脆弱性の重大度評価は高で、CVSS は 7.8 です。

CVE-2018-8897: この脆弱性は Linux カーネルに影響を及ぼします。権限のないユーザーまたはプロセスがシステム カーネルをクラッシュできるようになり、DoS 攻撃が発生します。脆弱性の重大度評価は中で、CVSS は 6.5 です。

CVE-2018-1087: この脆弱性は Linux カーネルの KVM ハイパーバイザに影響を及ぼします。権限のないプロセスがゲストカーネルをクラッシュできるようになり、場合によっては権限を取得できてしまいます。Kubernetes Engine が実行されているインフラストラクチャに脆弱性のパッチが適用されるため、Kubernetes Engine は影響を受けません。脆弱性の重大度評価は高で、CVSS スコアは 8.0 です。

2018 年 3 月 12 日

説明 重大度

先ごろ、Kubernetes プロジェクトにより、新しいセキュリティ脆弱性が公表されました。この脆弱性は CVE-2017-1002101CVE-2017-1002102 で、コンテナの外部にあるファイルにコンテナからアクセスできてしまうというものです。これらの脆弱性の影響を受けるのはすべての Kubernetes Engine ノードですので、できるだけ早く最新のパッチ バージョンにアップグレードすることをおすすめします。詳細については、以下をご覧ください。

必要な対策

これらの脆弱性の重大性により、ノードの自動アップグレードが有効であるかどうかにかかわらず、パッチが利用可能になったらすぐにノードを手動でアップグレードすることをおすすめします。このパッチは 3 月 16 日までにすべてのお客様が使用できるようになりますが、リリース スケジュールに従い、クラスタが属するゾーンによっては早めに利用可能になる場合があります。

アップグレードするには、まずマスターを最新バージョンにアップグレードする必要があります。このパッチは Kubernetes 1.9.4-gke.1、Kubernetes 1.8.9-gke.1、Kubernetes 1.7.14-gke.1 で入手できます。新しいクラスタでは、3 月 30 日までデフォルトでパッチ適用済みバージョンが使用されます。それまでに新しいクラスタを作成する場合は、パッチ適用済みバージョンを指定して使用する必要があります。

ノードの自動アップグレードを有効にしており、手動でアップグレードしない Kubernetes Engine のお客様は、4 月 23 日までにノードがパッチ適用済みバージョンにアップグレードされます。しかし、脆弱性の性質上、パッチが利用可能になったらすぐにノードを手動でアップグレードすることをおすすめします。

このパッチで対処される脆弱性

このパッチで緩和される脆弱性は以下の 2 つです。

脆弱性 CVE-2017-1002101 により、subPath ボリューム マウントを使用しているコンテナがボリュームの外部にあるファイルにアクセスできてしまいます。つまり、PodSecurityPolicy で hostPath ボリュームへのコンテナ アクセスをブロックしている場合、ポッドを更新または作成できる攻撃者が他のボリューム タイプを使用して任意の hostPath をマウントするおそれがあります。

脆弱性 CVE-2017-1002102 により、特定のボリューム タイプ(シークレット、構成マップ、予測ボリューム、下位 API ボリュームなど)を使用するコンテナがボリュームの外部にあるファイルを削除できてしまいます。つまり、これらのボリューム タイプのいずれかを使用するコンテナが不正使用された場合、または信頼できないユーザーによるポッド作成が許可されている場合、攻撃者がそのコンテナを利用してホスト上の任意のファイルを削除するおそれがあります。

この修正の詳細については、Kubernetes ブログの記事をご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...