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

公開日
2023年1月19日

皆さん、こんにちは!トレンドマイクロでテクニカルサポートをしている野木です。
今回はテクニカルサポート部門で開発、運用している自動化プログラムであるSmartKobanzaki2(以下Kobanzaki)のAWS移行および環境のセキュア化についてのご紹介をさせていただきます。
オンプレ環境で動作しているブログラムをどのようにAWS上へ移行したかや、どのようなセキュリティ対策を行っているのかを掲載できればと考えています。
なお、本ブログは第四回となります。過去は以下となりますためぜひご覧ください。

目次

・以前のブログのおさらい
・本ブログ(第四回)での目標と設定実施について

・本ブログ(第四回)での設定項目
・目標構成
・設定の実施

・最後に

以前のブログのおさらい

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

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

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

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

・本ブログ(第四回)での設定項目

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

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

・目標構成

SmartKobanzaki2のAWS移行プロジェクト目標構成図

図1:本ブログでの目標構成図

・設定の実施

<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のサンプルパイプライン

図2:Github Actionsのサンプルパイプライン

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

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

CIパイプラインのymlファイル「on」配下

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

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

CIパイプラインのymlファイル「jobs」配下

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

・設定後の構成

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

図5: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処理を行うという流れにしています。

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

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

・設定後の構成

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

図6: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上でのブランチの保護設定箇所

図7:Github上でのブランチの保護設定箇所

Github ActionsでのCIテスト結果例

図8:Github ActionsでのCIテスト結果例

・設定後の構成

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

図9:ブランチ設定の変更での設定後の構成

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

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のスタート画面

図10:C1OSS by Snykのスタート画面

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

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

図11:アカウント設定内 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 CLIを使用する準備が整ったため、弊社環境では以下3つのコマンドを実施しソースコードの脆弱性チェックを行うことにしました。

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

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

図12:snyk monitor コマンドで登録されたリポジトリ画面

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

登録されたリポジトリの詳細画面

図13:登録されたリポジトリの詳細画面

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

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

snyk testの実行テスト例

図14:snyk testの実行テスト例

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

nyk code test の実行テスト例

図15:nyk code test の実行テスト例

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

snyk code testで脆弱性が検出された時の図

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

・設定後の構成

SmartKobanzaki2のAWS移行プロジェクト目標構成図

最後に

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

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

【連載記事】

執筆

トレンドマイクロ株式会社 エンタープライズSE本部 エンタープライズテクニカルサポート部ネットワークサポート課 野木 健

野木 健

トレンドマイクロ株式会社 エンタープライズSE本部
エンタープライズテクニカルサポート部 ネットワークサポート課
2022 APN ALL AWS Certifications Engineers
2022 APN AWS Top Engineers (Software)

監修

根本 恵理子

根本 恵理子

トレンドマイクロ株式会社 セキュリティエキスパート本部
セールスエンジニアリング部 サーバセキュリティチーム
ソリューションアーキテクト

CDN業界にて大規模なWebサービスの負荷分散やパフォーマンス改善、セキュリティ対策等の提案・導入を経験した後にセキュリティ業界へ転身し7年業務に従事。Trend Cloud Oneシリーズのソリューションアーキテクトとして、クラウド全体のセキュリティ対策の検討やストレージ環境に対するセキュリティ対策の普及に注力。またトレンドマイクロとAWSのアライアンスにてTech担当をしており、共催イベント、エンジニア連携企画等のリードに従事。