設定検査を使用してクラスターのワークロードのセキュリティ設定をチェックする - Container Service for Kubernetes

ACK は、クラスター内のワークロードの設定におけるセキュリティリスクをスキャンするのに役立つ検査機能を提供します。検査タスクが実行されると、システムは検査レポートを生成します。レポートに基づいてリスク項目を表示および処理し、クラスター内のワークロードのリアルタイムのヘルスステータスをモニターできます。

前提条件

クラスターのバージョンが v1.14 以降であること。クラスターをアップグレードするには、詳細については、「クラスターを手動でアップグレードする」をご参照ください。
RAM ユーザーを使用する場合は、次のセクションで説明するように、RAM 権限付与と RBAC 権限付与を完了していることを確認してください。
- RAM 権限付与
  [設定検査] ページで RAM 権限付与を完了して、現在の RAM ユーザーに現在のクラスターの [設定検査] ページで操作を実行する権限を付与します。そうしないと、RAM ユーザーは [設定検査] ページで操作を実行できません。詳細については、「RAM を使用してクラスターとクラウドリソースへのアクセス権限を付与する」をご参照ください。
  設定検査の認証コードを展開して表示
```
{
  "Statement": [
    {
      "Action": [
        "cs:DescribePolarisConfig",
        "cs:DescribePolarisJob",
        "cs:DescribePolarisCronJob",
        "cs:UpdatePolarisJob",
        "cs:UpdatePolarisCronJob"
      ],
      "Effect": "Allow",
      "Resource": [
        "acs:cs:*:*:cluster/<yourclusterID>"
      ]
    }
  ],
  "Version": "1"
}
```
  検査レポート機能を使用するには、現在のクラスターのログ収集コンポーネントが使用する指定された Simple Log Service プロジェクトに対する読み取り権限を RAM ユーザーに付与する必要があります。これにより、RAM ユーザーはプロジェクト内のデータを読み取ることができます。そうしないと、権限が不十分なため検査レポートを表示できません。詳細については、「カスタム RAM ポリシーの例」をご参照ください。
  Simple Log Service からログを読み取るための認証コードを展開して表示
```
{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "log:Get*",
                "log:List*"
            ],
            "Resource": "acs:log:*:*:project/<Specified project name>/*",
            "Effect": "Allow"
        }
    ]
}
```
- RBAC 権限付与
  [設定検査] ページでリソースの RBAC 権限付与を完了します。指定されたクラスターの管理者権限を RAM ユーザーに付与して、ユーザーが [設定検査] ページで Kubernetes リソースを管理できるようにします。詳細については、「RBAC を使用してクラスター内のリソースを管理する権限を付与する」をご参照ください。

検査の実行

ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、[セキュリティ] > [検査] を選択します。
オプション: プロンプトに従って検査コンポーネントをインストールおよび更新します。
security-inspector コンポーネントは無料ですが、Pod リソースを消費します。コンポーネントとその変更履歴の詳細については、「security-inspector」をご参照ください。
検査を実行します。
重要
- オフピーク時に検査操作を実行することをお勧めします。
- デフォルトでは、サポートされているすべての項目が検査されます。[設定検査] ページの右上隅にある [検査設定] をクリックして、検査する項目を設定できます。詳細については、「検査項目」をご参照ください。
- すぐに検査を実行するには、[設定検査] ページの右上隅にある [今すぐ検査] をクリックします。
- 定期的に検査を実行するには、[設定検査] ページの右上隅にある [検査設定] をクリックします。次に、[定期検査] を選択し、検査サイクルを設定します。
検査が完了したら、[検査詳細] タブで目的の検査を見つけ、[アクション] 列の [詳細] をクリックします。

検査の詳細

[検査詳細] ページでは、さまざまなワークロードの詳細な検査結果が表形式で表示されます。このページでは、次の機能が提供されます:

[リスクあり]、[名前空間]、[ワークロードタイプ] などの基準でワークロードをフィルターして、[合格項目] と [リスク項目] の数を表示できます。
このページには、Pod およびコンテナーレベルでのチェックステータス (合格または失敗)、検査項目の詳細な説明、修正提案など、各検査項目の詳細情報が表示されます。失敗した検査項目を処理する必要がない場合は、ホワイトリストに追加できます。
ワークロードの YAML ファイルを表示できます。

検査レポート

[検査レポート] ページには、最新の検査スキャン結果が表示されます。このページには、次の情報が含まれています:

スキャン結果の概要 (検査エントリの総数、検査された各リソース項目の数と割合、全体的なヘルススコアなど)。
主要なスキャン結果カテゴリの統計 (ヘルスチェック、イメージ、ネットワーク、リソース、セキュリティの結果など)。
各ワークロード設定の詳細なスキャン結果 (リソースカテゴリ、リソース名、名前空間、チェックタイプ、検査項目、チェック結果など)。

検査項目

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

