[和訳] InSpecへの道 #getchef

本稿は The Road to InSpec (2015/11/04) の和訳です。

当社は火曜日、Chef Compliance のリリースの一環として、InSpec infrastructure testing framework のリリースを発表しました。今日は Serverspec 拡張が現在のスタンドアロン・プロジェクトに至るまで、我々がどのようにそしてなぜ InSpec をクリエイトすることにしたのかを掘り下げたいと思います。

コンプライアンステストのための Serverspec

今年初旬に Chef 社が買収したスタートアップ企業 VulcanoSec 社は、ある問題を解決するためのものでした――我々はどうすれば DevOps の最優良事例をコンプライアンスの世界にもたらすことが出来るのか。我々はすでに DevOps の世界に深く根付いており、インフラ管理に持ち込むという大転換も経験しました。我々はそれと同様の利点とワークフローをセキュリティとコンプライアンスの領域にももたらしたいと考えていました。

コンプライアンスをチェックするための既存のソリューションは、大きく分けて２つの領域に分類することができます: 静的解析と動的スクリプトベースのツールです。最初は多くの場合、期待値と結果が示される場 (例えば、XML) が移植性の高いシンタックスに付随してきます。これは移植性には有効ですが、たいてい柔軟性には欠けています。なぜならこれらのドキュメントには大々的に修正されたスキーマがあるからです。一方でスクリプト・ドリブン・ソリューションはユーザにテストを自由に定義させることで逆方向からの問題に対処します。ただ、それはより高度な複雑さと保持性を生む代償を支払うことになります。我々は最終的に革新的でありながらカスタマイズが容易で、軽量構造のコンプライアンスチェックを供給することができる何かを必要としていました。

我々は、通常はセキュリティ・アサーションの根源であるインフラ・テストを受容した Serverspec プロジェクトに感銘を受けました。Serverspec はインフラ・テスト用の記述的言語を作るために Ruby と RSpec を採用しました。Serverspec は静的な期待 (例えばリソース X が Y 状態になるという期待) とプログラムの柔軟性をバランス良く提供します。

Serverspec の核心部分においては、我々はただコンプライアンスに必要なものを作らなければなりませんでした。我々はテストがコンプライアンス・プロフィールにグループ化されるコントロール・コレクションだと表現したかったのです。これらは容易にシェアや拡張が可能でなければならず、一つのプロジェクトが次につながるのに単純な調整で済むメカニズムを提供する必要があったのです。テストの意味を説明するのに役立つ記述的メタデータと同様にクリティカリティを追加し（そうすればトラック一台分の失敗が見つかったときに最初に何を注視すべきか分かる）我々はテストがより記述的であることを望みました。

VulcanoSec の初期に我々が作成したソリューションは、DevOps に対して卓越したスタックを持っていました。表現力豊かな Ruby ドリブンのコア機能、Serverspec によって作り上げられた構造、至るところに加えられたコンプライアンスです。

現場からの学び、または InSpec への進化

コアフレームワークが準備できたので、我々はそれをコンプライアンスとセキュリティ監査の担当者の手に委ねました。最初のきっかけはしばしば DevOps の世界についての好奇心であり、それに引き続き Ruby との密着合に対する懸念、そして最後はいかにこれが日常業務やコンプライアンス維持の改善につながる可能性を持ち合わせているかということに対する大きな期待でした。

スマート・リソース

テストユーザーの手に渡ることで、我々は彼らのドメインに近づく方法を大いに学ぶことになりました。我々は自分たちの考え方を変えなくてはならないこと、監査役が実際に何を望み、一体何ができるのかについて注力しなければならないことに気づきました。そして、彼らは確実に、実際のテストのように莫大なチェック用のコードを書くことを望んでいませんでした。


if os