クラウドネイティブとソフトウェアサプライチェーンのセキュリティに関する私の考え

2011 年、インターネット技術の先駆者であるマーク・アンドリーセンは、ソフトウェアが世界を席巻していると宣言しました。ソフトウェア主導の業界イノベーションは、従来のビジネスモデルを破壊し、世界経済におけるデジタル接続を推進しています。インターネットの急速な発展により、デジタル変革はあらゆる企業にとって重要な戦略となっています。ただし、現代のソフトウェア開発では複数の関係者間のコラボレーションが必要であり、多数のアプリケーションがオープンソースコードまたはサードパーティコンポーネントに依存しています。アップストリームのオープンソースソフトウェアのセキュリティ問題は、ダウンストリームのユーザーに伝達されて拡大し、企業に重大なセキュリティリスクとビジネス損失を引き起こす可能性があります。

ソフトウェア制作のプロセスは、多くの点で従来の製造プロセスと似ています。ソフトウェアメーカーは、自社開発のビジネスコードとサードパーティのコンポーネントを組み合わせて、完全なソフトウェアを作成します。ビルドプロセスでは、これらのコンポーネントを展開可能なソフトウェア製品にパッケージ化し、企業顧客によって運用環境に展開します。このプロセスは、文字通り「ソフトウェアサプライチェーン」と呼ばれます。ソフトウェアサプライチェーンセキュリティの目標は、開発から展開までのライフサイクル全体を通じてソフトウェアの安全性と信頼性を確保することです。

Sonatypes の 2021 年ソフトウェアサプライチェーンの現状調査レポートによると、2021 年にソフトウェアサプライチェーン攻撃は 650% 増加しました。

現在、ソフトウェアサプライチェーンのセキュリティは業界から高い注目を集めています。多くの国では、サプライチェーンのセキュリティの回復力を向上させるために、自国のサプライチェーンセキュリティ管理をガイドする関連ポリシーや規制を導入しています。 2021 年 4 月、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁 (CISA) と米国国立標準技術研究所 (NIST) は共同で「ソフトウェアサプライチェーン攻撃に対する防御」レポートを発表しました。このレポートでは、ソフトウェアサプライチェーンが初めて定義され、ソフトウェアサプライチェーン攻撃、関連するリスク、および緩和策に関する情報が提供されました。

Google は、ソフトウェア成果物のサプライチェーンレベル (SLSA と略されるソフトウェア成果物のサプライチェーンレベル) も提案しました。 SLSA は、Google が長年にわたって社内で実装してきたセキュリティプロセスのオープンソースバージョンです。ソースコードの改ざん、サードパーティコンポーネントの脆弱性、製品リポジトリへの侵入によって引き起こされるセキュリティの脅威を防ぐためのセキュリティフレームワークと一連のベストプラクティスを提供します。

1. SBOM - ソフトウェア構成の透明性の向上

ソフトウェアサプライチェーンのセキュリティの基盤は透明性です。アプリケーションがコードと依存コンポーネントからどのように構築されるかを理解することによってのみ、アプリケーションのセキュリティリスクを効果的に管理できます。 2021年に米国が発行した「国家サイバーセキュリティの改善に関する大統領令」では、政府のソフトウェアには機械可読なソフトウェア部品表（SBOM）を含めることが明確に義務付けられています。 SBOM は、ソフトウェアの構築に使用されるさまざまなコンポーネントの詳細な情報とサプライチェーンの関係を含む正式な記録です。

国家電気通信情報局 (NITA) は、大統領令 14028 の要請により、2021 年 7 月 12 日に「SBOM の最小要素」をリリースしました。このドキュメントは、ツールを開発する組織やベンダー向けに、SBOM データ形式のリファレンスを提供します。新世代のソフトウェア開発ツールでは、SBOM をサポートするソフトウェアが増えています。

1. アプリケーションSBOM情報

SBOM の概念と使用方法を理解するために、Golang HTTP Server サンプルアプリケーションを例に挙げてみましょう。

 $ git clone https://github.com/denverdino/secure-supply-chain-sample
 $ cd secure -サプライチェーン-サンプル
$ ビルドを実行します。

