OpenTofuの「ブロック削除機能」「stateファイル暗号化」はなぜ注目されているのか：HashiCorpやコミュニティーとの関係に深く影響

TechTargetは「OpenTofu 1.7β版」に関する記事を公開した。同バージョンではTerraformのコミュニティーが長い間求めていたブロック削除機能とクライアント側の状態（state）ファイルの暗号化がサポートされている。

[Beth Pariseau，TechTarget]

　TechTargetは2024年4月19日（米国時間）、「OpenTofu 1.7β版」に関する記事を公開した。

OpenTofuはHashiCorpの怒りを買ったβ機能で前進（提供：TechTarget）

　「OpenTofu」はHashiCorpの「Terraform」をフォーク（派生）させて開発されたオープンソースのIaC（Infrastructure as Code）だ。

　TechTargetのベス・パリソー氏（シニアニュースライター）は「OpenTofuの最新β版（1.7）は、2つの点でTerraformのオリジナル作成者に反抗している」と指摘。それは、HashiCorpが違法にコピーしたと非難している機能を保持していることと、Terraformコミュニティーで話題となっている機能をTerraformよりも先に実装したことだ。

TerraformとOpenTofuを巡る騒動

　もともとTerraformはオープンソースのライセンスで開発されていた。だが、2023年8月にHashiCorpは「オープンソースコードを基に製品を開発しながら、オープンソースに貢献しない企業による不公平な競争が行われてること」を理由に、Terraformを商用ライセンスであるビジネスソースライセンス（BSL）に変更した。

　その後の論争を経て、HashiCorpの競合他社とオープンソースコミュニティーに所属する企業から構成されたコンソーシアムはTerraformのフォーク、つまりOpenTofuを立ち上げた。このプロジェクトはThe Linux Foundationに承認され、2024年1月にはバージョン1.6がリリースされている。

　一方のHashiCorpは、2023年11月に、BSLに基づく新しいTerraformのコードを公開した。このコードでは、ユーザーがTerraformの状態ファイルに保存されているインフラストラクチャリソースを永久に破壊することなく、Terraform構成コードをリファクタリングできるようにプロセスが改良されている。

　HashiCorpのブログによると、この改修は「バージョン1.8でTerraformのデプロイを『新しく、より速く、よりミスの少ない方法』にするために再設計されたプロセスの一部だ」という。これらの機能は“removedブロック”というTerraformコードの新しいブロック（コード内でリソースやモジュールの定義を囲むための要素）を基にしている。

　問題になったのはこの「removedブロックのサポート」を提案するプルリクエスト（Pull Request）がOpenTofuのリポジトリに投稿され、2024年3月のOpenTofuバージョン1.7リリースでその仕組みが実装されたことだ。HashiCorpは「BSL適用後のコードをOpenTofuが不正にコピーしている（BSL規約に違反している）」と主張し、弁護士を通じてOpenTofuに停止命令書を送った。

　OpenTofu側の企業は2024年4月11日にこれらの主張に対し、ソースコードを行単位で分析した結果と合わせ、「removedブロックはBSLバージョンのものではなく、オープンソースバージョンのTerraformに基づいて開発されたものだ」と公式に反論。また、2024年4月3日には業界紙に「OpenTofuがBSLコードをコピーした」という第三者の主張が掲載されたが、こちらの主張はその後、編集者のメモで更新されている。現在は「事実ではなかったようだ」とされ、主張を記事にした著者もソーシャルメディアでこれを否認している。

　OpenTofuのコアメンバーで、Scalrの創設者兼CEOのセバスチャン・スタディル氏は「TerraformとOpenTofuの“removedブロック”に関する機能は、ユーザー観点では同じ目標（リソースを削除せずにコードをリファクタリングする）を達成するためのものだが、そこに至る前の道筋が異なっている」とTechTargetの取材で答えている。

　「私たちはコミュニティーのフィードバックとニーズに基づいて機能の優先順位を決める。幾つかの機能はTerraformが提供するものと似ているが、OpenTofuユーザー専用のものもある」（スタディル氏）

　同氏によると、OpenTofu側から公式に反論した後はHashiCorpから連絡はないという。また、TechTargetからもHashiCorpへのコメントを求めたが、記事執筆時点では回答がなかった。2024年4月現在、OpenTofu側は、デジタルミレニアム著作権法に基づいてHashiCorpからGitHubに送られた「OpenTofuリポジトリに関する削除通知」に対応中だ。

OpenTofu バージョン1.7がstate暗号化の挑戦状をたたきつける

