Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2019年11月26日にSysdigのFede Barcelonaが投稿したブログ(https://sysdig.com/blog/image-scanning-aws-codepipeline-codebuild/)を元に日本語に翻訳・再構成した内容となっております。
このブログ投稿では、Sysdig Secure DevOps Platformを使用して、AWS CodePipelineとAWS CodeBuildのイメージ脆弱性スキャンを設定する方法を学びます。
AWSは、DevOpsチームへバージョン管理用のCodeCommit、コードのビルドとテスト用のCodeBuild、自動コードデプロイメント用のCodeDeployツールを提供しています。これらすべてのツールの一番上のブロックはCodePipelineで、これらのさまざまなステージを視覚化および自動化できます。
AWS CodePipelineのイメージスキャンにより、DevOpsチームがデプロイメントにおけるセキュリティに自信を持ち、既知の脆弱性を検出し、パイプラインの早い段階でコンテナビルド構成を検証します。これらの問題を検出してから、イメージをコンテナーレジストリへ公開したり、運用環境にデプロイメントすることで、修正プログラムをより迅速に適用し、運用環境へのデリバリーを改善していく事ができます。
Sysdigを用いてイメージをスキャンするプロセスには以下が含まれます。
Dockerfileおよびイメージメタデータを分析して、次のようなセキュリティセンシティブな構成を検出します。
既知の脆弱性データベースに対するソフトウェアパッケージの確認:
また、次のようなすべてのイメージを確認するユーザー定義のポリシーまたはコンプライアンス要件:
Sysdigのローカルスキャニングを使用すると、イメージをバックエンドに送信したり、ステージングリポジトリに公開したりする必要がないため、イメージを管理できなくなる事はありません。イメージがビルドされると、パイプラインを実行するノードと同じノードでスキャンされ、スキャン結果のみがSaaSまたはセルフホストインスタンスに関係なく、Sysdig Secureバックエンドに送信されます。
AWSは、選択したイベントが発生したときに自動的に実行されるパイプラインを作成できるCI/CD DevOpsプラットフォームを提供しています。パイプラインのトリガーに使用される最も一般的なイベントは、コードリポジトリにプッシュする新規コミットとなっています。
この記事におけるAWS CodePipelineは、コミットがGitHubリポジトリにプッシュされた後に呼び出されます。Pipelineは、AWS CodeBuildを使用してリポジトリコードをイメージにビルドし、イメージをレジストリ(Amazon Elastic Container Registryなど)にプッシュして、Kubernetesにデプロイできます。
シンプルさ実現するために、この例に必要なすべてのインフラストラクチャはコードとして定義され、inline-scan-aws-infraリポジトリで利用可能なTerraformマニフェストを使用して再作成できます。
Terraformマニフェストは、後でイメージを構築およびスキャンするために設定する1つのAWS CodeBuildプロジェクトを定義しています。
また、次のように設定するAWS CodePipelineを1つ定義します。
そして最後に、イメージレジストリの認証情報とSysdig Secure APIトークンをAWS Parameter Storeに保存します。これは、漏洩を防ぐためにシークレットを処理するための推奨される方法です。
以下を実行して作成します:
terraform apply
リポジトリのドキュメントで設定の詳細を確認してください。
インフラストラクチャが作成されたら、構築プロセスのセットアップを開始できます。 ビルドの手順は次のとおりです。
AWS CodeBuildは、コードリポジトリのルートパス内のbuildspec.ymlファイルで定義されている手順を実行します。
version: 0.2 env: variables: IMAGE_NAME: "sysdiglabs/dummy-vuln-app:latest" SCAN_IMAGE_NAME: "sysdiglabs/secure_inline_scan:latest" parameter-store: DOCKER_LOGIN_USER: dockerLoginUser DOCKER_LOGIN_PASSWORD: dockerLoginPassword SYSDIG_SECURE_TOKEN: sysdigApiToken phases: install: runtime-versions: docker: 18 commands: - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2& - timeout 15 sh -c "until docker info; do echo .; sleep 1; done" pre_build: commands: - docker login -u $DOCKER_LOGIN_USER -p $DOCKER_LOGIN_PASSWORD - docker pull $SCAN_IMAGE_NAME build: commands: - docker build . -t $IMAGE_NAME post_build: commands: - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock $SCAN_IMAGE_NAME /bin/inline_scan analyze -s https://secure.sysdig.com -k $SYSDIG_SECURE_TOKEN $IMAGE_NAME
- docker push $IMAGE_NAME
詳細を見て行きましょう。
env: variables: IMAGE_NAME: "sysdiglabs/dummy-vuln-app:latest" SCAN_IMAGE_NAME: "sysdiglabs/secure_inline_scan:latest" parameter-store: DOCKER_LOGIN_USER: dockerLoginUser DOCKER_LOGIN_PASSWORD: dockerLoginPassword
SYSDIG_SECURE_TOKEN: sysdigApiToken
最初に、パイプラインの環境変数を定義します。
Terraformマニフェストを使用して、AWS Systems Manager> Parameter Storeに機密情報を保存します。
ここで、実際のビルド、新しいコミットがあるときに実行する手順を定義します。
install: runtime-versions: docker: 18 commands: - nohup /usr/local/bin/dockerd --host=unix:///var/run/docker.sock --host=tcp://127.0.0.1:2375 --storage-driver=overlay2&
- timeout 15 sh -c "until docker info; do echo .; sleep 1; done"
パイプラインにより、ランナーにDocker18がインストールされます。ランナーはDockerをデーモンとして起動し、実行されるまで待機します。
pre_build: commands: - docker login -u $DOCKER_LOGIN_USER -p $DOCKER_LOGIN_PASSWORD
- docker pull $SCAN_IMAGE_NAME
イメージをビルドする前に、Dockerレジストリにログインし、インラインスキャンスクリプトを使用してイメージをプルします。
build: commands:
- docker build . -t $IMAGE_NAME
次に、ランナーはgitリポジトリのDockerfileを使用して1つのイメージをビルドします。
post_build: commands: - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock $SCAN_IMAGE_NAME /bin/inline_scan analyze -s https://secure.sysdig.com -k $SYSDIG_SECURE_TOKEN $IMAGE_NAME
- docker push $IMAGE_NAME
スキャンツールは、イメージがビルドされたのと同じマシンのランナー内でスキャンを実行しますが、コンテナイメージがAWSアカウントを離れることはありません。
Sysdig Secureでは、さまざまなチェックを使用して複数のスキャンポリシーを構成し、危険と見なされ、警告またはブロックする必要があるものを定義できます。
イメージにスキャンポリシーを割り当てることは、レジストリ、リポジトリ、またはタグをポリシーにリンクするのと同じくらい簡単です。
inline_scanスクリプトがスキャンポリシーからSTOP条件を検出した場合、スクリプトは0以外のリターンコードで中止され、パイプラインの実行は失敗と見なされます。その後、パイプラインの実行はここで終了します。
ただし、すべてが正しく、イメージがスキャンにパスした場合、パイプラインは続行し、イメージをDockerレジストリにプッシュします。
パイプラインを実行して、動作を確認しましょう!
パイプラインの結果は次のとおりです。 おっと! 何かがおかしいです:
[Details]に移動して[Execution details]を開くと、失敗したCodeBuildの実行が表示されます。
[Phase details]タブでは、POST_BUILDステージでどのように失敗したかを確認できます。また、最後に実行されたコマンド(エラーを生成したコマンド)を特定することもできます。
Sysdig Secureですべての情報を確認しましょう。
イメージはローカルマシンでスキャンされますが、結果はさらに分析するためにSysdig Secureに送信され、レポート全体をダウンロードできます。
次のことがわかります。
無防備なポート22は、スキャン結果のSTOP条件です。
イメージ内にオペレーティングシステムの脆弱性が見つかりました。
ソフトウェアが使用するライブラリからの非オペレーティングシステムの脆弱性。
Sysdig Secureは、DevOpsワークフローのセキュリティを強化する次の機能を提供しています。
リポジトリ用のアラートをSysdig Secureで作成。
AWS CodePipelineのイメージスキャニングにより、DevOpsチームは、コンテキストが最新の場合、CI/CDパイプラインの初期段階で問題を検出できます。これにより、セキュリティ、デリバリーが向上し、本番環境でイメージを実行する自信が高まります。
Sysdigを使用すると、AWS CodePipelineで構築したイメージを、インフラストラクチャから離れることなく、ステージングレジストリを必要とせずにスキャンを実施できます。これにより、複数のスキャンを並行して実行し、スループットを向上させることができます。