信頼できるコンテナ イメージのみが Cloud Run にデプロイされるようにする方法

## はじめに

この記事は、
　[How to ensure only trusted container images are deployed to Cloud Run
](https://www.youtube.com/watch?v=b7GdpEEvGDQ)という動画を参考に、『実際にやってみた』という記事になります。


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

以下は、Binary Authorizationの構成になります。
![binary_authorization.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/5f0d1297-d27b-4bc8-481d-379652210542.png)

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

ソフトウェア サプライチェーン攻撃とは（Chat GPT）  
> サプライチェーン攻撃は、ソフトウェアの開発や配布の過程に
介在する第三者を通じて、攻撃者が悪意のあるコードを組み込む手法です。
>
> この攻撃は、最終的な製品やサービスを使用するユーザーに対して、
未検出のままアクセスや情報漏洩のリスクを引き起こします。

脆弱なシステムを保護する方法（Chat GPT）
>1. サプライチェーンの監視強化: 
ソフトウェアの開発や配布過程で、全てのコンポーネントの出所を
確認し、定期的なセキュリティチェックを行う。
>
>2. セキュリティ更新の迅速な適用: 
新しい脆弱性やパッチが公開された際には、
迅速に更新を適用する。
>
>3. 最小権限の原則: 
システムへのアクセス権限を必要最低限に保ち、
不正アクセスのリスクを減らす。
>
>4. エンドツーエンドの暗号化: 
データの安全な転送と保存のために暗号化技術を利用する。
>
>5. 定期的なセキュリティトレーニング: 
従業員に対してセキュリティ意識の向上と教育を行う。

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


## 代表的な攻撃例

SolarWinds 攻撃（Chat GPT）
>概要: 2020年に発覚したこの攻撃は、IT管理ソフトウェアの大手企業である
SolarWindsのソフトウェア更新プロセスが侵害されたものです。
>
> 方法: 攻撃者は `SolarWinds` の `Orion` プラットフォームの
更新プロセスに悪意のあるコードを挿入しました。
この結果、何千もの `SolarWinds` の顧客がリスクにさらされました。
>
>影響: 攻撃は、米国政府機関や大手企業などに広範な影響を及ぼしました。
この事件は、サプライチェーン攻撃のリスクを浮き彫りにしました。

Codecov 攻撃（Chat GPT）
>概要: 2021年に発覚した `Codecov` 攻撃は、
ソフトウェア開発ツールの `Codecov` がハッキングされたものです。
>
>方法: 攻撃者は`Codecov` の `Bash Uploader` スクリプトに
悪意のあるコードを挿入しました。
これにより、開発者がこのスクリプトを使用する際に、
機密情報が漏洩するリスクが生じました。
>
>影響: この攻撃は、多くの`Codecov`の顧客に影響を及ぼしました。
漏洩した可能性のある情報には、`セキュリティキー`、`トークン`、
`クレデンシャル` などが含まれます。


## Binary Authorization を有効にする。  
セキュリティ > Binary Authorization を選択。
![sec_Binary _Authorization.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/2858eab6-f605-c5ac-f57b-264bb2f51f17.png)

ポリシーを編集をクリック。  
![binary_authorization_policy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/52f29b9f-5640-da31-0c36-344d286cf568.png)

Binary Authorization API の画面が表示されるので、『有効にする』をクリック。
![binary_authorization_api.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/b75cc991-83b1-878d-43ce-7f6756d0d875.png)


## Cloud Run Service をデプロイする。
[get-current-time](https://github.com/tomo8332/gcp-sample/tree/main/cloud-run/golang/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](https://github.com/tomo8332/gcp-sample/blob/main/cloud-run/golang/get-current-time/README.md) を読んで、Cloud Run サービスのデプロイを行なってください。


## 『認証者』が自動生成されていることを確認する。
`Binary Authorization` に戻って、
認証者が自動生成されている事を確認してください。

`Cloud Run` の Service がデプロイされると、
認証者が自動生成されているはずです。
![binary_authorization_認証者.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/b529f7e2-5665-a255-0ef7-07e560ece0e3.png)

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

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


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

`Binary Authorization` の ポリシーを編集 をクリック。
![binary_authorization_top_fix.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/f0e6dc7d-d2db-402b-34de-a2dc533df946.png)

デフォルトのルールで、`証明書を要求` を選択。
![binary_authorization_rule.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/c58d2ef5-ceaa-4731-5c91-177d2fb4bbcb.png)

アテスター（認証者）の追加。
![binary_authorization_認証者_fix.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/1ddd801e-70ca-0660-7f84-46ba04c7f167.png)

ポリシーを保存。


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

`Cloud Run` に戻って、ポリシーを適用するServiceを選択。
![binary_authorization_cloud_run.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/5ae6f5b0-c231-bb18-8838-01198e0de87d.png)

セキュリティタブを開いて、`Binary Authorization` で、
ポリシー『`default`』を選択して、適用をクリック。
![binary_authorization_sec_fix.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/4e1cb3a2-3822-d461-ad92-186afe158cba.png)


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

`Cloud Run` のデプロイ画面でコンテナイメージを選択。
![binary_authorization_deploy_fix.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/7ca46389-a6bb-13b6-983d-e4a2541c83a1.png)

Google が提供しているテスト用のサンプルコンテナを選択。
![binary_authorization_deploy_image_fix.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/92bebed4-64c7-3229-b715-58d5c1c2579e.png)

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

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

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

![binary_authorization_cloud_run_deploy_com.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2952807/d8dacf2d-2496-8380-e9c0-3393f09f7811.png)


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


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

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

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

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

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