　スタディル氏によると、OpenTofu バージョン1.7には、OpenTofuだけがサポートする（Terraformはサポートしていない）、「主力機能」が含まれているという。同氏は「無料かつオープンソースで優れた機能を使える」とOpenTofuの優位性を訴える。

　クライアント側のstate（Terraformが構成をインフラストラクチャのリソースにマッピングし、メタデータを追跡するために使用するファイルのセット）の暗号化は、2016年からTerraformコミュニティーのメンバーから要求されていた。だが、HashiCorpのプロジェクトには組み込まれていなかった。Terraformで暗号化を利用するには、stateファイルが「Terraform Cloud」やクラウドベンダーのクラウドバックエンドでリモートホストされている必要がある。

　ただし、HashiCorpのドキュメントでは、stateの暗号化は明示的に推奨されていない。

　同ドキュメントによるとTerraformによる暗号化についてある実験をしたところ、課題が見つかったという。実験ではユーザーにPGP（Pretty Good Privacy）キーと暗号文を提供してもらい、それをプロバイダーキーで復号し、stateには暗号文のみ保存した。すると、PGPキーで暗号化された値は信頼性のある方法では補間できなかったという。

　HashiCorpのドキュメントには、この実験結果について「現時点のTerraformはPGPキーが欠落していると優れたユーザーエクスペリエンスを提供できず、Terraform 0.12以降のプロトコル要件に違反しないようにするには、このアプローチに大幅な変更を加える必要がある」と記載されている。

　こうした背景もあり、Terraformにおいてローカル（クライアント側）に保存されたstateは暗号化されていない。Terraformのドキュメントによるとこうした仕様は「『terraform apply』を実行する全てのマシンにTerraformのstateをクリアテキスト（平文）で保存する必要があった時代に合わせて調整された」という。しかし、リモートステッドバックエンド（Terraformのstateファイルをリモートで管理する仕組み）が導入されたため、この説明は現在当てはまらない。

　ただこの仕様は、より高度なセキュリティを求めるユーザーからは「追加で使える保護レイヤー」として好まれている。クラウドベンダーのクラウドバックエンドでstateを暗号化している場合、ユーザーはstateストアへのアクセスとTerraformクライアントへのアクセスを分離したり、stateストア内の特定のファイルを選択して暗号化したりすることはできないからだ。

　スタディル氏は「これらは『自分で暗号化してから誰か（クラウドベンダーなど）に保管してもらうか』『平文のまま誰かに渡して暗号化と保管を任せるか』の違いだ。前者の場合、暗号化されていないデータを自分以外は見ることができないが、後者であれば暗号化されていないデータは（渡された誰かが）参照できる可能性がある」と説明している。

state暗号化の長所と短所

　TerraformとOpenTofuのコミュニティーにおいて、state暗号化に関するさまざまな議論が交わされている。そこで懸念に挙がるのは、ユーザーがクライアント側の暗号化キーへのアクセスを失った場合に、Terraformのstateへもアクセスできなくなることだ。OpenTofu側は「OpenTofuは復号のためのフォールバック設定をユーザーが指定できるようすることでリスクを回避できる。一部のユーザーはキー紛失によるリスクを過大評価しており、クライアント側での暗号化の潜在的なメリットが無視されている」と主張している。

　かつてTerraformコミュニティーに貢献し、『Terraform in Depth』の著者でもあるロバート・ハフナー氏は「OpenTofuが提供するstate暗号化は、個々の値だけでなく状態ファイル全体が暗号化されるため、プロバイダーに依存しないというメリットがある。HashiCorpが同じ機能を提供しないのは技術的な懸念があるからではなく、ビジネス上の理由でコミュニティーを無視しているように感じる」と述べている。

　OpenTofuのstate暗号化は提供されてから日が浅いものの、コミュニティー版のTerraformを使い続けるつもりのITエンジニアからは注目を集めている。

　ウィリアム・アンド・メアリー大学のフィル・フェンスターマッハー氏（システム設計、アーキテクチャマネジャー）は、「われわれはTerraformのstateファイルの管理にGitLab（セルフホスト版）を使っている。GitLabを使うことで、stateを管理しているデータ保存領域の設定や、セキュリティアクセス、暗号化が可能になる。しかし、もし誰かがバックエンドのファイルにアクセスできた場合、その内容を平文で読むことができてしまうという課題があるため、ファイル内の機密データをクライアント側で暗号化したいと考えている。それができれば、プロジェクトごとに異なる暗号化キーを設定できるからだ」と述べている。