ワークロード構成の問題を自動的に監査する

このページでは、Google Kubernetes Engine（GKE）Autopilot クラスタと Standard クラスタのセキュリティ ポスチャーを強化するために、セキュリティ問題に関するワークロード構成の自動監査と実行可能な推奨事項の入手方法について説明します。ワークロード構成の監査を有効にする方法、テスト ワークロードをデプロイする方法、構成の監査結果を表示して対処する方法、ワークロード構成の監査を無効にする方法について説明します。また、ワークロード構成監査の料金、要件、制限事項についても説明します。

このページは、GKE Autopilot クラスタと Standard クラスタでワークロード構成を自動的に監査する方法について詳しく知りたいと考えている、GKE クラスタのセキュリティをモニタリングするセキュリティ スペシャリストを対象としています。 Trusted Cloud by S3NS のコンテンツで使用されている一般的なロールとタスクの例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

ワークロード構成の監査はセキュリティ ポスチャー ダッシュボードの機能であるため、このページを読む前に次のコンセプトをよく理解しておいてください。

• セキュリティ ポスチャー ダッシュボードの概要
• ワークロード構成監査について

料金

GKE では、Container Security API を通じてセキュリティ対策ダッシュボードを追加料金なしでご利用いただけます。

Cloud Logging に追加されたエントリには Cloud Logging の料金が適用されます。

始める前に

始める前に、次の作業が完了していることを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

• Container Security API を有効にします。

  Container Security API の有効化

• バージョン 1.21 以降を実行する Autopilot クラスタまたは Standard クラスタがあることを確認します。新しいクラスタを作成するには、Autopilot クラスタの作成をご覧ください。

要件

• ワークロード構成の監査に必要な権限を取得するには、ご使用の Trusted Cloud プロジェクトに対するセキュリティ ポスチャー閲覧者（roles/containersecurity.viewer）IAM ロールを付与するよう管理者に依頼してください。ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

  この事前定義ロールには、ワークロード構成の監査に必要な権限が含まれています。必要とされる正確な権限については、「必要な権限」セクションを開いてご確認ください。

  必要な権限

  ワークロード構成の監査には次の権限が必要です。

  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • containersecurity.locations.list
  • containersecurity.locations.get
  • containersecurity.clusterSummaries.list
  • containersecurity.findings.list

  カスタムロールや他の事前定義ロールを使用して、これらの権限を取得することもできます。

• ワークロード構成の監査には、GKE バージョン 1.21 以降が必要です。

ワークロード構成の監査を有効にする

バージョン 1.27 以降を実行している新しい Autopilot クラスタと Standard クラスタでは、ワークロード構成の監査がデフォルトで有効になっています。この機能は、gcloud CLI または Trusted Cloud コンソールを使用して手動で有効にすることもできます。

既存のクラスタで構成の監査を有効にする

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --security-posture=standard

Google Kubernetes Engine（GKE）Enterprise エディションを使用してクラスタのフリートを管理する場合は、すべてのメンバー クラスタに適用されるフリートレベルの構成監査設定を構成することもできます。手順については、フリートレベルで GKE セキュリティ対策ダッシュボードの機能を構成するをご覧ください。

テスト ワークロードをデプロイする

Pod のセキュリティ基準に意図的に違反しているサンプル アプリケーションをデプロイします。

1. 次のマニフェストを misconfig-sample.yaml として保存します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloweb
     labels:
       app: hello
   spec:
     selector:
       matchLabels:
         app: hello
         tier: web
     template:
       metadata:
         labels:
           app: hello
           tier: web
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
           ports:
           - containerPort: 8080
           securityContext:
             runAsNonRoot: false
           resources:
             requests:
               cpu: 200m
   

2. アプリケーションをクラスタにデプロイします。

   kubectl apply -f misconfig-sample.yaml
   

他の違反を試す場合は、misconfig-sample.yaml を対応する「不適切な」構成に変更します。

構成の監査結果の表示とアクション

最初の監査で結果が返されるまでに最大 15 分かかります。結果はセキュリティ対策ダッシュボードに表示され、クラスタログにエントリが自動的に追加されます。

結果を表示する

プロジェクトのクラスタとワークロードで検出された懸念事項の概要を表示する手順は次のとおりです。

1. Trusted Cloud コンソールの [セキュリティ ポスチャー] ページに移動します。

   [セキュリティ ポスチャー] に移動

2. [懸念事項] タブをクリックします。

3. [懸念事項のフィルタ] ペインの [問題の種類] セクションで、[構成] チェックボックスをオンにします。

懸念事項の詳細と推奨事項を表示する

特定の構成に関する懸念事項の詳細情報を表示するには、その懸念事項を含む行をクリックします。

[構成に関する問題] ペインに次の情報が表示されます。

• 説明: 懸念事項の説明。
• 推奨される対応: 構成の問題を解決するために実行できるアクションの概要。このセクションには次の情報が表示されます。
  • 修正が必要なリソース
  • 影響を受けるリソースに修正を適用するために実行できるサンプル コマンド
  • Trusted Cloud コンソールで問題を解決する手順（該当する場合）

検出された懸念事項のログを表示する

GKE は、検出された懸念事項ごとに Logging の _Default ログバケットにエントリを追加します。これらのログは特定の期間のみ保持されます。詳細については、ログの保持期間をご覧ください。

1. Trusted Cloud コンソールで [ログ エクスプローラ] に移動します。

   [ログ エクスプローラ] に移動

2. [クエリ] フィールドに次のクエリを規定します。

   resource.type="k8s_cluster"
   jsonPayload.@type="type.googleapis.com/cloud.kubernetes.security.containersecurity_logging.Finding"
   jsonPayload.type="FINDING_TYPE_MISCONFIG"

3. [クエリを実行] をクリックします。

GKE が Logging に新しい検出結果を追加したときに通知を受け取るには、このクエリのログベースのアラートを設定します。詳細については、ログベースのアラートの管理をご覧ください。

クリーンアップ

1. デプロイしたサンプル ワークロードを削除します。

   kubectl delete deployment helloweb
   

2. 必要に応じて、使用したクラスタを削除します。

   gcloud container clusters delete CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

ワークロード構成の監査を無効にする

ワークロード構成の監査を無効にするには、gcloud CLI または Trusted Cloud コンソールを使用します。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --security-posture=disabled

ワークロード構成の監査の制限事項

• Windows Server ノードプールはサポートされていません。
• ワークロード構成の監査では、kube-system Namespace のワークロードなど、GKE が管理するワークロードはスキャンされません。
• ワークロード構成の監査は、ノード数が 1,000 未満のクラスタでのみ使用できます。

• セキュリティ対策ダッシュボードは、クラスタごとに最大 150,000 件のアクティブなワークロード構成監査結果をサポートしています。クラスタに対する検出結果の数がこの上限を超えると、セキュリティ対策ダッシュボードはそのクラスタに関する構成の検出結果の表示を停止します。

  この問題を解決するには、Logging のログを使用して構成の問題を特定し、更新されたマニフェストをデプロイします。構成の検出結果が 150,000 件未満の場合は、セキュリティ対策ダッシュボードにクラスタの検出結果が表示されます。

次のステップ

• セキュリティ対策ダッシュボードについて確認する。
• 構成の監査の仕組みについて確認する。
• Google の推奨事項に基づいてクラスタを保護する方法を確認する。