詳細検索
↑↓移動
↵選択
ESC閉じる

ビルド、公開、安全化:AWS CodePipelineがECR公開と脆弱性スキャンを簡素化

アバター
著者: Jatin Mehrotra12/05/2024
タグ cloud-infra mid-career aws Colorkrew
ビルド、公開、安全化:AWS CodePipelineがECR公開と脆弱性スキャンを簡素化
Englishから翻訳 • 原文を読む

Dockerイメージをプッシュしたり脆弱性スキャンを実行するためだけにCodeBuildを設定するのに疲れましたか?

*AWS CodePipelineの新しいECRBuildAndPublishとInspectorScanアクションにより、画像をパイプライン内で直接構築、公開、保護できるようになり、追加のセットアップは不要です。どのように機能するのか気になりますか?さあ、始めましょう!*

動機

2024年11月26日 – re:Invent 2024直前に、AWSはECRBuildAndPublishとInspectorScanアクションを導入する という刺激的なアップデート を発表しました。このアップデートにより、Dockerイメージの構築と公開が簡素化され、パイプラインがシームレスに対応できるようになります。

このアップデートはあなたにとって何を意味するのでしょうか?

アップデート 😭前に

Dockerのイメージ構築や脆弱性スキャンをパイプラインに組み込むには、 CodeBuildプロジェクトを手動で設定する必要がありました。これには以下が含まれます:

  • CodeBuildプロジェクトの設定設定。
  • ECRやその他のリソースへの安全なアクセスを確保するため、 IAMの役割と権限 を管理すること。
  • Dockerイメージのビルドとプッシュのためのコマンドを含む buildspec.yml ファイルの書き込みと維持。
  • 画像やソースコードのスキャンに サードパーティのセキュリティツール を統合し、追加のセットアップとコストが必要。
  • 学習 曲線や運用上のオーバーヘッドの対応、これによりパイプラインの納期が遅れる可能性があります。

アップデート 🤩後

CodePipelineの新しい ECRBuildAndPublish および InspectorScan アクションにより、これらの複雑さはすべて解消されます:

  • ECRリポジトリ名 を定義し、ソースコードリポジトリ内の Dockerfile を指すだけです。
  • CodePipelineは画像を自動的に構築し、ECRにプッシュし、脆弱性スキャンも統合します。これらは すべて別のCodeBuildプロジェクトを必要としません。
  • これはセットアップにかかる時間が減り、複雑さが軽減され、リソース消費が少なくなることを意味します。

*このアップデートはパイプラインの設定を簡素化するだけでなく、コンテナ化ワークフローの自動化における参入障壁を下げ、チームが運用の詳細よりもイノベーションにより集中できるようにしました。 *

これらの行動に関する重要な注釈

  • ECRBuildAndPublishアクション は、Amazon ECRソースリポジトリに変更があった際にパイプラインをトリガーするCodePipelineのAmazon ECRソースアクション とは異なります。
  • 両方のアクションは CodePipeline管理のCodeBuild計算を利用しており、AWS のCodeBuildで別々の料金が発生すること。

実際に動いている様子を見る:CodePipelineにおけるECRBuildAndPublishとInspectorScanの設定

建築図

  • ユーザーがコード内でチェックします。
  • パイプラインが作動します。
  • InspectorScanのSourceCodeScanアクションは、ソースコードの脆弱性をチェックするために実行されます。
  • もしその条件に合格した場合、dockerイメージが構築され、ECRにプッシュされます。
  • その後、InspectorScanのECRImageScanでECRリポジトリのプッシュドッカーイメージの脆弱性を最終的にチェックします。

前提条件

  • AWSアカウントへのアクセス
  • すでにAmazon ECRリポジトリを作成しています
  • Dockerfile

注意: このブログでは、コードパイプラインアクションによる脆弱性スキャンの結果を示すために、Log4j cveを含む脆弱なDockerFileを使用しています。 本番環境では使わないでください

ECRリポジトリを作成

  • 新しいリポジトリを作成してください。好きな名前を付けて構いません

パイプラインを作れ

  • カスタム パイプラインの構築 オプションを使って新しいコードピップラインを作成する。

  • 私はGitHubをソースプロバイダーとして使っているので、リポジトリの変更があればパイプラインが起動します。CodeStar接続をcで操作する必要があります。

  • ECRBuildAndPublishアクション を追加し、ECRリポジトリを指定する

  • デプロイステージをスキップしてパイプラインを作成する。
  • パイプラインは自動的に実行され、画像をECRにプッシュします