Go 言語に精通している開発者は、Go モジュールの概念に非常に精通している必要があります。アプリケーションが依存するモジュールは、go.mod ファイルを通じて宣言されます。 go mod tidy コマンドを使用すると、go.mod ファイルを更新し、依存モジュールとバージョン情報を「ロック」することができます。これにより、ビルドの確実性、再現性、検証可能性が大幅に向上します。第三者が依存モジュールのバージョンを改ざんできないようにするために、各モジュール依存関係の暗号化されたハッシュ値が go.sum ファイルに記録されます。 go コマンドを使用してモジュールコードをローカルにダウンロードすると、そのハッシュ値が計算されます。計算結果がgo.sumに記録されたデータと一致しない場合は、改ざんの恐れがあります。さらに一歩進んで、Google は Go モジュールバージョンの暗号化ハッシュを記録する Go モジュール検証データベースサービスを運営しており、Go インフラストラクチャのセキュリティをさらに向上させています。

詳細については、https://go.dev/blog/supply-chain をご覧ください。

コンパイルされたアプリケーションバイナリファイルの場合、go version -m コマンドを使用して、ソフトウェアソース、依存モジュール、ビルドパラメーターなどのアプリケーションのビルド情報を表示できます。

 $ go バージョン- m セキュア-サプライ-チェーン-サンプル
セキュア- サプライチェーン - サンプル: go1 .18 .3
 パス github .com / denverdino / secure - supply - chain - sample
 mod github .com / denverdino / secure - supply - chain - sample ( devel )
 dep github .com / sirupsen / logrus v1 .8 .1 h1 : dJKuHgqk1NNQlqoA6BTlM1Wf9DOH3NBjQyu0h9 + AZZE =
 dep golang .org / x / sys v0 .0 .0 - 20220702020025 - 31831981 b65f h1 : xdsejrW / 0 Wf2diT5CPp3XmKUNbr7Xvw8kYilQ + 6 qjRY =
 ビルド-コンパイラ= gc
 CGO_ENABLED = 1をビルドする
 ビルド CGO_CFLAGS =
 ビルド CGO_CPPFLAGS =
 ビルド CGO_CXXFLAGS =
 ビルド CGO_LDFLAGS =
 GOARCH = amd64 をビルドする
 GOOS を構築する=ダーウィン
 GOAMD64 = v1 をビルドする
 ビルドvcs = git
 ビルド vcs .revision = c630057157df402b658ab97139895337633b5bbc
 vcs をビルドします。時間= 2022-07-04 T01 : 33 : 01Z
 ビルドvcs .modified = false

2. コンテナイメージのSBOMサポート

コンテナテクノロジーはソフトウェアサプライチェーン全体を再形成しました。コンテナイメージは、アプリケーションとそのすべての依存関係をパッケージ化して、さまざまなコンピューティング環境間でアプリケーションを迅速かつ確実に実行できるようにします。コンテナイメージはアプリケーション配布の標準となり、Kubernetes は分散リソースのスケジューリングとオーケストレーションの事実上の標準となりました。では、コンテナイメージの構築、配布、実行時にその整合性とセキュリティをどのように確保すればよいのでしょうか?

コンテナ化されたソフトウェアサプライチェーンのセキュリティに関する最新のプラクティスとツールチェーンを紹介するために、上記の Golang アプリケーションを引き続き例として使用します。

Ko は、Google がオープンソース化したシンプルで高速な Go アプリケーションコンテナイメージビルダーです。今日は、ソフトウェアサプライチェーンにおける Ko の設計の一部にのみ焦点を当てます。それらから学び、自分の言語やプロジェクトに適用することができます。

Dockerfile を書かなくても、Ko build を使用して Golang プロジェクトを Docker イメージにビルドできます。

 $ 猫.ko .yaml
 defaultBaseImage : knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / distroless / static :非ルート


$ エクスポート KO_DOCKER_REPO = knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino
 $ ko ビルド-B 。
 2022/07/02 21:05:33 github .com / denverdino / secure - supply - chain - sample のベースknative - dev - registry .cn - hangzhou .cr .aliyuncs .com / distroless / static : nonroot @ sha256 : 66 cd130e90992bebb68b8735a72f8ad154d0cd4a6f3a8b76f1e372467818d1b4 を使用
