ビュー:

継続的なコンプライアンスのためのKubernetesネットワークポリシーを手動で作成するにはどうすればよいですか?

デフォルトでは、 Container Securityの継続的コンプライアンスによって、ユーザに代わってKubernetesネットワークポリシーが作成されます。ポリシーを手動で作成する場合は、次の手順を実行します。

手順

  1. の値を変更します。 cloudOne.oversight.enableNetworkPolicyCreationにfalse 。
     cloudOne: oversight: enableNetworkPolicyCreation: false
  2. を使用してネットワークポリシーを作成します。 matchLabelsに設定trendmicro-cloud-one: isolate必要な名前空間に配置します。
     apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: labels: app.kubernetes.io/instance: trendmicro name: trendmicro-oversight-isolate-policy spec: podSelector: matchLabels: trendmicro-cloud-one: isolate policyTypes: - Ingress - Egress
    重要
    重要
    matchLabelsを使用したネットワークポリシーtrendmicro-cloud-one: isolate隔離の軽減を適切に実行するには、各アプリケーションの名前空間に存在する必要があります。

Container Securityに関連するHelmチャート操作を実行するにはどうすればよいですか?

次の表をレファレンス/参照情報して、Helmコマンドを使用して実行できるタスクを確認してください。
タスク
説明
Container Securityデプロイメントをアップグレードする
初期設定のKubernetes名前空間にある既存のインストールを最新バージョンにアップグレードするには、次の手順を実行します。 
 helm upgrade \ --values overrides.yaml \ --namespace ${namespace} \ trendmicro \ https://github.com/trendmicro/cloudone-container-security-helm/archive/master.tar.gz
上記のスクリプトは、overrides.yamlファイルの値をオーバーライドまたはリセットします。以前の値を使用する場合は、 -reuse-values Helmのアップグレード時のパラメータ: 
 helm upgrade \ --namespace ${namespace} \ --reuse-values \ trendmicro \ https://github.com/trendmicro/cloudone-container-security-helm/archive/master.tar.gz
特定のコンポーネントの有効化または無効化
Container Security Helmチャートの特定のコンポーネントは、オーバーライドファイルを使用して個別に有効または無効にできます。たとえば、ランタイムセキュリティコンポーネントを有効にするように選択できます。 overrides.yamlファイル:
 cloudOne: runtimeSecurity: enabled: true
AWS bottlerocketでランタイムセキュリティを有効にする
AWSボトルロケットノードでランタイムセキュリティを実行するには、次の設定をoverrides.yamlファイル:
securityContext: scout: scout: allowPrivilegeEscalation: true privileged: true

トラブルシューティングの目的でログを収集する方法を教えてください。

問題のトラブルシューティングでは、いくつかのログを使用できます。

アクセスログ

ほとんどの問題は、アプリケーションログを使用して調査できます。ログには次のコマンドを使用してアクセスできます。 kubectl次のログにアクセスできます。
  • 次のコマンドを使用してアドミッションコントローラを実行します。 
    kubectl logs deployment/trendmicro-admission-controller --namespace ${namespace}
  • 次のコマンドを使用して実行時セキュリティコンポーネントを実行します。コンテナには次のいずれかを指定できます。スカウト、またはファルコ: 
     kubectl logs daemonset/trendmicro-scout --namespace ${namespace} -c ${container}
  • 次のコマンドを使用して、監視コントローラ (継続的コンプライアンスポリシーの適用) を実行します。 
     kubectl logs deployment/trendmicro-oversight-controller [controller-manager | rbac-proxy] --namespace ${namespace}
  • 次のコマンドを使用して、使用量コントローラを使用します。 
     kubectl logs deployment/trendmicro-usage-controller [controller-manager | rbac-proxy] --namespace ${namespace}

サポートログの収集

サポートケースを開くときは、必ずログパッケージを含めてください。ログパッケージは、サポートプロバイダが、特にクラスタ内コンポーネントや通信に関連する問題をデバッグするのに役立ちます。から使用できるログ収集スクリプトを利用できます。トレンドマイクロ Cloud One Container Security Helm GitHubリポジトリ。
次のコマンドを使用してログを収集します。
./collect-logs.sh
ログ収集では、次の環境変数がサポートされています。
環境変数 説明 初期設定
リリース Helmのリリース名 トレンドマイクロ
名前空間 Helmチャートが配置されている名前空間 で宣言されている現在の名前空間kubeconfig 。名前空間の設定が存在しない場合kubeconfigの場合トレンドマイクロシステム使用されます。

API呼び出しで「401 Unauthorized」メッセージが表示されるのはなぜですか?

これは通常、 Container Securityでリクエストを認証するためのAPIキーを作成していないことが原因です。 Trend Vision One APIキーの作成と使用については、を参照してください。APIキーの取得 。
[Deprecated]: 従来のAPIキーの作成と使用の詳細については、「Workload Security」を参照してください。 APIキーのヘルプ。

Container Securityでは、Kubernetesクラスタへの受信ネットワークアクセスが必要ですか?

Container Securityでは、現在、受信ネットワークアクセスは必要なく、受信ファイアウォールルールに追加のIPアドレスを追加する必要もありません。アドミッションコントローラからの通信は、HTTPSポート443を介してのみ発信されます。

ポリシーの作成時に正規表現はサポートされますか?

最初のリリースでは、イメージレジストリ、名前、およびタグに対してキーワード「contains」および「start with」がサポートされています。これは、基本的な正規表現インタフェースを提供します。

各Kubernetesクラスタに独自のアドミッションコントローラが必要ですか?