検査項目 ID	検査項目	検査内容と潜在的なセキュリティリスク	修正提案
hostNetworkSet	コンテナーとホスト間のネットワーク名前空間の共有を無効にする	ワークロードの Pod spec に `hostNetwork: true` 設定が含まれているかどうかをチェックします。この設定により、Pod はホストのネットワーク名前空間を使用できます。この設定が指定されている場合、Pod 内のコンテナーがホストネットワークを攻撃し、ホストネットワーク上のデータ転送をスニッフィングする可能性があります。	Pod spec を変更して `hostNetwork` フィールドを削除します。例:
hostIPCSet	コンテナーとホスト間の IPC 名前空間の共有を無効にする	ワークロードの Pod spec に `hostIPC: true` 設定が含まれているかどうかをチェックします。この設定により、Pod はホストのプロセス間通信 (IPC) 名前空間を使用できます。この設定が指定されている場合、Pod 内のコンテナーがホストプロセスを攻撃し、プロセスデータをスニッフィングする可能性があります。	Pod spec を変更して `hostIPC` フィールドを削除します。例:
hostPIDSet	コンテナーとホスト間の PID 名前空間の共有を無効にする	ワークロードの Pod spec に `hostPID: true` 設定が含まれているかどうかをチェックします。この設定により、Pod はホストのプロセス ID (PID) 名前空間を使用できます。この設定が指定されている場合、Pod 内のコンテナーがホストプロセスを攻撃し、プロセスデータを収集する可能性があります。	Pod spec を変更して `hostPID` フィールドを削除します。例:
hostPortSet	コンテナー内のプロセスがホストポートでリッスンするのを防ぐ	ワークロードの Pod spec に hostPort フィールドが含まれているかどうかをチェックします。このフィールドは、Pod のリッスンポートをホストポートにマッピングします。`hostPort` フィールドが指定されている場合、ホストポートが権限なく占有され、コンテナーポートが予期しないリクエストを受信する可能性があります。	Pod spec を変更して `hostPort` フィールドを削除します。例:
runAsRootAllowed	root ユーザーとしてのコンテナーの起動を無効にする	ワークロードの Pod spec に `runAsNonRoot: true` 設定がないかどうかをチェックします。この設定は、Pod 内のコンテナーが root ユーザーとして実行されるのを防ぎます。この設定が指定されていない場合、コンテナー内の悪意のあるプロセスがアプリケーション、ホスト、さらにはクラスター全体を危険にさらす可能性があります。	Pod spec を変更して `runAsNonRoot: true` を追加します。例:
runAsPrivileged	特権モードでのコンテナーの起動を無効にする	ワークロードの Pod spec に `privileged: true` 設定が含まれているかどうかをチェックします。この設定により、Pod 内のコンテナーが特権モードで実行できます。この設定が指定されている場合、コンテナー内の悪意のあるプロセスがアプリケーション、ホスト、さらにはクラスターを危険にさらす可能性があります。	Pod spec を変更して `privileged` フィールドを削除します。例:
privilegeEscalationAllowed	コンテナー内の子プロセスの権限昇格を無効にする	ワークロードの Pod spec に `allowPrivilegeEscalation: false` 設定がないかどうかをチェックします。この設定は、コンテナーの子プロセスが親プロセスよりも高い権限を取得するのを防ぎます。この設定が指定されていない場合、コンテナー内の悪意のあるプロセスが昇格された権限を取得し、不正な操作を実行する可能性があります。	Pod spec を変更して `allowPrivilegeEscalation: false` フィールドを追加します。例:
capabilitiesAdded	不要な Linux Capabilities を無効にする	ワークロードの Pod spec の `capabilities` フィールドをチェックして、コンテナー内のプロセスに SYS_ADMIN、NET_ADMIN、ALL などの特権的な Linux Capabilities が付与されているかどうかを判断します。これらの capabilities が付与されている場合、コンテナー内の悪意のあるプロセスがこれらの権限を使用してアプリケーションを危険にさらしたり、コンポーネントやクラスターを損傷したりする可能性があります。	Pod spec を変更して、必要な Linux capabilities のみを追加し、不要なものは削除します。追加の Linux capabilities が不要な場合は、すべて削除します。例: 必要な Linux capabilities のみを追加し、不要なものはすべて削除します。例:
notReadOnlyRootFileSystem	コンテナー内のファイルシステムの読み取り専用モードを有効にする	ワークロードの Pod spec に `readOnlyRootFilesystem: true` 設定がないかどうかをチェックします。この設定により、コンテナー内のルートファイルシステムが読み取り専用になります。この設定が指定されていない場合、コンテナー内の悪意のあるプロセスがシステムファイルを変更する可能性があります。	Pod spec を変更して readOnlyRootFilesystem: true を追加します。特定のディレクトリ内のファイルを変更するには、`volumeMounts` を使用できます。例: ディレクトリ内のファイルを変更するには、`volumeMounts` フィールドを使用します。例:
cpuRequestsMissing	コンテナー実行のための最小 CPU リソースを設定する	ワークロードの Pod spec に `resources.requests.cpu` フィールドがないかどうかをチェックします。このフィールドは、各コンテナーを実行するために必要な最小 CPU リソースを指定します。このフィールドが指定されていない場合、Pod が不十分な CPU リソースを持つノードにスケジュールされ、コンテナー内のプロセスの実行が遅くなる可能性があります。	Pod spec を変更して `resources.requests.cpu` フィールドを追加します。例:
cpuLimitsMissing	コンテナー実行のための最大 CPU リソースを設定する	ワークロードの Pod spec に `resources.limits.cpu` フィールドがないかどうかをチェックします。このフィールドは、各コンテナーが使用できる最大 CPU リソースを指定します。このフィールドが指定されていない場合、コンテナー内の異常なプロセスが大量のノードリソースを消費したり、ノード全体またはクラスターのリソースを使い果たしたりする可能性があります。	Pod spec を変更して `resources.limits.cpu` フィールドを追加します。例:
memoryRequestsMissing	コンテナー実行のための最小メモリリソースを設定する	ワークロードの Pod spec に `resources.requests.memory` フィールドがないかどうかをチェックします。このフィールドは、各コンテナーを実行するために必要な最小メモリリソースを指定します。このフィールドが指定されていない場合、Pod が不十分なメモリリソースを持つノードにスケジュールされる可能性があります。その結果、メモリ不足 (OOM) エラーによりコンテナー内のプロセスが終了する可能性があります。	Pod spec を変更して `resources.requests.memory` フィールドを追加します。例:
memoryLimitsMissing	コンテナー実行のための最大メモリリソースを設定する	ワークロードの Pod spec に `resources.limits.memory` フィールドがないかどうかをチェックします。このフィールドは、各コンテナーが使用できる最大メモリリソースを指定します。このフィールドが指定されていない場合、コンテナー内の異常なプロセスが大量のノードリソースを消費したり、ノード全体またはクラスターのリソースを使い果たしたりする可能性があります。	Pod spec を変更して `resources.limits.memory` フィールドを追加します。例:
readinessProbeMissing	コンテナーの readiness プローブを設定する	ワークロードの Pod spec に `readinessProbe` フィールドがないかどうかをチェックします。readiness プローブは、コンテナー内のアプリケーションがリクエストを処理する準備ができているかどうかをチェックします。このフィールドが指定されていない場合、アプリケーションが異常でリクエストを処理できない場合でも、リクエストがコンテナーに送信される可能性があります。これにより、サービス例外が発生する可能性があります。	Pod spec を変更して `readinessProbe` フィールドを追加します。例:
livenessProbeMissing	コンテナーの liveness プローブを設定する	ワークロードの Pod spec に `livenessProbe` フィールドがないかどうかをチェックします。liveness プローブは、アプリケーションの例外を解決するためにコンテナーを再起動する必要があるかどうかをチェックします。このフィールドが指定されていない場合、再起動によってのみ解決できるアプリケーション例外が発生したときに、コンテナーがタイムリーに再起動されない可能性があります。これにより、サービス例外が発生する可能性があります。	Pod spec を変更して `livenessProbe` フィールドを追加します。例:
tagNotSpecified	コンテナーのイメージタグを指定する	ワークロードの Pod spec の image フィールドに特定のイメージタグがないか、`latest` タグを使用しているかどうかをチェックします。特定のタグが使用されていない場合、予期しないコンテナイメージバージョンが実行され、サービス例外が発生する可能性があります。	Pod spec の image フィールドを変更して、`latest` タグの代わりに特定のイメージタグを使用します。例:
anonymousUserRBACBinding	クラスターへの匿名アクセスを禁止する	クラスター内の RBAC バインディングをチェックして、匿名ユーザーにアクセス権限を付与する設定項目を特定します。匿名ユーザーがクラスターリソースにアクセスできる場合、悪意のあるユーザーがクラスターに関する機密情報を盗んだり、クラスターを攻撃して侵害したりする可能性があります。	必要に応じて、スキャンされた RBAC バインディングを変更し、匿名ユーザーがクラスターリソースにアクセスできるようにする権限設定項目を削除します。例:

イベント

イベントタイプ	イベント名	イベント内容の例	イベントの説明	操作
法線	SecurityInspectorConfigAuditStart	Start to running config audit	システムが検査タスクの実行を開始します。	操作は不要です。
法線	SecurityInspectorConfigAuditFinished	Finished running once config audit	検査タスクが完了しました。	操作は不要です。
Warning	SecurityInspectorConfigAuditHighRiskFound	2 high risks have been found after running config audit	検査完了後、一部のワークロードに未処理の高リスク検査項目が見つかりました。	クラスターの [設定検査] ページの [検査詳細] タブで、詳細な検査結果を表示します。必要に応じて、[リスクあり]、[名前空間]、[ワークロードタイプ] でリスクのあるワークロードをフィルターします。 [詳細] をクリックして、ワークロード内の各検査項目のチェック結果を表示します。修正する必要がないことを確認した検査項目については、[ホワイトリストに追加] をクリックして、その検査項目をホワイトリストに追加します。修正する必要があることを確認した検査項目については、[詳細] をクリックし、強化提案に基づいて項目を修正します。