2022/07/02 21:05:33 github .com / denverdino / secure - supply - chain - sample for linux / amd64 を構築しています
2022/07/02 21:05:34 公開knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample : latest
 2022/07/02 21:05:35 既存のBLOB : sha256 : 64 ef75a9b8ab92a78ea225f1e707dfee0434dcf7cb0e0b5a8b5020e6b737b791
 2022/07/02 21:05:35 既存のBLOB : sha256 : 3 f99978937439fa8ef418c3f36e755f10d175ba218dda5f42846a52b8dca002d
 2022/07/02 21:05:35 knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample : sha256- cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 .sbom :ダイジェスト: sha256 : 0500 ec91074135a2774c87fe86833c0267713be9e78cc4ea86b86cc42701fd0a サイズ: 368
 2022/07/02 21:05:35 SBOM knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample : sha256- cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 .sbomを公開しました
2022/07/02 21:05:36 既存のBLOB : sha256 : 7 d883a3eb1c556752c73dedf88da2c0d3943b9f5c3f763cdd7a813ca766f5486
 2022/07/02 21:05:36 既存のBLOB : sha256 : 250 c06f7c38e52dc77e5c7586c3e40280dc7ff9bb9007c396e06d96736cf8542
 2022/07/02 21:05:36 既存のBLOB : sha256 : 1759 dab52bf113b8a23d818934e0fb48d6f4528df4d614b6edc1d7dba05a01b3
 2022/07/02 21:05:36 既存のBLOB : sha256 : 70e4 c71b62aef82e9650deb85d30f3402b435e07665d775a3f3b700e9e7300cb
 2022/07/02 21:05:36 knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample : latest : digest : sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 サイズ: 751
 2022/07/02 21:05:36 knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample @ sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 を公開しました
knative - dev - registry .cn -杭州.cr .aliyuncs .com / denverdino / secure - supply - chain - sample@sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3

画像の作成日時が「1970/1/1」となっているのはなぜですか？これは、Ko の設計目標の 1 つが再現可能なビルドをサポートすることだからです。再現可能なビルドは、ソースコードとビルド環境の構成が同一である場合に、異なるマシンでコンパイルされたターゲットバイナリがビット単位で同一であることを保証する一連の開発プラクティスです。これの利点は、独立した第三者がソースコードからバイナリファイルまでのコンパイルプロセスを検証して、脆弱性やバックドアが導入されていないことを確認できることです。一般的な docker build コマンドによってビルドされたコンテナイメージには、イメージのマニフェストファイルにビルドタイムスタンプが含まれ、イメージの HASH 計算にはマニフェストファイルが含まれます。つまり、同じコードと Dockerfile が使用されたとしても、ビルドされたイメージの HASH が同じであるという保証はありません。

Ko は、アプリケーションコードとイメージビルドのタイムスタンプを固定することで、どの環境でビルドされたイメージ HASH も変更されないようにします。したがって、画像のHASH値を比較することで、2つの画像の内容が一致しているかどうかをすぐに判断できます。未解決の質問ですが、再現可能なビルドはベストプラクティスでしょうか?あなたのビジネスシナリオに適していますか?

さらに、ソフトウェアサプライチェーンのセキュリティをより適切にサポートします。 Ko は、アプリケーションコンテナイメージに対応する SBOM 情報を自動的に生成し、アプリケーション製品としてイメージリポジトリにプッシュします。 URL パスからアクセスできます: {KO_DOCKER_REPO}/{IMAGE_NAME}:sha256-{HASH}.sbom

コンテナイメージの SBOM 情報を取得するにはどうすればよいですか?方法は 2 つあります。まず、コンテナイメージの SBOM 情報がイメージリポジトリに保存されていない場合は、docker sbom コマンドを使用してアプリケーションイメージの SBOM 情報を分析および生成できます。

 $ docker sbom knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample@sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
 サイフトv0.43.0
 ✔ 画像を読み込みました
 ✔ 解析された画像
 ✔ カタログパッケージ[ 6パッケージ]
名前 バージョン タイプ
ベース-ファイル11.1 + deb11u3 deb
 github .com / denverdino / secure -サプライチェーン-サンプル go -モジュール