はい。各Kubernetesクラスタには、独自のアドミッションコントローラが必要です。必要に応じて、必要なレプリカをスケーリングできます。初期設定は1です。

Container Securityは、アドミッションコントロールWebhookの検証によってコンテナの設定を変更しますか?

いいえ。ポリシー定義で配信要求が許可または拒否されているかどうかのみを検証します。

検証フェーズ中に実行すると、 kubectl apply -f <...> 、アドミッション コントローラーはコンテナ セキュリティをクエリしますか?使用されている場合、各クエリにローカル キャッシュが使用されていますか?

はい。アドミッションコントローラは、Kubernetesでレビューリクエストが発生するたびにContainer Securityにクエリを実行します。 kubectl createまたはkubectl apply。
ポリシーを常に最新の状態に保つため、クエリやポリシーにローカルキャッシュは使用されません。
初期設定では、kube-system名前空間からのレビューリクエストはContainer Securityに転送されません。詳細については、アドミッションコントローラyamlファイル。

Container Securityのテレメトリは何に使用されますか?アドミッションコントロールが送信するデータの種類

データ収集とテレメトリの詳細については、を参照してください。 Trend Vision One Container Securityのデータ収集通知。

アドミッションコントローラのレプリカ数を増やす必要があるのはどのような場合ですか?

多数のアドミッション要求が同時に発生する可能性がある大規模な環境では、アドミッションコントローラのレプリカ数を増やすことを検討してください。アドミッション要求は、ポッドのレプリカ数がスケーリングされたとき、新しいデプロイが発生したときなどに発生します。

複数のコンテナを含むポッドを例外に追加するにはどうすればよいですか?

複数のコンテナを含むポッドでは、内部のすべてのコンテナに対して例外を設定する必要があります。Container Securityは、要求されたすべてのコンテナがポリシールールに違反していない場合、または除外基準を満たしていない場合にのみ、許可要求を許可します。

ポッドがネットワークアクセスから隔離されないのはなぜですか?

継続的コンプライアンスポリシーまたはランタイムルールで「隔離」アクションを使用している場合は、保護対象のリソースが実行されているKubernetesクラスタでKubernetesネットワークポリシーが有効になっている必要があります。 Kubernetesネットワークポリシーを有効にするには、 HelmチャートのREADME 。

脆弱性ビューに脆弱性が表示されないのはなぜですか?

このセクションでは、実行時検索でよく見られる問題とその対処方法について説明します。
スキャナポッドが終了しますOOMKilledステータス:
  • スキャナポッドのステータスは、次のようなツールで確認できます。 kubectl 。この場合、次のログが実行されます。
    kubectl describe nodes: Memory cgroup out of memory: Killed process xxxxx (sbom-job)
  • 通常の操作では、クラスタにデプロイされたすべての一意のイメージによってスキャナポッドがトリガされます。このスキャンジョブにより、配信されたイメージのソフトウェア部品表 (SBOM) が生成され、さらに分析するためにSBOMが Trend Vision One に送信されます。生成されたSBOMがスキャンジョブの初期設定の最大メモリ制限よりも大きい場合、Podは終了します。 OOMKilledステータス。非常に大きな画像 (機械学習画像など) は、SBOM のサイズが非常に大きくなる可能性があります。この問題を解決するには、検索ジョブの初期設定の最大メモリ制限ヘルムでYAMLファイルを上書きします (通常はoverrides.yaml ):
    cloudOne: apiKey: <API_KEY> endpoint: <ENDPOINT> vulnerabilityScanning: enabled: true resources: scanner: limits: memory: 1024Mi
  • 新しい設定を適用するには、ヘルムのアップグレードコマンド。同じ問題が引き続き発生する場合は、スキャナのメモリを再度増設することを検討してください (たとえば、 2048Mi )。
検出された脆弱性が脆弱性ビューに表示されなくなります:
  • ランタイム検索の脆弱性ビューには、現在、クラスタ内の脆弱性がリアルタイムで表示されます。クラスタで脆弱性が実行されなくなると (脆弱性のコンテナが終了すると)、脆弱性はただちに脆弱性ビューから削除されます。

クラスタに複数の検索ツールをインストールできますか?

クラスタごとに1つの検索ツールのみを含めることをお勧めします。このようなツールを複数同時に実行すると、両方のツールが互いのポッドを継続的に検索するという予期しない動作が発生する可能性があるためです。この状況を回避できない場合は、オーバーライドファイルに以下を追加することで、他の検索ツールの名前空間をContainer Security検索から除外できます。
cloudOne: exclusion: namespaces: [list, of, namespaces]
また、 Container Securityをインストールした名前空間を他の検索ツールによる検索から除外することをお勧めします。

脆弱性検索ポッドの最大同時実行数を増やす必要があるのはどのような場合ですか?

大規模なクラスタでは、脆弱性検索ポッドの初期設定の最大同時実行数クラスタのリソースをより多く使用して、検索結果を高速化します。 Scanner Podの同時実行数の制限は、クラスタ内でのContainer Securityのリソース使用量を制限することを目的としています。たとえば、同時実行数の制限が5に設定されている場合、一度にスキャンできる一意のイメージは最大5つです。 Scanner Podの同時実行制限の変更は、オーバーライドファイルを使用して行うことができます。
cloudOne: scanManager: maxJobCount: 15
脆弱性検索ポッドの同時実行数の上限を引き上げる場合は、追加の検索ポッドを処理するのに十分なリソースがクラスタにあることを確認してください。各スキャナポッドの初期設定のリソース要件を変更するには、 maxJobCountの値scanManagerのセクションヘルムチャート。