クラウド ネイティブ ビルドパックと Wolfi を使用したより安全なイメージ ビルド

1709144687
2024-02-28 18:05:44

ソフトウェア サプライ チェーンには、(オープン ソース) ライブラリ、ビルド ツール、さらにはそれが実行されるサーバーを含む、プログラミングから展開までのすべてが含まれます。 各段階には潜在的な弱点があり、現在の状況は次のとおりです。 安全とはほど遠い。 への攻撃 サプライチェーン ソフトウェア サプライ チェーンのセキュリティによって引き起こされる主な問題点は次のとおりです。

• オープン ソースの依存関係: オープン ソース コードに大きく依存していますが、その脆弱性を追跡し、更新を管理すると、すぐに混乱が生じる可能性があります。
• ツールの無秩序な増加と構成ミス: すべての開発者、ソフトウェア アーキテクト、CTO はお気に入りのツールを持っていますが、それらの寄せ集めと不適切な構成により、セキュリティ侵害を引き起こす可能性のあるギャップが発生する傾向があります。
• 不透明で複雑なワークフロー: 最新のソフトウェア開発には複雑なパイプラインと自動化が含まれており、どこで問題が発生しているかを正確に特定することが困難になっています。

ソフトウェア サプライ チェーンを保護しないと、データ侵害、経済的損失、風評被害など、悲惨な結果が生じる可能性があります。 したがって、ソフトウェア サプライ チェーンを構成するコンポーネントを保護することが重要です。 コンテナは、現在最も一般的なデプロイメント単位です。 クラウド ネイティブの世界では、これらは特に重要です。

しかし、コード、ライブラリ、依存関係を含む階層構造により、攻撃対象領域が拡大します。 各層には潜在的な脆弱性があり、リスクが増大します。 多数のコンテナにわたってこれらの脆弱性を追跡してパッチを適用することはモグラたたきのようなものとなり、サプライ チェーンはセキュリティ上の懸念が複雑に絡み合います。

ウルフィとは何ですか？

ウォルフィ は Linux ディストリビューションであり、その目的はコンテナ イメージに安全な基本層を提供することです。 これは「アンディストロ」として一般に販売されています。 それは、積極的に構想、構築、維持されます。 チェーンガード コミュニティの多くは経験豊富なソフトウェア セキュリティの専門家です。 彼らは集合的に、Wolfi CVE をフリーに保つことを目指しています。

関連するドキュメントを読んで、Wolfi の使い方を学びました。 ビジーボックス そして 高山。 両方 アルパイン・リナックス そして ビジーボックス ミニマリスト的なアプローチで有名です。 Linuxの世界。 これらはフットプリントの小ささ、効率性、セキュリティを優先しており、コンテナ、組み込みシステム、サーバーなどのリソースに制約のある環境に最適であり、Wolfi の設計原則はこれらから大きく取り入れられています。 Wolfi は、コンテナなどの最新のコンピューティング モデルをサポートするためにゼロから設計されています。

クラウドネイティブ ビルドパックとは何ですか?

ビルドパック ソースコードからコンテナを作成する方法です。 その意味で、これらは docker build の代替となります。 などの構成要素は使用しません。 Dockerfileただし、コンテナ化には既製の手段を提供します。 Cloud Native Buildpack (CNB) は Buildpack の仕様であり、Buildpack の設計方法の特定の側面を管理し、OCI ベースのコンテナの作成を支援することを義務付けています。

本番環境にも対応したクラウド ネイティブ ビルドパックの好例は次のとおりです。 パッケージ。

内部的には、Buildpack はビルド イメージと実行イメージを利用してコンテナーを作成します。 これらのイメージは最終コンテナ内のレイヤーとして使用されるため、最終コンテナのセキュリティに大きく貢献します。 Wolfi をビルド イメージや実行イメージとして使用すると、生成される最終イメージの CVE 数を減らすことができます。