github .com / sirupsen / logrus v1 .8 .1 go -モジュール
golang.org/x/sys v0.0.0-20220702020025-31831981 b65f go - モジュール
ネットベース6.3 deb
 tzdata 2021a - 1 + deb11u4 deb

2 つ目は、Ko が公開した SBOM 情報のように、コンテナイメージの SBOM 情報がイメージリポジトリに保存されているかどうかです。 Sigstore プロジェクトの cosign ツールを使用して、イメージの SBOM コンテンツを直接取得できます。

 $ cosign ダウンロード sbom knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample@sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
メディア タイプ: text / spdx の SBOM が見つかりました
SPDXバージョン: SPDX - 2.2
データライセンス: CC0 - 1.0
 SPDXID : SPDXRef -ドキュメント
ドキュメント名: github .com / denverdino / secure - supply - chain - sample
 ドキュメント名前空間: http://spdx.org/spdxpackages/github.com/denverdino/secure-supply-chain-sample
作成者:ツール: ko 0.11 .2
作成日: 1970 - 01 - 01 T00 : 00 : 00 Z


 ##### github .com / denverdino / secure - supply - chain - sample を表すパッケージ


パッケージ名: github .com / denverdino / secure -supply - chain - sample
 SPDXID : SPDXRef -パッケージ- github .com .denverdino .secure -サプライチェーン- サンプル
パッケージサプライヤ:組織: github .com / denverdino / secure - supply - chain - sample
 パッケージのダウンロード場所: https://github.com/denverdino/secure-supply-chain-sample
ファイル分析: false
 パッケージホームページ: https://github.com/denverdino/secure-supply-chain-sample
パッケージライセンス終了: NOASSERTION
パッケージライセンス宣言: NOASSERTION
パッケージ著作権テキスト: NOASSERTION
パッケージライセンスコメント: NOASSERTION
パッケージコメント: NOASSERTION


関係: SPDXRef -ドキュメントは SPDXRef を記述します-パッケージ- github .com .denverdino .secure -サプライ-チェーン-サンプル




関係: SPDXRef -パッケージ- github .com .denverdino .secure - supply - chain - sample DEPENDS_ON SPDXRef -パッケージ- github .com .sirupsen .logrus - v1 .8 .1


 ##### github .com / sirupsen / logrus を表すパッケージ


パッケージ名: github .com / sirupsen / logrus
 SPDXID : SPDXRef -パッケージ- github .com .sirupsen .logrus - v1 .8 .1
 パッケージバージョン: v1.8.1
パッケージサプライヤー:組織: github .com / sirupsen / logrus
 パッケージのダウンロード場所: https://proxy.golang.org/github.com/sirupsen/logrus/@v/v1.8.1.zip
ファイル分析: false
パッケージチェックサム: SHA256 : 7492 ae1e0aa4d4d35096aa00e814e533559ff43387dcd063432bb487df806591
パッケージライセンス終了: NOASSERTION
パッケージライセンス宣言: NOASSERTION
パッケージ著作権テキスト: NOASSERTION
パッケージライセンスコメント: NOASSERTION
パッケージコメント: NOASSERTION




関係: SPDXRef -パッケージ- github .com .denverdino .secure - supply - chain - sample DEPENDS_ON SPDXRef -パッケージ- golang .org .x .sys - v0 .0 .0 - 20220702020025 - 31831981 b65f


 ##### golang .org / x / sys を表すパッケージ


パッケージ名: golang.org/x/sys
 SPDXID : SPDXRef -パッケージ- golang .org .x .sys - v0 .0 .0 - 20220702020025 - 31831981 b65f
パッケージバージョン: v0 .0 .0 - 20220702020025 - 31831981 b65f
 パッケージサプライヤー: 組織: golang.org/x/sys
 パッケージのダウンロード場所: https://proxy.golang.org/golang.org/x/sys/@v/v0.0.0-20220702020025-31831981 b65f.zip
ファイル分析: false
パッケージチェックサム: SHA256 : c5db1e8eb5bfd167f67624f908fa775e629435bafb5efc3c9188a543eeaa8d16
パッケージライセンス終了:アサーションなし
パッケージライセンス宣言: NOASSERTION
パッケージ著作権テキスト: NOASSERTION
パッケージライセンスコメント: NOASSERTION
パッケージコメント: NOASSERTION

