DevOpsDays Tokyo 2021 で Infrastructure as Code のテストについて話してきました
こんにちは、チェシャ猫です。
先日開催された DevOpsDays Tokyo 2021 で Infrastructure as Code のテストについて発表してきました。公募 CFP 枠です。
今回の発表は、昨年の CloudOperatorDays Tokyo 2020 での講演をほぼそのまま再現しています。内容については前回登壇時に詳細な解説記事を書いたので、こちらもご参照ください。
オンサイト登壇
ここしばらく、どのカンファレンスもリモート開催がデフォルトになっていましたが、今回は久しぶりに会場まで行って登壇してきました。最後にオンサイトでプレゼンしたのが 2020 年の 3 月 26 日 なので、実に 1 年ぶりです。
実際には会場で参加していたのはほぼ関係者オンリーで、各ホールに数人ずつといった程度の人数でした。ただ登壇する側としてはマイクを持って物理的に対面して話すのことの効果は大きく、久々に自分の本来のペースが出せたので非常に良かったです。個人的には、他のイベントでもせめて登壇側はオンサイトで話せる仕組みができると良いなと感じます。*1
前回からの差分
昨年 CloudOperatorDays の登壇からやや時間は経っていますが、主たるテーマである「IaC はなぜ辛いのか」「それを解決するために何をテストすべきか」という問題意識は今も変わっていないため、スライドも大部分は前回と同じものを使用しています。
ただし、CloudFormation Guard が 2020 年 10 月に一般利用可能 (GA) になったことを受けて記述をマイナーチェンジしました。前回の時点では開発プレビュー版だったこともあり、cfn-guard コマンドのインストールには Rust のソースコードからのビルドが必要でした。現在はバイナリリリース版が利用可能で、またセキュリティ用の設定が必要であればサンプルファイルも提供されています。
cfn-nag と CloudFormation Guard を比較する上で最も大きな差はルールのカスタマイズ性です。とりあえずセキュリティのベストプラクティスだけでも網羅的に当てておきたければ cfn-nag を、ルール追加やカスタマイズが必要であれば CloudFormation Guard を、という感じになるかなと思います。
なお、CloudFormation Guard は既存の Template からルールを生成する機能を持っていますが、これはあまり期待しない方がよいです。ポリシーとして記述したいであろう内容と、cfn-guard が機械的に検出した条件はニュアンスが一致しないことも多いため、実用に足るポリシーはやはり人間が確認した上で書くことになりそうです。
まとめ
以上、簡単ではありますが DevOpsDays Tokyo 2021 での登壇報告でした。
余談ですが、講演後チャットで GCP + Terraform の場合はどうなるのかという質問を頂きました。AWS CDK の姉妹プロジェクトとして Hashicorp 社によって「Terraform 用の CDK」も開発されています。さらに、今回紹介した Conftest は、HCL や Dockerfile など YAML 以外のファイル形式もサポートしています。
というわけで、今回お話ししたような内容と Terraform との組み合わせもどこかで話せたら面白いかなと思っていますが、それはまた別の話。
*1:ただしその分、今回のように参加費が高くなるのも事実。
