【第四回】
SmartKobanzaki2のAWS移行プロジェクト
～CI/CDでの自動化～

以前のブログのおさらい

第一回ではKobanzakiの概要やAWS移行の構想、そしてAWS環境に適したセキュリティ設定を行うために利用する弊社製品のTrend Micro Cloud Oneについて記載しました。

第二回ではAWS上に移行するためのベースとなるAmazon VPCの作成やオンプレ環境との接続といったネットワークレイヤの設定、およびネットワークレイヤでのセキュリティ対策について記載しました。

第三回ではAWS上での開発環境の構築とホスト端末でのセキュリティ対策について記載しました。

本ブログ（第四回）での目標と設定実施について

・本ブログ（第四回）での設定項目

第四回の本ブログは以下を設定し、AWS上での開発環境の構築とホスト端末でのセキュリティ対策を行っていきます。

・Github Actions 設定 / CIパイプラインの作成
・CDパイプラインの作成
・ブランチ設定の変更
・ソースコードの脆弱性チェックの導入

・目標構成

図１：本ブログでの目標構成図

・設定の実施

<Github Actions 設定 / CI パイプラインの作成>

CI/CD環境にはGithub Actionsを選択しました。選んだ理由としてはすでに利用しているGithub Enterprise上で使用することができ、Jenkins等の新しいソフトウェアの導入コストや管理運用コストを抑えられるためです。
Github Actionsとは？：https://github.co.jp/features/actions

Github Actionsを使用しCIパイプラインを導入することでユーザのPull Request時に自動で必要なテストを実行するという環境を作ります。
※Github Actionsではデフォルトで複数のアプリケーションのサンプルパイプラインがあります。

図２：Github Actionsのサンプルパイプライン

設定方法としては 主に"on"の配下でどのタイミングでパイプラインを実行するか、"jobs"配下で実行する処理を定義します。

今回の実行タイミングはmasterブランチの特定のディレクトリへのPush時、またはmasterブランチへのPull Request時に自動で実行するように設定しています。
※"wokflow_dispatch"は手動でこのパイプラインを実行できるようにするパラメータとなっています。

図３：CIパイプラインのymlファイル”on”配下

また、実行する処理は各必要なテストコードの実行を書きます。
この時"runs-on"にはパイプラインを実行する環境のコンテナイメージ、"steps"の中に各処理を定義していきます。

図４：CIパイプラインのymlファイル”jobs”配下

・設定後の構成

図５：Github Actions 設定 / CI パイプラインの作成での設定後の構成

<CDパイプラインの作成>

CDパイプラインでは変更されたコードを自動的に展開する設定を行っていきます。
Kobanzakiのサーバはまだオンプレミス環境にあるため、AWS CodeDeploy(以下CodeDeploy)のオンプレミスエージェントを使用することでオンプレミス環境のサーバにデプロイを実行していきます。
https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/instances-on-premises.html

具体的な処理としては、本番環境へ展開するファイルをzipに圧縮しアーティファクトとしてS3にアップロード、その後CodeDeployからDeploy処理を行うという流れにしています。

今回の実装でのはまりポイントとして以下の３点がありました。

1. 既存の環境に対してCodeDeployを導入しデプロイを行う場合、appspec.yml内で"file_exists_behavior: OVERWRITE"を定義しないとファイルの上書き防止機能が動作し同一ファイルのデプロイができない
2. オンプレミス環境の場合、通常のCodeDeployエージェントのインストールやセットアップのほかにcodedeploy.onpremises.ymlを設定し、CodeDeployに対してオンプレミスインスタンスを登録する必要がある
3. プロキシを使用している環境でCodeDeployエージェントを利用する場合、codedeployagent.yml内 で":proxy_uri:"を定義しないとCodeDeployとの通信が行えず、デプロイ処理が行えない

・設定後の構成

図６：CD パイプラインの作成での設定後の構成

<ブランチ設定の変更>

CI/CDパイプラインの作成が終わった後はブランチの保護設定を行います。
この設定を行うことによりPull Requestをマージする際CIパイプラインでテストが正常に動作し完了することを条件に含めることができます。

https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule
Github上、ブランチの設定内で"Require status checks to pass before merging"にチェックをいれ"Status checks that are required."にチェックを必要とするパイプラインを選択することで、特定のパイプラインの結果で問題があった場合マージをブロックすることができるようになります。