2. 新世代画像署名技術 - キーレス

ご存知のとおり、画像の追跡可能性を確保するために画像署名を使用できます。一般的に、開発者は秘密鍵を使用してイメージに署名します。アプリケーションをデプロイするときに、OPA/Gatekeeper を介してリクエストをインターセプトし、イメージの署名を検証できます。開発者はセキュリティポリシーを定義してセキュリティプロセスを自動化できます。たとえば、リスクの高い脆弱性を持つイメージを本番システムにデプロイできないようにするポリシーを定義できます。イメージ構築フェーズでは、イメージスキャンに合格し、高リスクの脆弱性を含まないイメージに署名できます。 K8s プロダクションクラスターでは、セキュリティポリシーを使用してイメージ署名を検証します。

これまで、イメージ署名/検証ツールは使いにくく、企業で広く使用されていませんでした。 Alibaba Cloud Image Service ACR と ACK は、統合され簡素化されたイメージセキュリティエクスペリエンスを提供し、イメージセキュリティの技術的なハードルを大幅に下げます。

今日は新しい技術的なアイデアをご紹介したいと思います。 Sigstore は、Red Hat、Google、およびいくつかのアメリカの大学によって開発および保守されているオープンソースのサプライチェーンセキュリティプロジェクトです。ソフトウェアの署名、検証、保護のための新しい標準を提供することを目的としています。 Sigstore を通じて、クラウドネイティブのさまざまなオープンソース製品に自動的にデジタル署名と検証を行うことができ、より安全で追跡可能なサプライ監視チェーンの構築に役立ちます。

その中でも、Sigstore のキーレス署名モードはこのプロジェクトの最大のハイライトの 1 つです。キーレス署名は、自動化されたキー管理機能をサポートします。ユーザーは秘密鍵を管理および維持する必要がないため、イメージの署名と検証のエクスペリエンスが大幅に簡素化されます。

まず、cosign sign コマンドを使用してイメージに署名します。

 $ COSIGN_EXPERIMENTAL = true共同署名 knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample@sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 に署名
一時キーを生成しています...
 署名された証明書を取得しています...


 この署名済みアーティファクトには個人を特定できる情報が含まれている可能性があることに注意してください。
 これには、認証に使用するアカウントに関連付けられた電子メール アドレスが含まれる場合があります。
 この情報は、このアーティファクトに署名するために使用され、公開透明性ログに保存され、後で削除することはできません。
 「y」と入力すると、許可（ または許可する権限を持っている）を証明し、この情報を透明性ログに永久に保存することに同意したことになります。


本当に続行しますか? ( y / [ N ] ) : y
ブラウザが開きます:
 https : // oauth2 .sigstore .dev / auth / auth?access_type = online & client_id = sigstore & code_challenge = Zj3B13VeqlwO1OEs_cc_gVly21ZWdotsB_ipAG1KUD0 & code_challenge_method = S256 & nonce = 2 BPd2p6uHg1e916zBz3MoEoH8FR & redirect_uri = http % 3 A % 2 F % 2 Flocalhost % 3 A55455 % 2 Fauth % 2 Fcallback & response_type = code & scope = openid + email & state = 2 BPd2uo32VlgXKC9NY0rDOJlfmA
 SCT の検証に成功しました...
インデックス2824482 でtlog エントリが作成されました
署名を次の場所にプッシュしています: knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample

キーレスモードでは、端末が自動的にブラウザを開き、ユーザーが認証用の OAuth ID サービスプロバイダーを選択すると、プロセスが完了します。 cosign はイメージに署名し、イメージ署名をイメージリポジトリに保存します。 URL パスは次のとおりです: {IMAGE_REPO}/{IMAGE_NAME}:sha256-{HASH}.sig

このプロセスでは、cosign は fulcio のルート証明書を使用して、イメージに署名するための一時的なキーと証明書を作成します。署名は Rekor の透明なログにも記録され、画像署名のリモート証明を提供します。 cosign verify コマンドを使用してイメージ署名を検証できます。

 COSIGN_EXPERIMENTAL = true共同署名検証 knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample@sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3


 knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample@sha256 の検証: cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3 --
これらの署名ごとに次のチェックが実行されました。
 -共同署名の主張は検証されました