注意:もし「toomanyrequests: You has reached your pull rate limit.」というエラーが見られたら、認証とアップグレードによって制限を増加させることができます。その場合はAWS ECRの公開ギャラリーのベース画像を試してみてください

大きな問題 🚨

  • このブログを書いている時点で、コンソールからパイプラインを作成すると(これは長い間デフォルトオプションでした)、コンソールからパイプラインを作成すると自動的に実行されます。

  • これは ECRBuildAndPublish アクションの場合に限って非常に大きな問題です。なぜなら、脆弱なdockerイメージがECRにプッシュされた場合、下流システム(例えばK8)がそのイメージからコンテナをデプロイし、脆弱なアプリケーションが展開されるという大きな問題を引き起こすからです。
  • これは問題です。なぜなら、コンソールからパイプラインを作成する際に、他の段階やアクションを追加して脆弱性をチェックすることができず、パイプラインの実行が失敗し、イメージがECRリポジトリに公開されなくなるからです。

  • コンソールで修正されるまで、より多くのコントロールを得られるためにIaCを使うことをお勧めします。

AWS InspectorScan のテスト

  • InspectorScanアクションは2つのモードで可能です: SourceCodeScan または ECRImageScanです
  • 私はRepositoryを使いましたが、そこにはソースコードの脆弱性とDockerイメージの脆弱性の両方がコンテナ化されています。
  • 私にとって、アクションを追加しCI/CDを確保する理想的な場所は以下の通りです:
    • ECRBuildAndPublishアクション(ビルド段階)の前にInspectorScanアクションのSourceCodeScanを追加
    • ECRBuildAndPublishアクションの後にInspectorScanアクションのECRImageScanを追加

InspectorScanのソースコードスキャンのテスト

  • パイプラインを編集
  • ステージを追加、名前をスキャンコードとして出す

  • アクショングループをステージに追加し編集する
  • Awsインスペクタースキャンとしてアクションプロバイダーを追加

  • 実行モードをソースコードスキャンとして選択
  • Critical、High、Medium、Lowの閾値を0と指定してください。これはパイプラインを失敗させるために非常に重要です。なぜなら、Sourceに存在するCritical、High、Medium、Lowの脆弱性の数を計算し、それを超えるとCodePipelineはアクションに失敗しないからです。
  • 選択した出力アーティファクトの名前を指定し、パイプラインの変更を保存して手動でパイプラインを実行します。
  • ご覧の通り、実行がECRBuildAndPublishアクション(ビルドステージ)に到達する前にパイプラインが失敗しました。

InspectorScanのECRImageScanのテスト

  • ECRImageScanはECRリポジトリ内の画像をスキャンします。タグ付きの画像がなければ、この動作は自動的に失敗します。
  • ECRBuildAndPublishアクションの後にアクションを追加する必要があるので、手順はソースコードスキャンと同じままです。

  • ECRリポジトリ内でプッシュされたdocker画像をスキャンするための新しいステージとアクションを追加します。

  • パイプラインを通過させるために、ソースコードスキャンの閾値を削除し、実行をECRImageScanまで進めます。
  • パイプラインを保存して手動で実行する

ソリューションアーキテクトの視点から

  • ECRBuildAndPublish および InspectorScan アクション、さらに 10月にリリースされたコマンドアクション の導入は、コンテナ化されたワークフローの簡素化において大きな前進を示しています。追加のCodeBuildセットアップを不要にし、セキュリティスキャンをシームレスに統合することで、AWSはパイプラインをより迅速かつアクセスしやすくしました。
  • しかし、 コンソール経由で作成されたパイプラインの自動実行 は、特に脆弱なイメージがECRに送られる可能性があるため、正当なセキュリティ上の懸念を引き起こします。AWSが修正を導入するまでは、 インフラ・アズ・コード(IaC )がパイプラインの制御を維持する最良の方法であり続けます。

このアップデートは、より速くイノベーションを目指すチームにとって、堅牢なセキュリティ対策を確保したいチームにとって画期的なものとなります。

📣 これらのアップデートについてどう思いますか?

🔍 同じような課題に直面したり、創造的な回避策を見つけたことはありますか?

 

もっと見る

Related Articles