Snyk ContainerでKubernetesアプリケーションをセキュアに

以前、SDLC全体でコンテナセキュリティを実装する方法についてご紹介し、ローカル、CI/CDパイプライン、レジストリ、Kubernetesクラスターでテストするそれぞれのメリットとデメリットを解説しました。Snyk Containerの新しいKubernetesインテグレーションでは、最後の工程をより簡単に実施できるようにするとともに、その情報を開発者により近い場所で確認できるようにすることで、脆弱性をすばやく修正し、Kubernetesのセキュリティを強化できるようにします。

Snykで脆弱性のあるKubernetesアプリケーションを検出

Snykではすでに、継続的インテグレーションのパイプラインでイメージをスキャンしたり、コンテナレジストリからイメージを直接インポートしたりできます。新しいKubernetesインテグレーションにより、クラスターも対象になります。インテグレーションを有効にするには、Helm Chartを使用してコントローラーをクラスターにインストールします。コントローラーはKubernetes APIへの読み取りアクセス権を持ち、ワークロードとそのワークロードで使用されているイメージを検出します。

コントローラーは情報をSnykに送信します。そこで特定のワークロードをインポートすると、Snykが分析して結果を報告します。

ワークロードをいくつかインポートすると、Snykにはイメージの脆弱性情報に加え、メタデータ（ワークロードが実行されているクラスターやワークロードの種類など）が表示されます。

イメージだけでなく、ワークロードも保護

特定のKubernetesワークロードには、数十から数百のPodが含まれ、さらに多くのコンテナが含まれる場合もあります。しかし開発者にとって、これらは基本的にプラットフォームの実装詳細にすぎません。個々のコンテナ単位で脆弱性データを確認する方法では、この点が考慮されず、開発者が使用する抽象化レベル（多くの場合、Deployment、CronJob、ReplicationControllerなど）にも合致しません。

クラスター内のイメージだけに注目しても、リスクの理解や実際に影響を受けるアプリケーションの特定に重要なコンテキストを見落とす可能性があります。

たとえば、SnykがKubernetesワークロードをインポートする際には、イメージの脆弱性とともに、重要なセキュリティ設定の情報も収集します。

この情報を確認すれば、設定を変更してセキュリティを強化すべきワークロードをすぐに把握できます。ケーパビリティが削除されていないワークロード、CPUやメモリの上限が設定されていないワークロード（サービス拒否攻撃の影響を軽減するのに役立ちます）、読み取り専用ファイルシステムを使用していないワークロードなどを検出します。

まとめ

Snyk Kubernetesインテグレーションは、Snyk Container製品の一部として有料プランのお客様にご利用いただけます。この初期機能を基盤に、コントローラーの設定項目の拡充、レポート機能の拡張、設定情報を活用した脆弱性の優先順位付けなど、さまざまな機能の開発を予定しています。詳細はドキュメントをご確認のうえ、ぜひご意見をお聞かせください。