図７：Github上でのブランチの保護設定箇所

図８：Github ActionsでのCIテスト結果例

・設定後の構成

図９：ブランチ設定の変更での設定後の構成

・ソースコードの脆弱性チェックの導入

CI/CDパイプライン環境では開発されたソースコードが使用しているオープンソースのライブラリに脆弱性が含まれていないか、またコードに脆弱性が含まれていないかをチェックするためにソースコードスキャンを行うセキュリティ製品を導入します。

Cloud One Open Source Security by Snyk(以下C1OSS by Snyk)とはソースコードリポジトリとビルドパイプラインにおけるオープンソースの脆弱性の検出と管理を提供します。
https://cloudone.trendmicro.com/docs/open-source-security-by-snyk/about/

C1OSS by SnykではGithub Enterpriseとネイティブ連携を行い、Github Actionsのパイプラインでのチェックも可能なのですが、今回の導入環境ではその連携方法が技術的制約により行えなかったため、パイプライン上でSnyk CLIを実行する構成としています。
https://docs.snyk.io/integrations/ci-cd-integrations/github-actions-integration

C1OSS by Snykを導入するため、Cloud OneコンソールからC1OSS by Snykをクリックし進みます。

図１０：C1OSS by Snykのスタート画面

今回はC1OSS by SnykとのIntegrationをCLIで行うためコンソールでのIntegration設定を行わずAPI Tokenを取得します。

図１１：アカウント設定内 API Token 確認画面

Snyk CLIを使用するために下記コマンドでSnyk CLIのインストール、および上記取得したAPI Tokenを使用した認証が必要となります。

curl https://static.snyk.io/cli/latest/snyk-linux -o snyk
chmod +x ./snyk
sudo mv ./snyk /usr/local/bin/
snyk auth $SNYK_TOKEN

また、Github Actionのパイプラインに導入する際、環境変数設定およびシークレット設定を利用することでAPI Tokenをプレーンテキストでファイルに記載せずに認証を行うSnyk CLIコマンドに渡す方法を採用します。

これでSnyk CLIを使用する準備が整ったため、弊社環境では以下３つのコマンドを実施しソースコードの脆弱性チェックを行うことにしました。

・snyk monitor
リポジトリの情報をスナップショットとして取得し、C1OSS by Snykのコンソール上に登録します。

図１２：snyk monitor コマンドで登録されたリポジトリ画面

Snyk monitorコマンドを利用しコンソールへ登録することでリポジトリ内の脆弱性等の問題点やオープンソースの依存関係について確認が可能になります。

図１３：登録されたリポジトリの詳細画面

https://docs.snyk.io/snyk-cli/commands/monitor

・snyk test
オープンソースのライブラリに脆弱性が含まれていないかの確認を行います。
※意図的に検出されるコードを含めて検査テストを行った結果、以下のように検出が行われました。
https://docs.snyk.io/snyk-cli/commands/test

図１４：snyk testの実行テスト例

・snyk code test
開発しているコードに脆弱性が含まれていないかの確認を行います。
※意図的に検出されるコードを含めて検査を行った結果以下のように検出が行われました。
https://docs.snyk.io/snyk-cli/commands/code-test

図１５：nyk code test の実行テスト例

・パイプラインとの連携
上記検査は脆弱性が検出されると"Error: Process completed with exit code 1."が返されます。

そのため、パイプラインの中で上記のコマンドを実行することで脆弱性を含んでいるコードの場合、テスト時にチェックを行いエラーが出力されてマージやテストに失敗させることができます。
また、ブランチの保護設定と併せることにより脆弱性が含まれたコードをマージされることから防ぐことも可能となります。

・設定後の構成

最後に

これでCI/CD環境の導入、およびソースコードの脆弱性スキャンができました！
Github ActionsおよびCodeDeployを使用することで都度開発者が手動で行っていたテストやデプロイを自動化し、より開発や別の業務に時間を割くことができるようになりました！
また、C1OSS by Snykを利用することによりソースコードでの依存関係やコードの脆弱性も検出することでより安全な開発が行えるようになりました！
次回はKobanzakiのコンテナ化とECS環境の構築およびコンテナ環境でのセキュリティ対策について記載します！

※製品画面等のスクリーンショットは11/1の情報となります。

【連載記事】