Terraform Cloud Business の紹介と解決できる課題

当記事はみずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画で執筆されたものです。

みずほリサーチ＆テクノロジーズ株式会社の浅香です。

G-gen さんとのコラボ企画のもと、弊社エンジニアによる Google Cloud の記事を執筆する機会を頂戴しました。

他の方々が先行して Google Cloud に関する各種記事を投稿していますので、本記事では少し趣向を変えてみて Google Cloud と関わりが深い Terraform について、その中でも特に Terraform Cloud Business をご紹介させていただきます。

Terraformについて
Terraform OSS の利用イメージ
Terraform OSS を利用している場合の課題
Terraform Cloud Business の利用イメージと課題への対応
Terraform Cloud Business とプロビジョニング先の通信
まとめ

Terraformについて

Terraform とは

Terraform とは、 IaC ( Infrastructure as Code ) ツールの一種です。

HashiCorp 社によって開発され、オープンソースソフトウェアとして開発され続けています。

Terraform の特徴

Terraform は、各種パブリッククラウド / SaaS 製品に対応しています。

どのプラットフォームであっても統一された構文で IaC 化を実現することが可能で、各プラットフォームごとの IaC ツール / サービスを使うための学習コストを削減することができます。

ご参考までに、メジャーなパブリッククラウドでは、それぞれの IaC ツール / サービスが提供されていますが、このいずれのパブリッククラウドも Terraform は対応しています。

プラットフォーム	IaC ツール / サービス
AWS	AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) など
Microsoft Azure	Azure Resource Manager (ARM) など
Google Cloud	Cloud Development Manager

Terraform の種類

Terraform は大きく分けて 3 種類あります。

Terraform OSS

名前の通り、 OSS として提供されている形態です。
Terraform Enterprise

商用版の Terraform で、自ホストにインストールして利用する形態です。
Terraform Cloud

名前から想像できるかもしれませんが、 Cloud として提供されている形態です。

HashiCorp 社が運用する Terraform のマネージドサービスです。

Terraform Cloud Business とは

上述した Terraform Cloud の中にもいくつかのプランがあります。プランごとに料金はもちろん、利用できる機能やサポートが異なります。（詳細はリンク先をご参照ださい。）

Terraform Cloud Business はその中の 1 つのプランです。後述していますが、様々な機能が利用可能となっています。

本記事では、この Terraform Cloud Business について、Terraform OSS との比較を交えてご紹介していきます。

Terraform OSS の利用イメージ

まずは Terraform OSS をそのまま利用した場合の利用イメージを共有したいと思います。

担当者Aさんが、Terraform のコードを書いて、必要な変数やシークレットを用意して、Plan を実行し確認して… 次に承認を得るために、コードと Plan 結果を添えて、管理者に承認依頼をして…

管理者さんは、メールをもとに内容を確認しますが、機械的なではなく人間の目によるチェックを実施し… 問題があれば差戻をし、問題なければ添付ファイルもとに Apply を CLI で実行し…

比較のためにもあえて、シンプルな利用イメージとしてますが、IaC としてコード化しているにも関わらず、実行に至るまでのプロセスは手動となっており、その分ヒューマンエラーの可能性も大きくなってしまいます。

また、今回は登場人物は 2 人だけ、かつ、やりとりするコードも少数のイメージになっていますが、実際はこれが複数かつ並列に走っていくことになり、より複雑になっていきます。

Terraform OSS を利用している場合の課題

上述のフローをもとにした際に生じる課題を挙げてみます。

人的なRV依頼 / 実施

メールを介したレビュー依頼や、人の目によるチェックなどは、どうしてもヒューマンエラーが生じてしまいます。
コード / シークレットの管理（バージョン管理や自動化）

バージョン管理をしないと事故のもとになります。ただ一方で、シークレットは平文管理は望ましくないです。
操作ログや監査、変更の通知など

有事に備える意味でも、いつ、誰が、何をしたのかは把握が必要です。
CLI による操作/管理

CLI でも操作は可能ですが、視覚的には見づらくなってしまいます。GUI で直観的に情報に辿りつける方が優しいです。
ステートファイルの管理

Terraform を使う以上、ステートファイル ( tfstate ) の管理は必須です。不用意に変更できないように管理する必要があります。
Terraform外の変更管理

急ぎの対応などは、リソースを直接修正してしまいがちですが、そうすると Terraform との差分が出てきてしまいます。忘れることなくて追い付きの Terraform 修正を抜け漏れなく対応できればいいですが…

