Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、2020年1月14日にSysdigのÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/image-scanning-github-actions/)を元に日本語に翻訳・再構成した内容となっております。
このブログ投稿では、Sysdig Secure DevOps Platformを使用してGithub Actionsでイメージスキャンをセットアップする方法を学びます。イメージがレジストリにプッシュされる前に、ローカルスキャンを実行して脆弱性と悪い習慣を検出する基本的なワークフローを作成します。また、スキャンポリシーをカスタマイズして、定義された一連のルールに従ってビルドを停止させます。
Kubernetes /コンテナの世界におけるイメージスキャンとは、セキュリティの問題、脆弱性、または不正行為を検出するために、コンテンツを分析するプロセスとコンテナイメージのビルドプロセスを指します。 インラインスキャンには、イメージが最初にレジストリにプッシュされ、次に外部ツールからプルおよびスキャンされる従来のアプローチとは対照的にいくつかの利点があります。
デプロイされたほぼすべてのコンテナは他のコミュニティが提供するイメージの上に構築されるため、最下位層の脆弱性や特権コンテナや安全でないポートなどの悪い慣行により、インフラストラクチャ全体が危険にさらされる可能性があります。 開発プロセスの早い段階でセキュリティを導入することにより、イメージスキャンはCI/CDワークフローの重要なステップになりました（セキュリティシフトレフト）。
GitHub actionsを使用すると、gitリポジトリでソフトウェア開発タスクを直接自動化し、さまざまなイベントによってトリガーされる強力なCI/CDワークフローを作成できます。最も一般的なタスク用の既存のアクションの数は、Github Marketplaceで増え続けています。また、完全にカスタマイズされたワークフローを作成して、独自のアクションを作成することもできます。 Sysdig Secure Inline Scanアクションを含めることで実証するように、アクションの使用は簡単です。
ワークフローはコードをDockerイメージにビルドし、Sysdig Secure Inline Scanアクションを使用してローカルでイメージをスキャンを行います。その後、スキャン結果がSysdigに送信されます。スキャンがFailすると、ワークフローが中断し、イメージがレジストリにアップロードされなくなります。
Sysdig Image Scanningを起動して実行するための要件は簡単です。
準備ができたら、次に進みましょう！
リポジトリのアクションをアクティブにしていない場合、最初のステップは、サードパーティのアクションが有効になっていることを確認することです。リポジトリーの設定に移動して、「Actions」セクション（https://github.com/<user>/<repo>/settings/actions）を探します。
そこで、このリポジトリのローカルおよびサードパーティのアクションを有効にするオプションが選択されていることを確認してください。
アクションを有効にすると、リポジトリのメインページの上部ナビゲーションバーに次のような[Actions]タブが表示されます。
GitHubアクションは、GithubリポジトリでCI/CDソフトウェアワークフローを直接自動化できる機能です。アクション、ワークフローを作成するために結合される自動化されたタスクから名前を借用します。したがって、私たちの旅は、新しいワークフローを作成して構成することから始まります。
[Actions]タブで、左上の[New workflow]ボタンをクリックします。
プロジェクトの種類に基づいた事前定義されたワークフローと一般的なワークフローが表示されます。 これらのワークフローのコードは、Starter Workflows repositoryで確認できます。また、学ぶには非常に良い例があります。これらのいずれかを選択して、イメージスキャンアクションを含めることができます。 ただし、ウィンドウの右上隅にある[Set up a workflow yourself]をクリックして、ワークフローを最初から開始します。
デフォルトのmain.yml名をimage-scan.ymlなどのより適切な名前に変更し、組み込みエディターでワークフローYAMLを編集して、次の手順を使用します。
name: Build and scan Docker Image
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Build the Docker image
run: docker build . --file Dockerfile --tag sysdiglabs/dummy-vuln-app:latest
GitHub Acrionsの使用の詳細については、公式ドキュメントを確認してください。しかし、概要を簡単に見てみましょう。 「Build and scan Docker Image」という名前のワークフローを定義しています（つまり、リポジトリのアクションUIに表示される名前です）。ワークフローは、リポジトリでプッシュが発生するたびにトリガーされ、GitHubによってホストされるubuntu-latest runnerで実行され、ステップのリストを順番に実行するjob_idビルドでジョブを定義しています。もちろん、多くの種類のトリガーが利用可能です。 複数のジョブを並行して実行し、依存関係とジョブ間のデータフローを定義できます。さらに、自分でホストするランナーなど、さまざまなタイプのワーカーで実行できます。
このジョブでは、ランナーで実行される2つのステップを宣言しました。
GitHubランナーには、非常に広範なツールセットがプリインストールされています。この例のDockerイメージの構築など、ほとんどの典型的なユースケースに適合するはずです。
以下を追加して、イメージスキャンをトリガーする新しいステップを追加しましょう。
- name: Scan image
uses: sysdiglabs/scan-action@v1
with:
image-tag: "sysdiglabs/dummy-vuln-app:latest"
sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }}
sysdiglabs/scan-action@v1（このリポジトリのアクションコードを確認）を使用し、いくつかのパラメーターを受け取る新しい名前付きステップを宣言しています。
ご覧のとおり、ジョブに新しいアクションステップを追加するのは非常に簡単です。しかし、さらに簡単にすることもできます。アクション名と構文を覚えたり、ドキュメントを読んだりする必要はありません。エディターの横にある[Marketplace]タブでは、マーケットプレイスで利用可能なアクションをすばやく検索できます。
そして、YAMLスニペットをワークフローに直接コピーします。
Sysdig Secure Inline Scanアクションにはさらにいくつかのパラメーターがありますが、ほとんどのユースケースにはデフォルトが適切です。
YAMLを終了したら、右上の[Start commit ]ボタンをクリックします。 メッセージとオプションの説明を追加し、変更をコミットします。
GitHub Actionsワークフローは、リポジトリ内の.github/workflows/にある.ymlファイルです。つまり、アクションUIを使用する必要はありません。 リポジトリに.github/workflows/my-shiny-workflow.ymlを追加し、変更をコミットしてプッシュするだけで、キーボードから手を離さずに新しいワークフローを作成できます。
リポジトリにDockerfileと有効なSecure APIトークンがある場合、作成したワークフローのコミットにより、ワークフローの実行がトリガーされ、イメージがビルドされ、スキャンされます。
リポジトリの「Actions」セクションに移動して、ワークフローの実行結果を確認できます。
そして、ワークフローの実行をクリックして、すべてのステップの詳細ビュー、ログなどを取得します。
分析結果は、Image Scanning -> Scan ResultsでSysdig Secureアカウントにポストされます。
スキャン手順で複数の脆弱性が検出されましたが、スキャン結果が渡されるとジョブとワークフローは成功します。典型的なワークフローでは、スキャン後にイメージをレジストリにプッシュして公開します。ただし、重大なセキュリティ問題を伴うイメージを公開することはお勧めできません。スキャン結果に応じて、ジョブを中断し、ビルドを中断する必要があります。
Sysdig Secure内では、イメージスキャンポリシーを定義し、それらのポリシーをレジストリ、リポジトリ、およびタグのサブセットに割り当てることができます。
デフォルトでは、デフォルトポリシーはすべてのレジストリ、リポジトリ、タグに割り当てられ、イメージで見つかった脆弱性はビルドを停止するのに十分ではありません。分析結果では、67個のWarnがありますが、Stopはないことがわかります。
ビルドを失敗させるには、Image Scanning -> Policiesに進み、デフォルトポリシーを編集して、スクリーンショットの最新のルール（Dockerfileで公開されているポート22）をWarnからStopに変更します。
スキャン結果に戻ると、ポリシーが変更されるとすぐにルールが再評価され、以前のスキャンはパスしなくなりました。
これらの変更はすぐに適用されます。 Kubernetes Admission Controllerを使用して脆弱なイメージをブロックする場合、新しいポッドは作成されません。ただし、Github Actionsを使用したCI/CDパイプラインでは、Dockerイメージの構築直後にスキャンが実行されるため、リポジトリで変更をトリガーしてアクションを再度実行する必要があります。スキャンが再度実行されますが、今回はポリシーの構成が原因で失敗し、ビルドが中断します。
ご覧のとおり、Github Actionsは、Githubリポジトリで直接CI/CDパイプラインを自動化する強力なツールです。Sysdig Secure Inline Scanをワークフローに組み込み、 イメージの脆弱性をスキャンし、ビルド時にベストプラクティスを実施し、従来のレジストリ内のイメージスキャンに比べていくつかの利点を提供するのは簡単です。
Sysdig Secureイメージスキャンは、Jenkins、Bamboo、Azure Pipelines、AWS CodePipelinesなどのほとんどのCI/CDパイプラインツールともシームレスに統合されます。
試されたい方は、https://sysdig.com/ 内のProduct->Free Trialをクリックすると14日間のトライアルライセンスが発行されます。Sysdig Secureも試されたい方は、http://www.scsk.jp/sp/sysdig/index.htmlからお問い合わせいただければと存じます。