ブログ

Github Actionsを用いたイメージスキャン

Github Actionsを用いたイメージスキャン

本文の内容は、2020年1月14日にSysdigのÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/image-scanning-github-actions/)を元に日本語に翻訳・再構成した内容となっております。

このブログ投稿では、Sysdig Secure DevOps Platformを使用してGithub Actionsでイメージスキャンをセットアップする方法を学びます。イメージがレジストリにプッシュされる前に、ローカルスキャンを実行して脆弱性と悪い習慣を検出する基本的なワークフローを作成します。また、スキャンポリシーをカスタマイズして、定義された一連のルールに従ってビルドを停止させます。

Kubernetes /コンテナの世界におけるイメージスキャンとは、セキュリティの問題、脆弱性、または不正行為を検出するために、コンテンツを分析するプロセスとコンテナイメージのビルドプロセスを指します。 インラインスキャンには、イメージが最初にレジストリにプッシュされ、次に外部ツールからプルおよびスキャンされる従来のアプローチとは対照的にいくつかの利点があります。

  • 最初に、イメージはローカルで分析され、ビルド環境の外部には送信されません。機密性を提供し、定義されたポリシーに準拠していない場合にイメージが公開されないようにします。
  • スキャナーは、コンプライアンスポリシーに対して評価されるメタデータを生成します。ポリシーが変更された場合、イメージを再スキャンせずにコンプライアンスを即座に再評価できます。

Githubリポジトリでの脆弱性スキャン

デプロイされたほぼすべてのコンテナは他のコミュニティが提供するイメージの上に構築されるため、最下位層の脆弱性や特権コンテナや安全でないポートなどの悪い慣行により、インフラストラクチャ全体が危険にさらされる可能性があります。 開発プロセスの早い段階でセキュリティを導入することにより、イメージスキャンはCI/CDワークフローの重要なステップになりました(セキュリティシフトレフト)。

GitHub actionsを使用すると、gitリポジトリでソフトウェア開発タスクを直接自動化し、さまざまなイベントによってトリガーされる強力なCI/CDワークフローを作成できます。最も一般的なタスク用の既存のアクションの数は、Github Marketplaceで増え続けています。また、完全にカスタマイズされたワークフローを作成して、独自のアクションを作成することもできます。 Sysdig Secure Inline Scanアクションを含めることで実証するように、アクションの使用は簡単です。

ワークフローはコードをDockerイメージにビルドし、Sysdig Secure Inline Scanアクションを使用してローカルでイメージをスキャンを行います。その後、スキャン結果がSysdigに送信されます。スキャンがFailすると、ワークフローが中断し、イメージがレジストリにアップロードされなくなります。

t01.png

イメージスキャンをトリガーするGithubアクションの作成

必要な条件

Sysdig Image Scanningを起動して実行するための要件は簡単です。

  • イメージスキャンポリシーを設定するためのSysdig Secureアカウント。 また、スキャンの結果が収集される場所。
  • いくつかのコンテナDockerfileを作成する準備ができました。サンプルをフォークして使用することもできますが、独自のコンテナを使用する方が面白いです!

準備ができたら、次に進みましょう!

リポジトリでGithub Actionsを有効にします