Terraform Cloud Business の利用イメージと課題への対応

上述の課題を踏まえて、Terraform Cloud Business を利用した場合に置き換えてみます。文章での説明の前に、課題の解決案を示したイメージを先に載せてみます。

構成については、先程の OSS 利用時はコンピューターにしていた箇所を VCS ( Version Control System ) に置き換えていますが、OSS で生じていた課題に対して、それぞれ解決策となるTerraform Cloud Businessの機能を示しています。

Terraform Cloud Businessの機能の紹介を兼ねて、先程の課題への解決アプローチを説明していきます。

人的なRV依頼 / 実施への解決アプローチ

Plan と Apply の間に、レビューにあたる各種設定を組み込むことが可能になります。画像の中にも載っていますが、具体的には Cost Estimation、 Sentinel Policy ( Policy as Code )、 Run Tasks を設定することができ、それぞれで各種レビューの役割を果たすことができます。

Cost Estimation

主にIaaSを中心に、Applyを実行して作成されるリソースの月額コストの予想見積を出すことが可能になります。

数が多い、サイズが大きいリソースの作成を意図せず組み込んでしまった際に、実行前に検知することができます。
Sentinel Policy ( Policy as Code )

標準的なセキュリティや社内ルールなどを Policy という形で定義 ( Policy as Code ) することで、それらに準拠しているかを機械的にチェックすることが可能になります。

そのチェック結果に応じて、後続のオペレーションをどうするか（実行中止や警告出力した上で続行など）を設定することもできます。

Policy as Code を実現する手段として、 Hashicorp 社が提供している Sentinel というツールや、Open Policy Agent (OPA) などを適用することができます。 Sentinel であれば、Cost Estimation のあとに実行されるため、コスト次第では実行させないなどの制御も可能です。
Run Tasks

サードパーティーツールとの連携に加え、自前のツールによるチェックを組み込むことが可能になります。上記の機能で補完できない部分を自作して使う方法などが考えられます。

コード / シークレットの管理（バージョン管理や自動化）への解決アプローチ

各種 VCS と連携することで、VCS 側のイベントを契機に Terraform を実行することが可能になります。 Pull Request を契機に Plan の自動実行、merge を契機に Apply を自動実行などができます。コードの作成 -> Pull Request -> ( Plan ) -> レビュー -> merge -> ( Apply ) を一連で行うことができ、コードの変更履歴やレビュー指摘などを VCS 側に記録できます。後述しますが、Terraform での実行履歴を GUI を介して確認することも可能です。

なお、連携できるVCSはリンク先をご確認ください。

また、必要なクレデンシャル情報や環境変数などの Variable を Terraform Cloud 内に保存することができ、コードとして管理する必要がなくなります。誤ってクレデンシャル情報を VCS に平文で格納してしまうなどの事故を防止します。

なお、保存された情報は Terraform Cloud 内で暗号化されるため、セキュリティも確保されています。暗号化対象や暗号化方法はリンク先をご確認ください。

操作ログや監査、変更の通知などへの解決アプローチ

各種APIを用いて、ログや監査証跡を取得することが可能になります。

Audit Trails APIを用いると、監査証跡として、いつ・誰が・何をしたかなどの情報を取得することができます。監査証跡は Splunk と統合することもでき、定期的に Splunk に取り込まれ、可視化できます。

また、Terraform の各種イベントを契機にして、通知を発信することもできます。 Email / Slack / Microsoft Teams などは設定のみで通知可能となっていますし、Webhook にも対応しているため、それら以外の柔軟な対応も可能です。

CLI による操作/管理への解決アプローチ

Web UI が提供されおり、各種設定や情報の参照が視覚的にわかりやすくなります。ワークスペースごとの Plan や Apply などの Terraform の実行履歴なども一覧で見ることができます。例えば、実行状態の確認をしたい場合を考えると、CLI だとコマンドを確認する必要がありますが、GUI であればクリックしてアクセスするのみになります。 Terraform の CLI に慣れている人であれば、大きな違いはないかもしれませんが、慣れていない人や初学者にとっては、技術的にも心理的にもハードルが大きく下がります。

また、ユーザー認証を SSO を利用して行うことができます。対応している連携先は、MS Azure AD / Okta / SAML があり、既存で利用しているものがあればそれを流用し ID 管理やガバナンスを実現できます。それに加え、Teams 管理機能を用いて権限管理（認可）を設定できます。ユーザーは Team に所属する必要があり、その Team 単位に実行権限やアクセスできるワークスペースの設定などができ、適切なアクセス管理を実現できます。