Buildpack を利用する最良の方法は、次のようにすることです。 パック — コマンド ライン インターフェイス — ユーザーがソース コードからコンテナーを作成できるようにします。

BuildPacks と Wolfi を一緒に使用する利点は何ですか?

いくつかあります。 まず第一に、コンテナの品質が大幅に向上しました。 Buildpacks と Wolfi はどちらも大きなメリットをもたらし、このプロセスでは Docker や Jammy を使用した場合と比較して、イメージとコンテナーの性質が完全に変わります。 Wolfi を使用すると、イメージのサイズが小さくなり、Wolfi が t0 CVE に貢献するという 2 つの明確な利点が得られます。 Buildpacks を使用すると、Docker を使用して作成したイメージと比較して、自動化が容易で、よりモジュール化され、操作が簡単なイメージを作成できます。

チュートリアル

前提条件:

パック CLI をインストールする。

Dockerをインストールする。

両方のツールに対して簡単なコマンドを実行して、インストールが適切に動作していることを確認します。 例えば、

サンプル アプリケーションのコンテナを作成する手順は次のとおりです。

ベースイメージの作成

このステップは 2 つの部分から構成されます。 まず、Dockerfile を作成します。 この Dockerfile は、コンテナ化された環境内でアプリケーション (Cloud Native Buildpacks を使用して構築) を構築および実行するための、特定のユーザーおよびグループ構成を使用して基本イメージをセットアップします。 また、互換性のために必要な CNB ターゲット情報も提供します。

実行イメージの作成

最初のステップと同様に、実行イメージの Dockerfile を定義し、docker build コマンドを実行してそれをビルドします。 このイメージは後の段階で参照します。

お気づきのとおり、これはほぼ同一の Dockerfile です。 次に、ビルドコマンドを実行します。

ビルダーを作成する

この手順では、最初に構成ファイルを書き込む必要もあります。 builder.toml と呼ばれるこのファイルは、Buildpack ライフサイクル全体で使用される構成スキーマを指定します。

この builder.toml 設定ファイルは 3 つのことを行います。 まず、2 つの Java 関連のビルドパックが含まれており、Maven ベースのアプリケーション用のローカル ビルドパックを優先します。 パケトからの 1 つ — オープンソースのファミリー、 本番環境に対応したビルドパック。 次に、ビルド プロセス中の Buildpack 検出の順序を定義します。 最後に、ビルド用の特定の基本イメージとアプリケーションを実行するための特定の実行イメージへの参照が含まれています (どちらも前の手順で作成しました)。

次のコマンドを使用して、この構成 (builder.toml) を利用するビルダーを作成します。

ビルダーを使用してコンテナをエクスポートする

build サブコマンドを Pack とともに使用して、コンテナーを作成します。 ソースコードを忘れずに指定してください。

ビルダーはアプリケーションのソース コードを分析してそのタイプと依存関係を判断し、これに基づいてビルダーは一連の Buildpack を適用します。各ビルドパックは、最終イメージに特定のレイヤーを提供する役割を果たします。 Buildpack は、依存関係、ランタイム コンポーネント、アプリケーション自体など、イメージに必要なレイヤーを作成します。 その後、レイヤーが完全なコンテナー イメージに組み立てられ、ramiyengar/wolfi-java という名前のイメージが作成されます。

これをどう活用するか

まずは使い始めてください ビルドパック コンテナ作成ワークフローで。 エンジニアリング チームと運用の両方が、Buildpack が提供するものに多大なメリットがあることに気づくでしょう。 あらゆる言語とフレームワークのビルドパックが利用可能です。 また、複数の言語で書かれたアプリのイメージを構築できる複合フォームに構成することもできます。 Buildpack がイメージをエクスポートする方法に慣れたら、よりスリムで安全なベース イメージを使用してさらに最適化する作業に進みます。

スケッチで作成されたグループ。

#クラウド #ネイティブ #ビルドパックと #Wolfi #を使用したより安全なイメージ #ビルド