すべてのプロダクト
Search

このプロダクト

    Container Service for Kubernetes:クラスターワークロードの検査

    ドキュメントセンター

    Container Service for Kubernetes:クラスターワークロードの検査

    最終更新日:Jun 22, 2026

    Container Service for Kubernetes (ACK) は、クラスターのワークロード構成におけるセキュリティリスクをスキャンする検査機能を提供します。検査タスクの実行後、システムは検査レポートを生成します。このレポートを使用して、リスク項目を確認および対処し、ワークロードのヘルスステータスをリアルタイムで監視できます。

    前提条件

    • クラスターで Kubernetes v1.14 以降が実行されていること。クラスターをアップグレードするには、「ACK クラスターの手動更新」をご参照ください。

    • RAM ユーザーの場合は、以降の説明に従って RAM 認可と RBAC 認可を完了してください。

      • RAM 認可

        Inspections ページで RAM 認可を完了し、現在の RAM ユーザーが現在のクラスターの Inspections ページを使用する権限があることを確認してください。そうでない場合、権限が不足するため、Inspections ページの機能を使用できなくなります。詳細については、「RAM を使用したクラスターおよびクラウドリソースへのアクセスの権限付与」をご参照ください。

        検査認可ポリシー

        {
  "Statement": [
    {
      "Action": [
        "cs:DescribePolarisConfig",
        "cs:DescribePolarisJob",
        "cs:DescribePolarisCronJob",
        "cs:UpdatePolarisJob",
        "cs:UpdatePolarisCronJob"
      ],
      "Effect": "Allow",
      "Resource": [
        "acs:cs:*:*:cluster/<yourclusterID>"
      ]
    }
  ],
  "Version": "1"
}

        検査レポート機能を使用する場合、RAM ユーザーに、クラスターのログ収集コンポーネントが使用する指定された Simple Log Service (SLS) プロジェクトに対する読み取り権限を付与する必要があります。そうでない場合、権限が不足するため、検査レポートを表示できなくなります。詳細については、「カスタム RAM 認可の例」をご参照ください。

        SLS ログ認可ポリシー

        {
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "log:Get*",
                "log:List*"
            ],
            "Resource": "acs:log:*:*:project/<your_project_name>/*",
            "Effect": "Allow"
        }
    ]
}

      • RBAC 認可

        Inspections ページのリソースに対して RBAC 認可を完了し、指定されたクラスターの管理者権限を RAM ユーザーに付与してください。これにより、RAM ユーザーが Inspections ページで Kubernetes リソースを操作する権限を確実に持つようになります。詳細については、「RBAC を使用したクラスター内のリソースに対する操作の認可」をご参照ください。

    検査の実行

    1. ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。

    2. [クラスター] ページで、管理するクラスターの名前をクリックします。 左側のペインで、[セキュリティ] > [検査] を選択します。

    3. 任意：画面の指示に従って、検査コンポーネントをインストールまたは更新します。

      security-inspector コンポーネントは無料ですが、Pod リソースを消費します。コンポーネントとそのリリースノートの詳細については、「security-inspector」をご参照ください。

    4. 検査を実行します。

      重要

      • オフピーク時に検査を実行することを推奨します。

      • デフォルトでは、検査はサポートされているすべての項目をスキャンします。Inspections ページの右上隅にある 定期検査の設定 をクリックして、スキャンする項目を指定できます。詳細については、「検査項目」をご参照ください。

      • 即時検査を実行するには、Inspections ページの右上隅にある Inspect をクリックします。

      • 定期検査を実行するには、Inspections ページの右上隅にある 定期検査の設定 をクリックします。次に、定期検査の設定 を選択し、検査期間を設定します。

    5. 検査が完了したら、検査 タブで目的の検査結果を見つけ、操作 列の 詳細 をクリックします。

    検査の詳細

    検査 ページには、さまざまなワークロードの詳細な検査結果が一覧表示されます。このページでは、次の機能を利用できます。

    • 合否、名前空間、ワークロードタイプ などの条件で結果をフィルタリングし、各ワークロードの [合格した項目の数] と [リスク項目] の数を表示します。

    • 各検査項目の詳細 (Pod およびコンテナレベルでのチェックステータス (合格または不合格)、詳細な説明、修正の提案など) を表示します。不合格になった項目が修正が不要な場合は、ホワイトリストに追加できます。

    • ワークロードの YAML ファイルを表示します。

    検査レポート

    レポート ページには、最新の検査結果が表示されます。このページには、次の情報が含まれます。

    • スキャン結果の概要 (検査項目の総数、検査された各リソースタイプの数と割合、総合的なヘルススコアなど)。

    • 主要なスキャンカテゴリ (ヘルスチェック、イメージ、ネットワーキング、リソース、セキュリティなど) の統計。

    • 各ワークロード設定の詳細なスキャン結果 (リソースタイプ、リソース名、名前空間、チェックタイプ、検査項目、結果など)。

    検査項目

    設定検査機能は、次の項目をスキャンして結果を表示します。

    チェック ID

    チェック項目

    説明とセキュリティリスク

    修正

    hostNetworkSet

    コンテナがホストネットワーク名前空間を共有することを防止

    ワークロードの Pod の spec に hostNetwork: true が設定されているかどうかを確認します。この設定が有効になっている場合、コンテナはホストのネットワーク名前空間にアクセスできるため、Pod 内からのネットワーク攻撃やデータスニッフィングのリスクが生じます。

    Pod spec を変更して hostNetwork フィールドを削除します。

    例：

          labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

    hostIPCSet

    コンテナがホスト IPC 名前空間を共有することを防止

    ワークロードの Pod spec に hostIPC: true が設定されているかを確認します。この設定が有効になっていると、コンテナがホストの IPC 名前空間にアクセスできるようになり、ホスト上の他のプロセスへの攻撃やデータのスニッフィングが可能になります。

    Pod の spec を変更して、hostIPC フィールドを削除します。

    例：

          labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

    hostPIDSet

    コンテナがホスト PID 名前空間を共有することを防止

    ワークロードの Pod spec に hostPID: true が設定されているかどうかを確認します。この設定が有効な場合、コンテナはホストのプロセス ID (PID) 名前空間にアクセスできるようになり、ホスト上の他のプロセスを攻撃したり、データを収集したりすることが可能になります。

    Pod の spec を修正して、hostPID フィールドを削除します。

    例：

          labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

    hostPortSet

    コンテナプロセスがノードポートをリッスンすることを防止

    ワークロードの Pod spec でhostPortが設定されているかどうかを確認します。コンテナポートがホストノードのポートにマッピングされている場合、ホストポートを占有し、意図しない送信元からのリクエストを受信するおそれがあります。

    Pod spec を変更して、hostPort フィールドを削除します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

    runAsRootAllowed

    コンテナが root ユーザーとして実行されることを防止

    ワークロードの Pod spec に runAsNonRoot: true が設定されているかどうかを確認します。この設定がされていない場合、コンテナはデフォルトで root ユーザーとして実行されます。これにより、悪意のあるプロセスがアプリケーション、ホスト、またはクラスター全体を侵害するリスクが生じます。

    Pod の spec を変更して runAsNonRoot: true を追加します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          runAsNonRoot: true

    runAsPrivileged

    コンテナが特権モードで実行されることを防止

    ワークロードの Pod spec に privileged: true が設定されているかどうかを確認します。この設定が有効になっている場合、コンテナはホストへの root アクセスが可能になります。これにより、悪意のあるプロセスがお客様のアプリケーション、ホスト、またはクラスター全体を侵害する深刻なリスクが生じます。

    Pod の spec を変更して、privileged フィールドを削除します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext: {}

    privilegeEscalationAllowed

    コンテナ内での権限昇格を防止

    ワークロードの Pod spec に allowPrivilegeEscalation: false が設定されているかどうかをチェックします。この設定がされていない場合、コンテナ内の子プロセスが親プロセスよりも多くの権限を取得できるため、権限昇格攻撃のリスクが生じます。

    Pod の spec を変更して、allowPrivilegeEscalation: false フィールドを追加します。

    例：

            ports:
        - containerPort: 80
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
        volumeMounts:

    capabilitiesAdded

    不要な Linux ケーパビリティの削除

    ワークロードの Pod の spec にある capabilities フィールドをチェックし、SYS_ADMIN、NET_ADMIN、または ALL などの特権レベルの高い Linux ケーパビリティが許可されているかを確認します。これらのケーパビリティが付与されている場合、悪意のあるプロセスがそれらを使用してアプリケーション、コンポーネント、またはクラスターを侵害するおそれがあります。

    Pod スペックを修正して、必要な Linux ケーパビリティのみを追加し、その他はすべて削除します。

    追加の Linux ケーパビリティが不要な場合は、すべて削除します。例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          capabilities:
            drop:
            - ALL

    特定のケーパビリティが必要な場合は、必要なものだけを追加し、その他はすべて削除します。例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          capabilities:
            add:
            - CHOWN
            drop:
            - ALL

    notReadOnlyRootFilesystem

    コンテナに読み取り専用ルートファイルシステムを使用

    ワークロードの pod spec に readOnlyRootFilesystem: true が設定されているかどうかを確認します。この設定がされていない場合、コンテナのルートファイルシステムは書き込み可能になります。これにより、悪意のあるプロセスがシステムファイルを変更するリスクが生じます。

    pod spec を変更して readOnlyRootFilesystem: true を追加します。特定のディレクトリに書き込む必要がある場合は、volumeMounts を使用します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          readOnlyRootFilesystem: true

    特定のディレクトリ内のファイルを変更するには、volumeMounts フィールドを使用します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
        volumeMounts:
        - mountPath: /path/to/write
          name: writeable
      volumes:
      - emptyDir: {}
        name: writeable

    cpuRequestsMissing

    コンテナの CPU リクエストを設定

    ワークロードの Pod スペックに resources.requests.cpu が設定されているかどうかを確認します。この設定が構成されていない場合、CPU リソースが不十分なノードに Pod がスケジューリングされ、パフォーマンスが低下する可能性があります。

    Pod spec を変更して、resources.requests.cpu フィールドを追加します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m

    cpuLimitsMissing

    コンテナの CPU 制限を設定

    ワークロードの Pod spec に resources.limits.cpu が設定されているかどうかを確認します。この設定がされていない場合、コンテナ内の異常なプロセスが過剰なノードリソースを消費し、ノードまたはクラスター全体の CPU リソースを枯渇させる可能性があります。

    Pod の spec を変更して、resources.limits.cpu フィールドを追加します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m
          limits:
            cpu: 100m

    memoryRequestsMissing

    コンテナのメモリリクエストを設定

    ワークロードの Pod の spec に resources.requests.memory が設定されているかどうかをチェックします。この設定がされていない場合、Pod がメモリ不足のノードにスケジュールされ、メモリ不足 (OOM) エラーが発生する可能性があります。

    Pod の spec を変更して、resources.requests.memory フィールドを追加します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m
            memory: 128Mi

    memoryLimitsMissing

    コンテナのメモリ制限を設定

    ワークロードの pod spec に resources.limits.memory が設定されているかどうかを確認します。この設定がされていない場合、コンテナ内の異常なプロセスが過剰なノードリソースを消費し、ノードまたはクラスター全体のメモリを使い果たす可能性があります。

    Pod の spec を変更して、resources.limits.memory フィールドを追加します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 100m
            memory: 128Mi

    readinessProbeMissing

    コンテナの readiness プローブを設定

    ワークロードの Pod spec に readinessProbe が設定されているかどうかをチェックします。readiness プローブがないと、コンテナがリクエストを処理する準備が整う前にトラフィックが送信され、アプリケーションエラーの原因となる可能性があります。

    Pod の spec を変更して、readinessProbe フィールドを追加します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 20

    livenessProbeMissing

    コンテナの liveness プローブを設定

    ワークロードの Pod の spec に livenessProbe が設定されているかチェックします。liveness プローブがない場合、応答しないコンテナは自動的に再起動されず、アプリケーションのダウンタイムにつながる可能性があります。

    Pod の spec を変更して、livenessProbe フィールドを追加します。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 20

    tagNotSpecified

    コンテナに特定のイメージタグを使用

    ワークロードの pod spec の image フィールドにイメージタグが欠落しているか、または latest タグが使用されているかどうかをチェックします。特定のイメージタグが使用されていない場合、ワークロードで予期しないバージョンのコンテナイメージが実行され、アプリケーションエラーを引き起こす可能性があります。

    Pod spec の image フィールドを、特定のイメージタグに変更してください。latest タグは使用しないでください。

    例：

        spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

    anonymousUserRBACBinding

    匿名ユーザーによるクラスターへのアクセスを禁止

    クラスター内のロールベースアクセス制御 (RBAC) バインディングをチェックし、匿名ユーザーにアクセスを許可する設定があるかどうかを確認します。匿名アクセスが許可されている場合、悪意のあるユーザーが機密情報を盗んだり、クラスターを攻撃したりする可能性があります。

    RBAC バインディングを修正して、匿名ユーザーがクラスターリソースにアクセスできる権限を削除します。

    例：

      - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: 'foo-group'

    イベント

    イベントタイプ

    イベント名

    内容の例

    説明

    操作

    Normal

    SecurityInspectorConfigAuditStart

    Starting config audit

    検査タスクが開始されます。

    操作は不要です。

    Normal

    SecurityInspectorConfigAuditFinished

    Config audit finished

    検査タスクが完了しました。

    操作は不要です。

    Warning

    SecurityInspectorConfigAuditHighRiskFound

    Found 2 high-risk items after config audit

    検査後、一部のワークロードで未対応の高リスク項目が検出されました。

    1. クラスターの Inspections ページで、検査 タブに移動し、詳細な検査結果を表示します。

    2. 合否、名前空間、ワークロードタイプ で結果をフィルタリングして、リスクのあるワークロードを特定します。

    3. ワークロードの 詳細 をクリックして、各検査項目の結果を表示します。

      • 修正が不要であると確認した項目は、ホワイトリストに追加 をクリックします。

      • 修正が必要な項目は、詳細 をクリックし、修正の提案に従って項目を修正します。