-透明性ログ内のクレームの存在はオフラインで検証されました
-すべての証明書は Fulcio ルートに対して検証されました。


 [ { "critical" : { "identity" : { "docker-reference" : "knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample" } 、 "image" : { "docker-manifest-digest" : "sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3" } 、 "type" : "コンテナイメージ署名の共同署名" } 、 "optional" : { "Bundle" : { "SignedEntryTimestamp" : "MEQCIB1YeNP8suFn6xm7hn0qkAJBiID/gcOP//tsm7u2Z/FIAiBqiw0Zl1CvgVfcGhOWKUEkZKB2XdFm3FPaxq9E+Jsmyg==" 、 "ペイロード" : { "body" : "=" 、 "integratedTime" : 1656769347 、 "logIndex" : 2822273 、 "logID" : "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d" } } 、 "発行者" : "https://github.com/login/oauth" 、 "件名" : "[email protected]" } } 、 { "critical" : { "identity" : { "docker-reference" : "knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample" } 、 "image" : { "docker-manifest-digest" : "sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3" } 、 "type" : "cosign container image signature" } 、 "optional" : { "Bundle" : { "SignedEntryTimestamp" : "MEYCIQDdn2/IzVRCAuS+8s5Zz1F2+Gp3/MXzFP2whryasTa3GQIhAJKWFtb7jGnL8krnR4CwVYr/jbtZuHtlX7TpNPtEP67R" 、 "ペイロード" ： { "body" ： "=" 、 "integratedTime" ： 1656811260 、 "logIndex" ： 2824453 、 "logID" ： "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d" } } 、 "発行者" ： "https://github.com/login/oauth" 、 "件名" ： "[email protected]" } } 、 { "critical" : { "identity" : { "docker-reference" : "knative-dev-registry.cn-hangzhou.cr.aliyuncs.com/denverdino/secure-supply-chain-sample" } 、 "image" : { "docker-manifest-digest" : "sha256:cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3" } 、 "type" : "cosign container image signature" } 、 "optional" : { "Bundle" : { "SignedEntryTimestamp" : "MEUCIBe/RXXYBuyDXJVvCwFV/vcjfiUXnNqjS7HR2TpyB6WeAiEA+4MdLCkXW1zFqo4M0cdkNcPpEQe5ZfLw5mv266ib1oE=" 、 "ペイロード" ： { "body" ： "==" 、 "integratedTime" ： 1656811517 、 "logIndex" ： 2824482 、 "logID" ： "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d" } } 、 "発行者" ： "https://github.com/login/oauth" 、 "件名" ： 「[email protected]」 } } ]

Sigstore の cosign-gatekeeper-provider プロジェクトは、Cosign と OPA/Gatekeeper の統合を提供し、Kubernetes クラスター内のイメージの署名を検証できます。ただし、このバージョンは現在、キーレス署名をサポートしていません。キーレス署名をサポートするバージョンをフォークしました。

外部データ機能をサポートするには、Gatekeeper をインストールして構成します。

 $ helm リポジトリにゲートキーパーを追加しますhttps://open-policy-agent.github.io/gatekeeper/charts
 $ helm インストール ゲートキーパー/ゲートキーパー \
 --name-template=ゲートキーパー \
 --namespace ゲートキーパーシステム --create-namespace \
 --set 外部データを有効にする = true \
 --set controllerManager.dnsPolicy=ClusterFirst、audit.dnsPolicy=ClusterFirst

cosign-gatekeeper-provider をインストールし、有効な署名が含まれていないイメージを拒否するように OPA ポリシーを構成します。

 $ git clone https://github.com/denverdino/cosign-gatekeeper-provider
 $ cd 共同署名-ゲートキーパー-プロバイダー
$ kubectl apply -fマニフェスト
$ kubectl apply -fポリシー/テンプレート.yaml
 $ kubectl apply -fポリシー/制約.yaml

デプロイメントに正しく署名されたイメージが含まれている場合、正常にデプロイできることを確認できます。

 $ cat デプロイ.yaml
 apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
 名前:サンプル-デプロイメント
 ラベル:
 アプリ:サンプル