ステートファイルの管理への解決アプローチ

文字通りになりますが、ステートファイル ( tfstate ) の管理をマネージド化し、 Terraform Cloud 上での管理にできます。これによりローカル環境に保存していた場合の共有管理や排他制御の必要性がなくなります。（必要性自体は変わっていませんが、その部分の管理を利用者側でする必要がなくなります）

ステートファイルには、コードによっては DB の管理パスワードなど機密情報が含まれる場合があり、暗号化やアクセス制御も重要になります。 Terraform Cloud上での管理にすれば、暗号化の実施やアクセス制限、監査証跡から追跡することが可能になり、より厳格な管理が可能になります。

Terraform外の変更管理への解決アプローチ

ドリフト検出機能 ( Drift Detection ) を利用することで、Terraform 外からの変更を監視 / 検出することが可能になります。利用者側でスケジュール定義はできませんが、24時間ごとに実行され継続的なドリフト検出ができ、ドリフト検出をした際には、上述の通知機能により通知することも可能です。

実際にドリフトを検出をした場合には、そのドリフトへの対応が必要になりますが、以下の 2 つの選択肢があります。

ドリフト検出の変更結果を受け入れる

変更内容（実リソースの内容）を正として、ステートファイルを更新します。 Refresh State にて実行することでステートファイルを、実リソースに合わせることができます。ただし、実際のコード ( tfファイル ) までは修正されないため、そこは手動で修正する必要があります。
ドリフト検出の変更結果を受け入れない

実際のコード ( tfファイル ) を正とします。既存のコードを用いて改めてApplyすることで、実リソースが更新され、あるべき姿の状態になります。

Terraform Cloud Business とプロビジョニング先の通信

上述の通り Terraform Cloud Business を用いると、Terraform OSS で抱えていた課題を解決してくことができます。一方で、Terraform を Cloud 環境に移行することにより、Terraform OSS にはなかった通信経路も必要になります。

Plan や Apply 、ドリフト検出等により、Terraform Cloud からプロビジョニング先に対してアクセスが発生します。その際のアクセスイメージは以下の通りです。

プロビジョニング先から見ると、Terraform Cloud 側の IP アドレスから各種APIを実行されていることになります。プロビジョニング先の設定によりソース IP アドレス制限などをしている場合は、Terraform Cloud 側の IP アドレスを許可しておく必要があります。

なお、Terraform Cloud 側の IP アドレスは可変となっておりますが、IP Range APIを通して取得することができます。頻繁な更新があるわけではないとドキュメントにも記載はありますが、変更される可能性はあるため考慮する必要があります。

しかし、環境によってはこれらの要件が受け入れがたい場合もあると思います。その場合は、Terraform Cloud Business で利用可能な Terraform Cloud Agent という選択肢があります。その際のアクセスイメージは以下の通りです。

Terraform Cloud Agent を利用すると、Terraform Cloud からのインバウンドアクセスはなくなり、アウトバウンド通信のみにすることができます。プロビジョニング先から見ると、Terraform Cloud Agent の配置先が各種APIの実行元となります。図のように、プロビジョニング先＝ Terraform Cloud Agent の配置先とすれば、内部から API を発行していることになります。これにより IP 制限がかけられている環境であっても、必要最低限の対応で利用することが可能になります。

ただし、Terraform Cloud Agent は VCS とは直接通信することはできません。 VCS 連携する場合は、VCS に対してTerraform Cloud 側の IP アドレスからのアクセスを許可しておく必要があります。特に、VCS をプロビジョニング先やオンプレなどに構築している場合は、VCS に限り Terraform Cloud からのインバウンドアクセスの許可が必須となるのでご注意ください。

まとめ

改めてにはなりますが、本記事では Terraform Cloud Business についてご紹介させて頂きました。今回紹介できた内容は一部に過ぎず、その他にも多種多様な機能が提供されていますし、続々とアップデートされています。直近で発表のあった以下のアップデートなども、個人的には管理面やセキュリティ面で大きなアップデートだと思っています。

これらのアップデートがいち早く享受できることも Cloud 利用の大きなメリットの 1 つですね。今後も注目して行きたいと思います。

最後までご覧いただきありがとうございました。本記事がどなたかの一助となれれば幸いです。