リポジトリのアクションをアクティブにしていない場合、最初のステップは、サードパーティのアクションが有効になっていることを確認することです。リポジトリーの設定に移動して、「Actions」セクション(https://github.com/<user>/<repo>/settings/actions)を探します。

そこで、このリポジトリのローカルおよびサードパーティのアクションを有効にするオプションが選択されていることを確認してください。

t02.png

アクションを有効にすると、リポジトリのメインページの上部ナビゲーションバーに次のような[Actions]タブが表示されます。

t03.png

Githubでイメージスキャンワークフローを設定する

GitHubアクションは、GithubリポジトリでCI/CDソフトウェアワークフローを直接自動化できる機能です。アクション、ワークフローを作成するために結合される自動化されたタスクから名前を借用します。したがって、私たちの旅は、新しいワークフローを作成して構成することから始まります。

[Actions]タブで、左上の[New workflow]ボタンをクリックします。

t04.png

プロジェクトの種類に基づいた事前定義されたワークフローと一般的なワークフローが表示されます。 これらのワークフローのコードは、Starter Workflows repositoryで確認できます。また、学ぶには非常に良い例があります。これらのいずれかを選択して、イメージスキャンアクションを含めることができます。 ただし、ウィンドウの右上隅にある[Set up a workflow yourself]をクリックして、ワークフローを最初から開始します。

t05.png

デフォルトの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つのステップを宣言しました。

  • 最初のステップには名前がありません(これはオプションの属性であり、表示目的でのみ使用されます)。このステップには、アクションactions/checkout@v1を使用するように指示します。アクションはhttps://github.com/actions/checkoutにあります。
  • 「Build the Docker image」という名前の2番目のアクションはアクションを使用していませんが、代わりにcommand dockerを実行してイメージをビルドします。

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(このリポジトリのアクションコードを確認)を使用し、いくつかのパラメーターを受け取る新しい名前付きステップを宣言しています。

  • image-tag:スキャンするローカルイメージのタグ。dockerビルドステップで使用したタグと一致する必要があります。
  • sysdig-secure-token:Sysdig Secureで認証するためのAPIトークン。ポリシーの取得と結果の公開に使用されます。セキュアにするために、yamlファイルにAPIトークンを入れないでください。代わりに、SYSDIG_SECURE_TOKENという名前のGitHubシークレットを作成し、構文$ {{secrets.SYSDIG_SECURE_TOKEN}}を使用してそのシークレットを参照します。

ご覧のとおり、ジョブに新しいアクションステップを追加するのは非常に簡単です。しかし、さらに簡単にすることもできます。アクション名と構文を覚えたり、ドキュメントを読んだりする必要はありません。エディターの横にある[Marketplace]タブでは、マーケットプレイスで利用可能なアクションをすばやく検索できます。

t06.png

そして、YAMLスニペットをワークフローに直接コピーします。

t07.png

Sysdig Secure Inline Scanアクションにはさらにいくつかのパラメーターがありますが、ほとんどのユースケースにはデフォルトが適切です。

YAMLを終了したら、右上の[Start commit ]ボタンをクリックします。 メッセージとオプションの説明を追加し、変更をコミットします。

t08.png

GitHub Actionsワークフローは、リポジトリ内の.github/workflows/にある.ymlファイルです。つまり、アクションUIを使用する必要はありません。 リポジトリに.github/workflows/my-shiny-workflow.ymlを追加し、変更をコミットしてプッシュするだけで、キーボードから手を離さずに新しいワークフローを作成できます。

Githubでのイメージスキャン:ライト、カメラ、アクション!

リポジトリにDockerfileと有効なSecure APIトークンがある場合、作成したワークフローのコミットにより、ワークフローの実行がトリガーされ、イメージがビルドされ、スキャンされます。

リポジトリの「Actions」セクションに移動して、ワークフローの実行結果を確認できます。

t09.png

そして、ワークフローの実行をクリックして、すべてのステップの詳細ビュー、ログなどを取得します。

t10.png

分析結果は、Image Scanning -> Scan ResultsでSysdig Secureアカウントにポストされます。

t11.png

スキャン手順で複数の脆弱性が検出されましたが、スキャン結果が渡されるとジョブとワークフローは成功します。典型的なワークフローでは、スキャン後にイメージをレジストリにプッシュして公開します。ただし、重大なセキュリティ問題を伴うイメージを公開することはお勧めできません。スキャン結果に応じて、ジョブを中断し、ビルドを中断する必要があります。

脆弱性が見つかったときにビルドを中断させる

Sysdig Secure内では、イメージスキャンポリシーを定義し、それらのポリシーをレジストリ、リポジトリ、およびタグのサブセットに割り当てることができます。

デフォルトでは、デフォルトポリシーはすべてのレジストリ、リポジトリ、タグに割り当てられ、イメージで見つかった脆弱性はビルドを停止するのに十分ではありません。分析結果では、67個のWarnがありますが、Stopはないことがわかります。

ビルドを失敗させるには、Image Scanning -> Policiesに進み、デフォルトポリシーを編集して、スクリーンショットの最新のルール(Dockerfileで公開されているポート22)をWarnからStopに変更します。

t12.png

スキャン結果に戻ると、ポリシーが変更されるとすぐにルールが再評価され、以前のスキャンはパスしなくなりました。

t13.png

これらの変更はすぐに適用されます。 Kubernetes Admission Controllerを使用して脆弱なイメージをブロックする場合、新しいポッドは作成されません。ただし、Github Actionsを使用したCI/CDパイプラインでは、Dockerイメージの構築直後にスキャンが実行されるため、リポジトリで変更をトリガーしてアクションを再度実行する必要があります。スキャンが再度実行されますが、今回はポリシーの構成が原因で失敗し、ビルドが中断します。

t14.png

まとめ

ご覧のとおり、Github Actionsは、Githubリポジトリで直接CI/CDパイプラインを自動化する強力なツールです。Sysdig Secure Inline Scanをワークフローに組み込み、 イメージの脆弱性をスキャンし、ビルド時にベストプラクティスを実施し、従来のレジストリ内のイメージスキャンに比べていくつかの利点を提供するのは簡単です。

  • CI/CDパイプラインにイメージスキャンを実装すると、脆弱性が見つかった場合に、イメージがまったく公開されなくなります。
  • 解析はランナー内で(ローカルに)インラインで実行されるため、イメージは、それが構築された環境の外部を含め、他のどこにも送信されません。分析中に、実際のコンテンツではなく、メタデータ情報のみがイメージから抽出されます。
  • 分析から取得したメタデータは、新しい脆弱性が発見された場合、または警告のためのイメージの新しいスキャンを必要とせずにポリシーが変更された場合、後で再評価できます。ビルドを中断したい場合は、ビルド内で新しいスキャンをトリガーする必要があります。
  • Sysdig Secureは、さまざまなコンテナコンプライアンス標準(NIST 800-190PCIなど)を実施および遵守するための、すぐに使用可能なポリシーを提供します。

Sysdig Secureイメージスキャンは、JenkinsBambooAzure PipelinesAWS CodePipelinesなどのほとんどのCI/CDパイプラインツールともシームレスに統合されます。

試されたい方は、https://sysdig.com/ 内のProduct->Free Trialをクリックすると14日間のトライアルライセンスが発行されます。Sysdig Secureも試されたい方は、http://www.scsk.jp/sp/sysdig/index.htmlからお問い合わせいただければと存じます。

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top