はじめに

この記事は、
　How to ensure only trusted container images are deployed to Cloud Run
という動画を参考に、『実際にやってみた』という記事になります。

この記事で実施する事。

Binary Authorization を有効にする。
Cloud Run Service をデプロイする。
認証者 が自動生成されていることを確認する。
認証者 をポリシーに設定する。
Cloud Run Service にポリシーを適用する。
デプロイが拒否されるかをテストする。

以下は、Binary Authorizationの構成になります。

脆弱なシステムを保護するには？

ソフトウェアサプライチェーンに対する攻撃から
脆弱なシステムを保護するには？

ソフトウェアサプライチェーン攻撃とは（Chat GPT）

サプライチェーン攻撃は、ソフトウェアの開発や配布の過程に
介在する第三者を通じて、攻撃者が悪意のあるコードを組み込む手法です。

この攻撃は、最終的な製品やサービスを使用するユーザーに対して、
未検出のままアクセスや情報漏洩のリスクを引き起こします。

脆弱なシステムを保護する方法（Chat GPT）

サプライチェーンの監視強化:
ソフトウェアの開発や配布過程で、全てのコンポーネントの出所を
確認し、定期的なセキュリティチェックを行う。

セキュリティ更新の迅速な適用:
新しい脆弱性やパッチが公開された際には、
迅速に更新を適用する。

最小権限の原則:
システムへのアクセス権限を必要最低限に保ち、
不正アクセスのリスクを減らす。

エンドツーエンドの暗号化:
データの安全な転送と保存のために暗号化技術を利用する。

定期的なセキュリティトレーニング:
従業員に対してセキュリティ意識の向上と教育を行う。

これらの対策は、ソフトウェアサプライチェーンの脆弱性を
低減し、攻撃からシステムを保護するために重要なことである。

代表的な攻撃例

SolarWinds 攻撃（Chat GPT）

概要: 2020年に発覚したこの攻撃は、IT管理ソフトウェアの大手企業である
SolarWindsのソフトウェア更新プロセスが侵害されたものです。

方法: 攻撃者は SolarWinds の Orion プラットフォームの
更新プロセスに悪意のあるコードを挿入しました。
この結果、何千もの SolarWinds の顧客がリスクにさらされました。

影響: 攻撃は、米国政府機関や大手企業などに広範な影響を及ぼしました。
この事件は、サプライチェーン攻撃のリスクを浮き彫りにしました。

Codecov 攻撃（Chat GPT）

概要: 2021年に発覚した Codecov 攻撃は、
ソフトウェア開発ツールの Codecov がハッキングされたものです。

方法: 攻撃者はCodecov の Bash Uploader スクリプトに
悪意のあるコードを挿入しました。
これにより、開発者がこのスクリプトを使用する際に、
機密情報が漏洩するリスクが生じました。

影響: この攻撃は、多くのCodecovの顧客に影響を及ぼしました。
漏洩した可能性のある情報には、セキュリティキー、トークン、
クレデンシャル などが含まれます。

Binary Authorization を有効にする。

セキュリティ > Binary Authorization を選択。

ポリシーを編集をクリック。

Binary Authorization API の画面が表示されるので、『有効にする』をクリック。

Cloud Run Service をデプロイする。

get-current-time を、git clone してください。

git clone https://github.com/tomo8332/gcp-sample.git

git cloneの実行が完了したら、cdコマンドを使って、対象のディレクトリ階層へ移動。

cd gcp-sample/cloud-run/golang/get-current-time

README.md を読んで、Cloud Run サービスのデプロイを行なってください。

『認証者』が自動生成されていることを確認する。

Binary Authorization に戻って、
認証者が自動生成されている事を確認してください。

Cloud Run の Service がデプロイされると、
認証者が自動生成されているはずです。

この認証者は、Cloud Buildで実行されるすべての
ビルドに暗号署名を行います。

署名された証明書には、作成元のソースコードや、
作成に使用されたコマンドなどの出所情報が
含まれるようになります。

『認証者』をポリシーに設定する。

ポリシーを更新して、すべてのビルドがデプロイされる前に、
その認証者によって署名されるように変更を行なってください。

Binary Authorization のポリシーを編集をクリック。

デフォルトのルールで、証明書を要求 を選択。

アテスター（認証者）の追加。

ポリシーを保存。

Cloud Run Service にポリシーを適用する。

ポリシーが適用されていない状態では、
適切なIAM権限を持つ認証済みユーザーは、
イメージとコンテナが構築された場所に関係なく、
引き続きイメージとコンテナをデプロイすることができてしまいます。

Cloud Run に戻って、ポリシーを適用するServiceを選択。

セキュリティタブを開いて、Binary Authorization で、
ポリシー『default』を選択して、適用をクリック。

デプロイが拒否されるかをテストする。

Cloud Build によって構築されていないコンテナを
デプロイしようとすると、システムはそのデプロイを
拒否するのか？を検証します。

Cloud Run のデプロイ画面でコンテナイメージを選択。

Google が提供しているテスト用のサンプルコンテナを選択。

このコンテナはどのように構築されたかわからない状態です。
知っているのは、自分のプロジェクトの
Cloud Build によって構築されていないことだけです。

デプロイを実行して、処理が失敗した事を確認する。

『サービス更新が Binary Authorization ポリシーによって拒否されました。』
と警告メッセージを表示していれば、ポリシーの適用は成功です。

これで、自分のプロジェクトで、構築されたコンテナは、
デプロイできますが、他の人が構築したコンテナは
デプロイできない状態となり、信頼できるコンテナイメージのみが
デプロイできるようになります。

終わりに

今回の記事は、動画を視聴しまして、
実際に『手を動かしてみた』という内容でまとめました。

セキュリティを強くするための方法の一つとして、
Binary Authorization を実践しました。

これまで、Cloud Build で、承認プロセスを組み込むことは
ありましたが、今回のように、『認証者』や『証明書』によって、
自分のプロジェクトで構築されたコンテナのみが
デプロイできるようになったことで、セキュリティ対策も、
さらに強固となる為の対策を学べました。

Binary Authorization について、
実際に試してみたいと考えていましたら、
参考にしていただけると幸いです。

あとで『じっくり読みたい』、『繰り返し読みたい』と
思ってくれましたら、『ストック』へ登録、
この記事が読まれている方にとって、
参考になる記事となりましたら、『いいね』を
付けていただけますと、励みになりますので、
よろしくお願いします。