RegulaとBitbucket Pipelinesを使ったCI/CDでのTerraform IaCセキュリティチェック［チュートリアル］

Regula 2.3.0を使うと、クラウドチームはTerraform、CloudFormation、Azure Resource Manager、KubernetesのInfrastructure as Code（IaC）を評価し、デプロイ前にセキュリティ違反やコンプライアンス違反を検出できます。Regulaを継続的インテグレーション／継続的デリバリー（CI/CD）パイプラインに組み込めば、クラウドインフラの安全なデプロイを自動化し、さらに一歩進めることができます。

この記事では、Terraformで定義したAmazon Web Services（AWS）リソースのテストを自動化するため、Bitbucketに組み込まれたCI/CDサービスであるBitbucket PipelinesにRegulaを統合する方法を紹介します。Terraformを含むリポジトリにコミットすると、Bitbucket Pipelinesがビルドを実行します。Regulaがセキュリティ上の脆弱性を検出してCIビルドを失敗させる様子と、違反を修正してビルドを成功させる方法を見ていきましょう。

設定が完了すると、CI/CDパイプラインは次のように動作します。

1. IaCをブランチにコミットします（ここでは説明を簡潔にするためmainブランチにコミットしますが、プルリクエスト向けに実行し、カスタマイズすることもできます）。

2. コミットをプッシュすると、Bitbucket Pipelinesのビルドが開始されます。

3. Bitbucket Pipelinesがリポジトリに対してRegulaを実行します（ここではベストプラクティスを示すため、Terraformのフォーマットと検証のチェックも含めています）。

4. リポジトリ内のIaCがRegulaのすべてのチェックに合格すると、Bitbucket Pipelinesのビルドも成功します。合格しなければ、ビルドは失敗します。

ヒント：CI/CDツールによって手順は異なりますが、上記の流れに沿って、Regulaを使ったCI/CDでのIaCチェックを実施できます。

前提条件

手順を進めるには、次のものが必要です。

• Bitbucketアカウント（Bitbucket cloudまたはBitbucket Serverのアカウント）

• Bitbucketアカウントで多要素認証を有効にしていること

• クラウドプロバイダーのアカウントと認証情報を、Bitbucketのリポジトリ変数として登録していること（この例ではAWSを使用します）

• Terraformで定義したクラウドリソースを含むBitbucketリポジトリ（ローカルにクローン済み）（リポジトリの構成は以下を参照）

リポジトリの内容

上の図は、リポジトリのファイル構成を示しています。主なファイルは次のとおりです。

• main.tf：プロバイダーとアカウント情報を定義するTerraformファイル

• ec2/instance.tf：意図的に脆弱性を含めたTerraformファイル

• .regula.yaml：このリポジトリでRegulaをどのように実行するかを定義する設定ファイル

• bitbucket-pipelines.yml：Bitbucket Pipelinesの設定ファイル

Bitbucket Pipelinesの設定

ここから、リポジトリのビルドを実行するようBitbucket Pipelinesを設定します。Bitbucketリポジトリのページ左側にある「Repository Settings」をクリックします。次に、左側に表示されたメニューを下までスクロールし、「Pipelines」セクションの「Settings」をクリックします。「Enable Pipelines」の横にあるスライダーをクリックして、緑色の背景に白いチェックマークが表示された状態にします。

ファイルの内容

まず、リポジトリ内の各ファイルを確認しましょう。最初はec2/instance.tfです。

脆弱性を含むTerraformコード

ec2/instance.tfのTerraform HashiCorp Configuration Language（HCL）ファイルでは、次のAWSリソースを定義しています。

• Elastic Compute Cloud（EC2）インスタンス

• 上記のEC2インスタンスへのアクセスに使用するIdentity and Access Management（IAM）ロール

Regulaのシンプルさと威力を示すため、EC2インスタンスには意図的にセキュリティ上の脆弱性を含めています（修正方法を示すヒントもコメントで記載しています）。このTerraformコードは、セキュリティ違反を修正せずにAWSにデプロイしないでください。脆弱性を詳しく見ていきましょう。

resource "aws_instance" "app_server18391111" {
    ami           = "ami-074cce78125f09d61"
    instance_type = "t2.micro"

    # Un-comment below to satisfy FG_R00253
    #iam_instance_profile = aws_iam_instance_profile.test_profile.name

    # Make the below declaration = false to satisfy FG_R00271
    associate_public_ip_address = true

    tags = {
        Name = "ExampleAppServerInstance18391111"
        Team = "dev"
    }
}

• 9行目（現在はコメントアウトされています）には、EC2インスタンスとIAMロールおよびインスタンスプロファイルとの関連付けが記述されています。IAMアクセスキーの代わりに、これらを使ってインスタンスにアクセスするべきです。起動時にEC2インスタンスへロール情報を渡すと、アクセスキーが漏えいするリスクを抑え、悪意のあるユーザーによるインスタンスの侵害を防ぐのに役立ちます

• 12行目では、EC2インスタンスにパブリックIPアドレスを割り当てるよう指定しています。ネットワークアクセスコントロールリストやセキュリティグループが設定されていても、不正なユーザーがEC2インスタンスにアクセスできる可能性があります

このままEC2インスタンスを本番環境にデプロイすると、悪意のある攻撃者にさらされることになります。脆弱性の存在に気づくずっと前に、自動化ツールで検出され、悪用されるおそれがあります。幸い、RegulaにはIaCをスキャンし、Center for Internet Security（CIS）ベンチマーク違反を検出するための数百ものルールが含まれています。

Bitbucket Pipelinesの設定

