検査機能を使用して、ACKクラスターのワークロードのセキュリティリスクを検出する - Container Service for Kubernetes

Container Service for Kubernetes (ACK) は、ACKクラスターのワークロードのセキュリティリスクを検出するのに役立つ検査機能を提供します。 ACKクラスターが検査タスクを完了すると、クラスターは検査レポートを生成します。検査レポートで失敗した検査項目を表示および対処できます。これにより、クラスターのヘルスステータスをリアルタイムで把握できます。

前提条件

Kubernetes 1.14以降を実行するクラスターが作成されます。クラスターの更新方法の詳細については、「ACKクラスターの手動更新」をご参照ください。
Resource Access Management (RAM) ユーザーを使用する場合は、次の手順に従ってRAM権限付与とロールベースのアクセス制御 (RBAC) 権限付与を完了する必要があります。
- 完全なRAM権限付与
  RAMユーザーを使用する場合、ACKコンソールの [検査] ページにメッセージが表示され、RAMユーザーに [検査] ページで操作を実行する権限を付与するよう求められます。 RAMユーザーに必要な権限がない場合、[検査] ページで操作を実行できません。詳細については、「カスタムRAMポリシーの作成」をご参照ください。
  [検査] ページで操作を実行する権限を付与するためのサンプルコードを表示する
```
{
  "Statement": [
    {
      "Action": [
        "cs:DescribePolarisConfig",
        "cs:DescribePolarisJob",
        "cs:DescribePolarisCronJob",
        "cs:UpdatePolarisJob",
        "cs:UpdatePolarisCronJob"
      ],
      "Effect": "Allow",
      "Resource": [
        "acs:cs:*:*:cluster/<yourclusterID>"
      ]
    }
  ],
  "Version": "1"
}
```
  検査レポート機能も使用する必要がある場合は、クラスター内のlogtail-dsコンポーネントで使用されるSimple Log Serviceプロジェクトの読み取り権限をRAMユーザーに付与する必要があります。これにより、RAMユーザーはSimple log Serviceプロジェクトのログデータを読み取ることができます。それ以外の場合は、検査レポートを表示できません。詳細については、「カスタムポリシーを使用してRAMユーザーに権限を付与する」をご参照ください。
  Simple Log Serviceプロジェクトで読み取り権限を付与するためのサンプルコードを表示する
```
{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "log:Get*",
                "log:List*"
            ],
            "Resource": "acs:log:*:*:project/<Project name>/*",
            "Effect": "Allow"
        }
    ]
}
```
- 完全なRBAC認証
  RAM権限付与が完了したら、RAMユーザーにRBAC権限を付与して、ACKコンソールの [検査] ページに表示されるKubernetesリソースを管理する必要があります。クラスターを管理するには、RAMユーザーに管理者権限を付与する必要があります。これにより、RAMユーザーは [検査] ページに表示されるKubernetesリソースを管理できます。詳細については、「RAMユーザーまたはRAMロールへのRBAC権限の付与」をご参照ください。

検査タスクの実行

ACKコンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。左側のペインで、[セキュリティ] > [検査] を選択します。
オプション: security-inspectorコンポーネントをインストールおよび更新します。
セキュリティインスペクタコンポーネントは無料ですが、ポッドリソースを占有します。 security-inspectorコンポーネントの概要とリリースノートの詳細については、「security-inspector」をご参照ください。
検査タスクを実行します。
重要
- オフピーク時に検査タスクを実行することを推奨します。
- デフォルトでは、検査タスクに対してすべての検査項目が有効になっています。 [検査] ページの右上隅にある [定期検査の設定] をクリックします。表示されるパネルで、検査タスクの検査項目を設定できます。詳細については、「検査項目」をご参照ください。
- すぐに検査タスクを実行する: [検査] ページの右上隅にある [検査] をクリックします。
- 定期的に検査タスクを実行する: [検査] ページの右上隅にある [定期検査の設定] をクリックします。次に、[定期検査の設定] を選択し、検査サイクルを設定します。
検査タスクが完了したら、[検査] タブに移動して検査結果を見つけ、[操作] 列の [詳細] をクリックします。

