Kubernetesクラスター内イメージスキャン
このページでは、デプロイ先のKubernetesクラスター内でAikidoがコンテナイメージをスキャンする方法を説明します。
この機能は以下でのみ利用できます Pro と Advanced プランでご利用いただけます。 お問い合わせ 詳細はチャットでお問い合わせください。
Aikido Kubernetes 統合を使用すると、コンテナレジストリを Aikido に接続しなくても、Kubernetes クラスター内のコンテナイメージをスキャンできます。
クラスター内イメージスキャンの利点
完全なカバー範囲 クラスターにデプロイされたすべてのイメージを対象に、公開イメージも含みます。
リアルタイムスキャン：新しいイメージでポッドが起動されるたびに、Aikido がそれをスキャンし、検出事項は数分以内に Aikido フィードに反映されます。
イメージは決して環境外に出ません：Aikido エージェントは SBOM をプラットフォームに報告するだけです。
帯域幅の節約：Aikido エージェントはまず Kubernetes ノードにキャッシュされたイメージの使用を試み、見つからない場合、またはアクセスできない場合にのみレジストリから取得します。この点は、トラフィック量に応じて料金が発生するコンテナレジストリを利用している組織にとって特に重要です。
はじめに
Kubernetes クラスターのオンボーディング中にイメージスキャンを有効にできます
また、次の設定も必要になります sbomCollector.enabled=true を Helm チャートのインストール時に設定します。
実行が開始されると、Aikido でイメージを次の場所で確認できます コンテナページ.
イメージスキャンの動作を選択
このスキャン動作は、同じイメージの複数のバージョン／タグ（例： busybox:1.37 と busybox:1.36）をクラスターで実行している場合に関係します。
クラスター内イメージスキャンを有効にすると、Aikido が実行中のイメージをどのように追跡するかを選択できます：
実行中のイメージごとに 1 つのタグをスキャンする
これはよりシンプルな विकल्पです。クラスター内でイメージリポジトリごとにコンテナを 1 つだけ保持したい場合は、これを選択してください。同じイメージの複数のタグが実行されている場合、Aikido はそのイメージについて 1 つのコンテナを追跡し、最も最近デプロイされたバージョン／タグをスキャンします。
実行中のすべてのイメージタグをスキャンする
Kubernetes ワークロードごとに実行中のイメージを追跡したい場合は、このオプションを選択してください。同じイメージが複数のワークロードで異なるタグとしてデプロイされている場合、各タグは Aikido では別々のコンテナとして表示されます。
Kubernetes クラスターのオンボーディング中にスキャン動作を設定でき、後でクラスター設定から更新することもできます。
イメージの取得方法
エージェント（別名 SBOM コレクター）は、ローカルノードのキャッシュからイメージを取得しようとします（そのため、デフォルトでは root ユーザーとして DaemonSet で実行され、containerd と Docker のソケットをマウントできるようになっています）。
SBOM コレクターがノードキャッシュからイメージを見つけられない場合（またはランタイムソケットをマウントできない場合）は、対応するレジストリからイメージを取得します。プライベートレジストリへのアクセスについては、ほとんどの認証方式（ノード IAM ロール、imagePullSecrets、ワークロード ID）をサポートしています。アクセスの詳細と（必要に応じた）設定方法については、次を参照してください Helm チャートの README.
SBOM コレクターのシークレットアクセス
デフォルトでは、SBOM コレクターはクラスター内のすべてのシークレットにアクセスできます。これは、次の場合のアクセスを許可するためだけです。 imagePullSecret が使用される場合です。次のことができます。 シークレット名を指定する レジストリアクセス認証情報を含むものを指定し、SBOM コレクターに付与されるアクセスを最小限に抑えられます。
FAQ
イメージの新しいバージョン／タグをデプロイするとどうなりますか？
選択したイメージスキャン動作によります。
を使用する場合 実行中のイメージごとに 1 つのタグをスキャンする、Aikido はクラスター内の各イメージリポジトリにつき 1 つのコンテナを保持します。同じイメージのより新しいタグがデプロイされると、Aikido は追跡中のそのコンテナを最新のデプロイ済みバージョンに更新します。
を使用する場合 実行中のすべてのイメージタグをスキャンする、Aikido は Kubernetes ワークロードごとにイメージを追跡します。あるワークロードが busybox:1.32 から busybox:1.33に移行すると、Aikido は対応する Aikido コンテナを更新してスキャンし、異なるタグを実行している他のワークロードは引き続き別々のコンテナとして表示されます。
このスキャン形式は、Aikido が提供する他のコンテナ関連機能の恩恵も受けますか？
はい。クラスター内スキャンでスキャンされたイメージは、ノイズ削減、リポジトリへのリンク、AutoFix、Aikido Images など、Aikido が提供するすべての機能の恩恵を受けます。
特定のイメージを無視できますか？
クラスター内スキャンは、クラスターのオンボーディング時に設定した除外対象の名前空間を尊重します。スキャン対象の名前空間から特定のイメージを除外する必要がある場合は、次を推奨します Aikido でそのコンテナを無効化する.
Aikido が、もう存在しないコンテナに対してタスクトラッカーのチケットを作成し続けます。どうすればよいですか？
これは、デプロイプロセスで新しい Kubernetes Deployment を作成している場合（既存のもののイメージを更新するのではなく）、または頻繁に Kubernetes Job を実行している場合（CronJob によって管理されていない場合）に発生することがあります
そのような場合は、 実行中のイメージごとに 1 つのタグをスキャンする スキャン動作により、イメージリポジトリごとに 1 つのコンテナを維持して、より整理されたインベントリを実現し、チケットの作成とクローズを回避できます。
これは OpenShift クラスターでもよく見られます。多くのワークロードが同じイメージリポジトリの異なるタグを使用することがあり、たとえば openshift/release.
特定の Kubernetes 名前空間のコンテナ問題だけを表示できますか？
はい。Aikido は、コンテナが実行されている Kubernetes 名前空間を次のように表示します コンテナのラベル。ラベルの形式は次のとおりです k8s/namespace:<namespace>。これにより、 これらのラベルに基づいてフィードをフィルタリングできます.
最終更新
役に立ちましたか？