bitbucket-pipelines.ymlファイルによって、ビルド開始時にBitbucket Pipelinesが何を実行するのかが決まります。まず、Bitbucketにパイプラインであること、そしてデフォルトのパイプラインであることを知らせます（プルリクエスト用や、リポジトリのブランチ別など、別のパイプラインも作成できます）。

pipelines:
 default:

ここでは、次のステップを順番に実行するようにしていますが、ステップの左側の列にparallelコマンドを追加すれば、並列実行もできます。

次に最初のステップを定義します。HashiCorp Terraformイメージを使ってTerraformを初期化し、HCLの標準形式に合わせてフォーマットを調整し、Terraformの妥当性を確認します（変数やモジュールがすべて定義されているかなど）。

- step:
    name: 1 - Initialize, Format, and Validate Terraform
    image: hashicorp/terraform
    script:
        - terraform init && terraform fmt
        - terraform validate

パイプラインの2つ目のステップではRegulaを活用します。リポジトリのルートディレクトリや子ディレクトリにあるIaCファイル（Terraform、CloudFormation、Azure Resource Manager、Kubernetesマニフェスト）を自動検出し、検出したすべてのファイルをCISベンチマーク基準に照らしてスキャンします（Fugueは、SOC 2、HIPAA、NIST 800-53など、その他のコンプライアンス基準にも標準で対応しています）。

- step:
    name: 2 - Scan Terraform Locally for Security and Compliance with CIS Benchmarks
    image: fugue/regula
    script:
        # Run in root directory first
        - regula run ./
        # Run in child directories next
        - regula run ./*/

最後のステップではTerraformを再初期化し、再びHashiCorp Terraformイメージを使用します。Bitbucketパイプラインの各ステップは別々のDockerコンテナで実行されるため、宣言した依存関係はステップ間で引き継がれないからです。最後に、Terraformのプランを作成して適用します。

- step:
    name: 3 - Plan and Apply Secure, Valid Terraform
    image: hashicorp/terraform
    deployment: Production
    trigger: manual
    script:
        - terraform init
        - terraform plan
        - terraform apply -auto-approve

ビルドを開始する

ビルドを試す（そして失敗させる）— IaCファイルを含むリポジトリの編集が終わったら、まずターミナルで次のコマンドを実行します。

git add 
git commit -m "initiating the bitbucket pipeline"
git push

新しいコミットをリポジトリで検出すると（または手動で指示すると）、Bitbucket Pipelinesは上記の.ymlファイルで定義したパイプラインを実行します。CISベンチマークに違反するTerraformをリポジトリのmainブランチにコミットすると、次のようになります。

Regulaで設定の問題を解決する

Terraformファイルに設定ミスがあることが分かったので、リポジトリに戻り、Regulaをローカルで実行して問題を修正できます。このリポジトリでは、コメントアウトしたTerraformの修正コードを簡単に有効化できるようにしています。ただし、インフラを適切に設定するのは、regulaの実行後に各ルール違反とともに表示されるFugueルールの修正ドキュメントへのリンクをクリックするだけで簡単です。以下では、FugueルールFG_R00253とFG_R00271を修正し、最後にregulaを実行してインフラを再チェックした様子を紹介します。

ビルドを試す（今度は成功！）

インフラを適切に設定できたので、リポジトリ用に設定したBitbucket Pipelineによる自動化を最大限に活用するため、Bitbucketリポジトリに再びコミットします。

最初に実行したコマンドをもう一度実行します…

git add 
git commit -m "initiating the bitbucket pipeline"
git push

…すると、ビルドが成功します。

これで完了です。Terraformを使ったクラウドインフラの安全なデプロイを自動化する、RegulaとBitbucket Pipelineの環境が整いました。

Regulaをローカルで実行する

ありがたいことに、Bitbucket Pipelines（やその他のCI/CDツール）がエラーを検出するまで待つ必要はありません。変更をコミットしてプッシュする前に、Regulaをローカルで実行できます。実際、そうすることをおすすめします。特におすすめなのがRegulaのpre-commitフックです。開発者がコードをコミットする前にセキュリティ違反やコンプライアンス違反を修正するよう強制し、多層防御を実現します。開発サイクルの早い段階で問題を検出することで、セキュリティを「左にシフト」でき、開発を加速させるとともに、後になって発生する時間やコストの浪費、ストレスを回避できます。

まず、Regulaをローカルにインストールします。Regulaは単独で動作するバイナリなので、前提ソフトウェアをインストールする必要はありません。お使いのOSに応じて、ドキュメントの手順に従ってください。

次に、リポジトリのルートディレクトリから、Bitbucket Pipelinesで実行されるものと同じコマンドを実行します。

regula run

Bitbucket Pipelinesのログと同じ出力が表示されますが、ローカルで実行すればビルド時間を消費せずに済みます。また、セキュリティチームの責任を開発者レベルに分散することで、デプロイ前のセキュリティ起因のボトルネックを減らし、あるいは完全になくすことができます。

次のステップ

Regulaについて詳しく知りたい方は、GitHubリポジトリとドキュメントをご覧ください。Regulaは、Terraform HCL、TerraformプランJSON、CloudFormation YAML/JSON、Kubernetes YAMLマニフェスト、Azure Resource Managerテンプレートを評価し、セキュリティとコンプライアンスをチェックします。免除設定やカスタムルール、ルールの有効化・無効化などにも対応しています。

クラウドインフラの安全なデプロイを自動化する別の方法に興味がありますか？RegulaとTravis CIの統合に関するブログ記事をご覧ください。