検査の詳細

[検査] ページには、さまざまなワークロードの検査結果を表示するテーブルがあります。検査結果を表示するには、次の機能があります。

合格または失敗、名前空間、ワークロードタイプなどの条件に基づいて検査結果をフィルタリングします。検査された各ワークロードの合格項目数および失敗項目数の値を表示します。
検査詳細ページには、各ポッドおよびコンテナの検査項目の合格および不合格、各検査項目の説明、セキュリティ強化に関する提案など、各検査項目の詳細情報が表示されます。失敗した検査項目を無視するには、ホワイトリストに追加します。
ワークロードのYAMLファイルを表示します。

検査レポート

[レポート] ページには、次の情報など、最新の検査タスクの結果が表示されます。

検査結果の概要。これには、検査項目の総数、検査された各リソースオブジェクトタイプの数と割合、およびクラスターの全体的なヘルスステータスが含まれます。
次の検査カテゴリの統計: ヘルスチェック、画像、ネットワーク、リソース、およびセキュリティ条件。
各ワークロードの構成の詳細な検査結果。結果には、リソースカテゴリ、リソース名、名前空間、検査タイプ、検査項目、および検査結果が含まれます。

検査アイテム

次の表に、検査項目を示します。

検査アイテムID	検査アイテム	検査内容と潜在的なセキュリティリスク	提案
hostNetworkSet	コンテナーとホスト間のネットワーク名前空間の共有を無効にする	ワークロードのポッド仕様に`hostNetwork: true`設定が含まれているかどうかを確認します。この設定では、ポッドがホストのネットワーク名前空間を使用することを指定します。 hostNetwork:true設定が指定されている場合、ホストネットワークはポッド内のコンテナによって攻撃される可能性があり、ホストネットワーク内のデータ転送が盗聴される可能性があります。	ポッド仕様から`hostNetwork`フィールドを削除します。例:
hostIPCSet	コンテナーとホスト間のIPC名前空間の共有を無効にする	ワークロードのポッド仕様に`hostIPC: true`設定が含まれているかどうかを確認します。この設定では、ポッドがホストのプロセス間通信 (IPC) 名前空間を使用することを指定します。 hostIPC:true設定が指定されている場合、ポッド内のコンテナーがホストプロセスを攻撃し、プロセスデータを検出する可能性があります。	ポッド仕様から`hostIPC`フィールドを削除します。例:
hostPIDSet	コンテナーとホスト間のPID名前空間の共有を無効にする	ワークロードのポッド仕様に`hostPID: true`設定が含まれているかどうかを確認します。この設定では、ポッドがホストのプロセスID (PID) 名前空間を使用することを指定します。 hostPID: true設定が指定されている場合、ポッド内のコンテナーがホストプロセスを攻撃し、プロセスデータを収集する可能性があります。	ポッド仕様から`hostPID`フィールドを削除します。例:
hostPortSet	コンテナ内のプロセスがホストポートでリッスンするのを防ぐ	ワークロードのポッド仕様に`hostPort`フィールドが含まれているかどうかを確認します。このフィールドは、ポッドのリスニングポートがマップされるホストポートを指定します。 hostPortフィールドが指定されている場合、指定されたホストポートが許可なく占有され、コンテナポートが予期しない要求を受け取る可能性があります。	ポッド仕様から`hostPort`フィールドを削除します。例:
runAsRootAllowed	rootユーザーとしてのコンテナー起動の無効化	ワークロードのポッド仕様に`runAsNonRoot: true`設定が含まれているかどうかを確認します。この設定では、ポッド内のコンテナーをrootユーザーとして実行できないように指定します。 runAsNonRoot: true設定が指定されていない場合、コンテナー内の悪意のあるプロセスがアプリケーション、ホスト、またはクラスターに侵入する可能性があります。	ポッド仕様に`runAsNonRoot: true`設定を追加します。例:
runAsPrivileged	特権モードでのコンテナー起動の無効化	ワークロードのポッド仕様に`privileged: true`設定が含まれているかどうかを確認します。この設定では、ポッド内のコンテナーを特権モードで実行できるように指定します。 privileged: true設定が指定されている場合、コンテナー内の悪意のあるプロセスがアプリケーション、ホスト、またはクラスターに侵入する可能性があります。	ポッド仕様から`特権`フィールドを削除します。例:
privilegeEscalationAllowed	コンテナ内の子プロセスの特権エスカレーションを無効にする	ワークロードのポッド仕様に`allowPrivilegeEscalation: false`設定が含まれているかどうかを確認します。この設定では、コンテナの子プロセスに親プロセスよりも高い特権を付与できないことを指定します。 allowPrivilegeEscalation:false設定が指定されていない場合、コンテナ内の悪意のあるプロセスにエスカレートされた権限が付与され、不正な操作が実行される可能性があります。	ポッド仕様に`allowPrivilegeEscalation: false`設定を追加します。例:
capabilitiesAdded	不要なLinux機能を無効にする	ワークロードのポッド仕様に`capabilities`フィールドが含まれているかどうかを確認します。このフィールドは、コンテナ内のプロセスに対してLinux機能を有効にするために使用されます。機能には、SYS_ADMIN、NET_ADMIN、およびALLが含まれます。ケーパビリティフィールドが指定されている場合、コンテナ内の悪意のあるプロセスがアプリケーション、クラスターコンポーネント、またはクラスターに侵入する可能性があります。	必要なLinux機能のみを保持し、他の機能を削除するようにポッド仕様を変更します。コンテナ内のプロセスがLinux機能を必要としない場合は、すべてのLinux機能を削除します。例：コンテナ内のプロセスがLinux機能を必要とする場合は、必要なLinux機能のみを指定し、他の機能を削除します。例:
notReadOnlyRootFileSystem	コンテナ内のファイルシステムの読み取り専用モードを有効にする	ワークロードのポッド仕様に`readOnlyRootFlesystem: true`設定が含まれているかどうかを確認します。この設定では、コンテナーにマウントされたルートファイルシステムが読み取り専用であることを指定します。 readOnlyRootFlesystem: true設定が指定されていない場合、コンテナ内の悪意のあるプロセスがルートファイルシステムを変更する可能性があります。	ポッド仕様に`readOnlyRootFlesystem: true`設定を追加します。特定のディレクトリ内のファイルを変更する場合は、ポッド仕様でvolumeMountsフィールドを設定します。例：特定のディレクトリ内のファイルを変更する場合は、ポッド仕様で`volumeMounts`フィールドを設定します。例:
cpuRequestsMissing	コンテナーの実行に使用できるCPUリソースの最小使用率を設定する	ワークロードのポッド仕様に`resources.requests.cpu`フィールドが含まれているかどうかを確認します。このフィールドは、各コンテナーの実行に必要な最小CPUリソースを指定します。 resources.requests.cpuフィールドが指定されていない場合、CPUリソースが不足しているノードにポッドがスケジュールされる可能性があります。これは、遅いプロセスにつながり得る。	`resources.requests.cpu`フィールドをポッド仕様に追加します。例：
cpuLimitsMissing	コンテナーの実行に使用できるCPUリソースの最大量を設定する	ワークロードのポッド仕様に`resources.limits.cpu`フィールドが含まれているかどうかを確認します。このフィールドは、各コンテナーで使用できる最大CPUリソースを指定します。 resources.limits.cpuフィールドが指定されていない場合、コンテナー内の異常なプロセスが過剰なCPUリソースを消費したり、ノードまたはクラスターのCPUリソースを使い果たしたりする可能性があります。	`resources.limits.cpu`フィールドをポッド仕様に追加します。例：
memoryRequestsMissing	コンテナーの実行に使用できる最小メモリリソースを設定する	ワークロードのポッド仕様に`resources.requests.memory`フィールドが含まれているかどうかを確認します。このフィールドは、各コンテナーの実行に必要な最小メモリリソースを指定します。 resources.requests.memoryフィールドが指定されていない場合、ポッドはメモリリソースが不足しているノードにスケジュールされる可能性があります。その結果、メモリ不足 (OOM) キラーがトリガされると、コンテナ内のプロセスが終了することがある。	`resources.requests.memory`フィールドをポッド仕様に追加します。例：
memoryLimitsMissing	コンテナーの実行に使用できる最大メモリリソースの設定	ワークロードのポッド仕様に`resources.limits.memory`フィールドが含まれているかどうかを確認します。このフィールドは、各コンテナが使用できる最大メモリリソースを指定します。 resources.limits.memoryフィールドが指定されていない場合、コンテナ内の異常なプロセスが過剰な量のメモリリソースを消費したり、ノードまたはクラスタのメモリリソースを使い果たしたりする可能性があります。	ポッド仕様に`resources.limits.memory`フィールドを追加します。例：
readinessProbeMissing	コンテナー準備プローブの設定	ワークロードのポッド仕様に`readinessProbe`フィールドが含まれているかどうかを確認します。このフィールドは、コンテナに対して準備プローブを設定するかどうかを指定します。コンテナ内のアプリケーションがリクエストを処理する準備ができているかどうかを確認するために準備プローブが使用されます。 readinessProbeフィールドが指定されていない場合、要求を処理する準備ができていないアプリケーションに要求が送信されたときにサービス例外が発生する可能性があります。	`readinessProbe`フィールドをポッド仕様に追加します。例：
livenessProbeMissing	コンテナーlivenessプローブの設定	ワークロードのポッド仕様に`livenessProbe`フィールドが含まれているかどうかを確認します。このフィールドは、livenessプローブをコンテナーに設定するかどうかを指定します。 Livenessプローブを使用して、アプリケーションの例外を解決するためにコンテナーの再起動が必要かどうかを確認します。 livenessProbeフィールドが指定されていない場合、アプリケーションの例外がコンテナーの再起動によってのみ解決できる場合、サービスが中断される可能性があります。	`livenessProbe`フィールドをポッド仕様に追加します。例：
tagNotSpecified	コンテナーのイメージバージョンの指定	ワークロードのポッド仕様の`image`フィールドがイメージバージョンを指定しているかどうか、またはフィールドの値が最新に設定されているかどうかを確認します。イメージバージョンが指定されていない場合、またはフィールドの値が最新に設定されている場合、コンテナーが間違ったイメージバージョンを使用すると、サービスが中断される可能性があります。	イメージのバージョンを指定して、ポッド仕様の`image`フィールドを変更します。フィールドを最新以外の値に設定します。例：
anonymousUserRBACBinding	クラスターへの匿名アクセスの禁止	クラスター内のRBACロールバインディングをチェックし、匿名ユーザーからのアクセスを許可する設定を特定します。匿名ユーザーがクラスターへのアクセスを許可されている場合、機密情報にアクセスし、クラスターを攻撃し、クラスターに侵入する可能性があります。	RBACロールバインディングから匿名ユーザーからのアクセスを許可する設定を削除します。例：

イベント

イベントタイプ	イベント名	イベント内容の例	イベントの説明	API 操作
正常	SecurityInspectorConfigAuditStart	構成監査の実行を開始する	システムがクラスターの検査を開始します。	この場合、アクションは必要ありません。
正常	SecurityInspectorConfigAuditFinished	設定監査の実行完了	システムは、クラスタの検査を終了する。	この場合、アクションは必要ありません。
警告	SecurityInspectorConfigAuditHighRiskFound	構成監査を実行した後、2つの高いリスクが見つかりました	検査機能は、ワークロードのセキュリティリスクを識別します。	検査の詳細を表示するには、[検査] ページの [検査] タブに移動します。 [合格または失敗] 、[名前空間] 、および [ワークロードの種類] ドロップダウンリストからフィルターオプションを選択して、セキュリティリスクのあるワークロードを特定します。 [詳細] をクリックして、ワークロードの各検査項目の結果を表示します。リスクを無視する場合は、[ホワイトリストに追加] をクリックして、対応する検査項目をホワイトリストに追加します。リスクを軽減する場合は、[詳細] をクリックして、リスクを軽減する方法に関する提案を表示します。