SnykLaunchの振り返り:カスタムベースイメージの推奨
2023年4月4日
0 分で読めます本日のSnykLaunchで紹介された注目の新機能の一つが、カスタムベースイメージの推奨(CBIR)です。2022年後半からオープンベータとして提供されているCBIRは、すでに複数の組織で利用されています。一般提供に向けて機能を拡充し、柔軟性を高めるとともに、手間のかからない自動化機能を追加しました。これにより、ユーザーはCBIRをCI/CDパイプラインで活用できます。
カスタムベースイメージの推奨は、Snyk Containerの中核をなす強力なベースイメージ推奨機能を拡張し、より高度なDevOpsワークフローを採用している組織やエンタープライズでも利用できるようにします。キュレーションした「ゴールデン」ベースイメージの選定、構築、カスタマイズ、強化を専門チームが担う場合も、人気の公式イメージ以外のイメージから始める場合も、ぜひ活用したい機能です。
コンテナ化されたアプリケーションの構築とリリースにはさまざまなワークフローがありますが、ベースイメージの選定、ビルド(共通ライブラリ、コンポーネント、プロジェクトファイルの追加)、デプロイという、共通する大まかなマイルストーンがあります。
ベースイメージの推奨が必要な理由
ベースイメージの選定は、多くの場合、プロジェクトで使われているプログラミング言語に基づいて「Docker Official」イメージを選ぶところから始まります。PythonアプリならPythonイメージ、JavaアプリならJavaイメージを探します。
コンテナイメージのデリバリーサイクルで重要なのは、脆弱性によるリスクを最小限に抑えることです。多くのツールは、イメージ内の脆弱なパッケージを検出し、修正版を提案できます。たとえば、node:14.0.0のベースイメージには、1,000件を超える脆弱性が含まれています。しかし残念ながら、多くのツールが次のように脆弱性ごとの対処方法しか提示しません。
この例では、脆弱性の一部を修正できるバージョンが示されていますが、何をすればよいのかは明確ではありません。1つだけパッチを適用するべきでしょうか。それともすべてに適用するべきでしょうか。
ベースイメージの推奨を利用すれば、より優れたイメージを見つけて、そこから開発を始められます。脆弱性を1つずつパッチする代わりに、ワンクリックで大量の脆弱性をまとめて解消できます。この例では、node:14.21.3にマイナーアップグレードするだけで脆弱性を64%削減でき、bullseye-slimに移行すれば、低深刻度の脆弱性が少数残るだけになります。

高度なDevOpsワークフロー
組織によってはアプリケーション開発チームがコンテナイメージの構築とメンテナンスを担いますが、より高度なワークフローを採用する組織もあります。そうした組織では、作業を分担し、プラットフォームチームが開発者向けの社内キュレーション済み、または「ゴールデン」ベースイメージを構築します。プラットフォームチームはベースイメージの起点を選び、社内基準に沿ってコンテナのベースイメージを設定・構築します。これには、共通ライブラリの追加、命名規則やタグ付け規則への準拠、ベースイメージの脆弱性を軽減するための強化などが含まれます。

責任を分担することで、開発者はベースイメージを修正する必要がなくなり、作成するアプリケーションに集中できます。
CBIRを使ったこの高度なワークフローの仕組みを見ていきましょう。
カスタムベースイメージのライフサイクル
プラットフォームチームとセキュリティチーム
この分業モデルでは、プラットフォームチームが起点となるイメージの選定と、開発者が使用するカスタムベースイメージの構築を担います。開発者がイメージをビルドするための、拡張性に優れた安全なサプライチェーンの自動化に責任を持つ一方、セキュリティチームにはベースイメージの状況を完全に可視化し、修正の優先順位を付けられるようにします。この可視性がフィードバックループとなり、チームはより安全なイメージをリリースできます。プラットフォームチームは、標準のベースイメージ推奨ロジックを使ってカスタムベースイメージを構築することもできます。
カスタムベースイメージを作成したら、CLI、CI/CD、API、Snyk UIなど、従来と同じ方法でSnykにインポートして監視できます。Snyk Containerでイメージの監視を開始した後、「カスタムベースイメージ」として指定し、任意で推奨の対象にできます。Snykは、セマンティックバージョニング、日付のマーキング、カスタムスキーマの命名パターンに基づいて、新しいバージョンを自動的に検出できます。

このプロセスはAPI経由で自動化することもできます。「推奨に使用」フラグを無効にすると、別のバージョンに置き換えたイメージを代替候補として提示しないようにできます。
開発者
コンテナがカスタムベースイメージから派生している、またはFROMでカスタムベースイメージを指定している場合、イメージファミリーに基づいて推奨が提示されます。また、イメージのビルドに使ったDockerfileが含まれていれば、この例のようにワンクリックでアップグレードすることもできます。この例では、開発者が脆弱性185件を含むmybaseimage:1.0を使用しています。最新のバージョン6.0では脆弱性が減少しており、開発者はすぐにアップグレード用のプルリクエストを作成できます。さらに、新しいベースイメージのバージョンがリリースされると、カスタムベースイメージから派生したイメージに対するプルリクエストを自動的に作成することもできます。

プラットフォームチームが提供するキュレーション済みのカスタムベースイメージを使えば、開発者が確認すべきノイズを取り除けます。その結果、手動またはパッケージマネージャー経由でコンテナに追加したパッケージや、アプリケーションに集中できます。ベースイメージについて心配する必要がなくなるのがポイントです。
コンテナサプライチェーンの自動化
前述のとおり、監視対象のベースイメージをカスタムベースイメージとして指定するAPIと、コンテナの命名に使うカスタムバージョニングスキーマを登録するAPIを新たに利用できます。これにより、使い慣れた方法でイメージに名前を付けながら、カスタムの推奨機能も利用できます。
これらのAPIを使えば、カスタムイメージのタグ付けとカスタムベースイメージの推奨を自動化ワークフローに組み込み、開発者がより安全なソフトウェアの提供に集中できるようになります。
機能の詳細については、カスタムベースイメージの推奨のドキュメントをご覧ください。
今すぐお試しください!
Snyk Containerのカスタムベースイメージの推奨は現在、Enterprise Tierのお客様にご利用いただけます。今後は無料プランを含む他のプランでも利用可能になる予定です。GA前に機能を有効にするには、担当アカウントマネージャーにお問い合わせいただくか、サポートチケットを起票してください。コンテナサプライチェーンのワークフローを自在に管理しましょう。
デモを実際にご覧になるには、SnykLaunchのオンデマンド録画をご視聴ください。
開発者ファーストのコンテナセキュリティ
Snykは、コンテナイメージとKubernetesワークロードの脆弱性を検出し、自動的に修正します。



