ビュー:

継続的なコンプライアンスのための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}

サポートログの収集

サポートケースを開く際には、ログパッケージを含めるようにしてください。ログパッケージは、特にクラスタ内のコンポーネントや通信に関連する問題をデバッグするのに役立ちます。ログ収集スクリプトは、トレンドマイクロから利用できます。
次のコマンドを使用してログを収集します。
./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に記載されているガイドを使用してNetworkPolicyをサポートするネットワークプラグインをインストールしてください。

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

このセクションでは、実行時検索でよく見られる問題とその対処方法について説明します。
スキャナポッドが終了しますOOMKilledステータス:
  • スキャナポッドのステータスは、次のようなツールで確認できます。 kubectl 。この場合、次のログが実行されます。
    kubectl describe nodes: Memory cgroup out of memory: Killed process xxxxx (sbom-job)
  • 通常の操作中、クラスターにデプロイされた各ユニークなイメージはスキャナーポッドをトリガーします。このスキャンジョブはデプロイされたイメージのソフトウェア部品表 (SBOM) を生成し、SBOMはさらなる分析のためにTrend Vision Oneに送信されます。生成されたSBOMがスキャンジョブのデフォルトの最大メモリ制限を超える場合、ポッドはOOMKilledステータスで終了されます。特に大きなイメージ（例えば機械学習のイメージ）は、特に大きなSBOMを引き起こす可能性があります。この問題を解決するために、Helmのオーバーライド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
脆弱性検索ツールポッドの同時実行制限を増やす場合、追加の検索ツールポッドを処理するためにクラスターに十分なリソースがあることを確認してください。各検索ツールポッドのデフォルトのリソース要件は、HelmチャートのscanManagerセクションでmaxJobCount値を変更することで変更できます。

ECS Scout サービスログを収集するにはどうすればよいですか？

ECS Scoutサービスからログを効率的に収集するには、以下の手順に従ってください

手順

  1. ECS クラスターに移動し、trendmicro-scout サービスを選択してサービスにアクセスします。
  2. [Logs] タブをクリックします。
  3. コンテナと時間のフィルターを適用して検索を絞り込み、分析に関連する最新のログに焦点を当てます。
  4. ログをさらに分析するには、[View in CloudWatch]をクリックします。CloudWatchでは、詳細な検査およびアーカイブのためにログをCSV形式でダウンロードするオプションがあります。

プライベートレジストリからイメージをプルするにはどうすればよいですか？

デフォルトでは、Container Security はパブリックコンテナイメージを Amazon ECR Public Gallery に保存し、helm chart で定義されたクラスターにそのイメージをプルします。プライベートレジストリを使用すると、レート制限されないイメージプルが可能になり、会社のベストプラクティスに沿った方法でコンテナイメージを保存できます。
プライベートレジストリからイメージをプルするには、以下の手順を使用します
注意
注意
以下の手順では、プライベートなAmazon Elastic Container Registry (ECR)を例として使用していますが、使用するコンテナレジストリによってプロセスは異なります。

手順

  1. Amazonユーザガイドの指示（ステップ1から8）に従って、Amazon ECR Publicのプルスルーキャッシュルール（AWS Management Console）を作成します。
  2. Helm オーバーライドファイルを修正して、プライベート ECR レジストリの URL、プロジェクト名、および次の形式を使用してイメージプルシークレットを使用するようにします:
    images: defaults: registry: <your-private-registry> project: <prefix-path> imagePullSecret: <pull-secret-if-needed>
    以下に例を示します。
    images: defaults: registry: <aws-account>.dkr.ecr.us-east-1.amazonaws.com project: <namespace>/trendmicro/container-security imagePullSecret: <ecr-cred>
    ヒント
    ヒント
    helm install または helm upgrade コマンドを使用して、Helm オーバーライドファイルの値を変更できます。