仕様:
 レプリカ： 1
 セレクター:
 マッチラベル:
 アプリ:サンプル
 テンプレート：
 メタデータ:
 ラベル:
 アプリ:サンプル
 仕様:
 コンテナ:
 -名前:サンプル
 イメージ: knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample@sha256 : cd1ac13d65aa8983f6c10317a09b994cd66fa46aceb1ba1eaf2cab4ee2038ec3
 ポート:
 -コンテナポート: 8080


 $ kubectl apply -fデプロイ.yaml
デプロイメント.apps /サンプル-デプロイメントが作成されました

イメージが署名されていない場合、デプロイメントのデプロイはブロックされます。

 $ cat deploy - 署名されていない.yaml
 apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
 名前:サンプル-デプロイメント- 未署名
 ラベル:
 アプリ:サンプル- 署名なし
仕様:
 レプリカ： 1
 セレクター:
 マッチラベル:
 アプリ:サンプル- 署名なし
 テンプレート：
 メタデータ:
 ラベル:
 アプリ:サンプル- 署名なし
 仕様:
 コンテナ:
 -名前:サンプル
 イメージ: knative - dev - registry .cn - hangzhou .cr .aliyuncs .com / denverdino / secure - supply - chain - sample : 未署名
 ポート:
 -コンテナポート: 8080


 $ kubectl apply -f deploy - 署名されていない.yaml
サーバーからのエラー(禁止) : 「deploy-unsigned.yaml」の作成中にエラーが発生しました:許可

3. 展望

真のエンドツーエンドのソフトウェアサプライチェーンセキュリティを実現するには、業界全体の努力が必要です。最近、多くのオープンソースコミュニティが関連技術への投資と協力を増やしています。

コンテナ技術の普及に伴い、AI モデルや Helm Charts など、OCI リポジトリを通じて管理されるソフトウェア製品が増えています。コミュニティの OCI Registry As Storage ORAS プロジェクトも誕生し、さまざまなアプリケーション製品の統合管理および配布機能を提供しています。 Cosign などのソフトウェアサプライチェーンセキュリティ機能も、これらのソフトウェアアーティファクトにシームレスに適用できます。 Kubernetes コミュニティは、独自のプロジェクトのための基本的なセキュリティ機能の構築も積極的に推進しています。バージョン 1.21 以降、リリースされるすべてのコンポーネントに関連する SBOM 情報が含まれるようになります。 KEP-3031 は、中間者攻撃を防ぎ、コンポーネントの整合性と信頼性を確保するために、ソフトウェア製品の署名メカニズムも推進しています。

コンテナイメージに加えて、Sonatype は、Java 開発プロセスにおけるサプライチェーンのセキュリティを向上させるために、Maven Central で Sigstore と連携することも発表しました。

これまで、ソフトウェアサプライチェーンの適用における最大の障害は、ユーザーエクスペリエンスでした。キー管理であれ、イメージ SBOM や署名などのメタデータ管理であれ、非常に複雑で、複数のシステムを連携させる必要がありました。 Sigstore/Cosign は、ユーザーエクスペリエンスの簡素化において大きな進歩を遂げました。ただし、Cosign は現在、イメージ署名のタグとして sha256-{IMAGE_HASH}.sig を使用するなどの規則に基づいています。このような設計は非常にシンプルですが、柔軟性と拡張性が欠けています。 OCI (Open Container Initiative) は、OCI リポジトリ内のソフトウェア成果物間の関係について標準化された記述とクエリメカニズムを提供することを目標として、参照タイプワーキンググループを設立しました。私たちは、ユーザーエクスペリエンスのシンプルさとシステムのスケーラビリティについて合意に達し、ソフトウェアサプライチェーンセキュリティ技術の普及をさらに促進するために、Sigstore コミュニティと協力することを楽しみにしています。

ソフトウェアサプライチェーンのセキュリティはまだ比較的新しい分野であり、多くのベストプラクティスとツールチェーンはまだ不完全です。現在、Cosign などのプロジェクトはまだ急速に発展しており、Keyless 署名メカニズムはまだ実用化されていません。この記事は、対応する技術アーキテクチャを学習および参照するすべての人を対象としています。

<<: グローバル分散ファイルシステム - ハイブリッドクラウドにおける高速アクセステクノロジー

>>: マルチクラウドオーケストレーションがオープンソースのID管理を推進