CNSC 2022からTerraformによるクレデンシャル管理の現実的な解の解説

CloudNative Security Conference 2022から、アクセンチュアのエンジニアが解説するインフラストラクチャー構築のためのツール、Terraformにおけるクレデンシャル管理に特化したセッションを紹介する。セッションを担当したのはアクセンチュアの崎原晴香氏だ。2021年に新卒でアクセンチュアに入社したというエンジニアでクラウド環境、特にAWSをメインにクラウドインフラストラクチャー構築に携わっているという。

「セキュアなTerraformの使い方」というタイトルのセッション

「機密情報をコードに含めず環境構築するにはどうしたらいいの？」というサブタイトルが示すように、サーバーやデータベースのインスタンスをクラウド上に構築する際にどうしても考慮しなければならないのが、ユーザーIDやパスワードなどのクレデンシャルの扱い方だ。実際にありそうな使い方からTerraformの内部の動きなどを解説することで、パスワードが平文で書き残されてしまう状況を解説した上で、AWSの場合に限定されるものの、現実的な解決策を提案する内容となっている。

動画：セキュアなTerraformの使い方 ～ 機密情報をコードに含めず環境構築するにはどうしたらいいの？

Terraformとは？

TerraformはHashiCorpが開発するオープンソースの構成管理ツールだ。宣言的な構文でインフラストラクチャーとして必要なリソース、例えばサーバーやデータベースなどを定義することで起動や停止、削除などを行う。Infrastructure as Code（IaC）の代表的なツールと言えるだろう。

Terraformの動作を解説

このスライドではTerraformがHCL（HashiCorp Configuration Language）で書かれた定義ファイルを読み込んで検証し、実行するまでを解説している。

ここからインフラストラクチャーをコードで構築管理、実行することの利点を解説。具体例として再構築が可能であること、自動化、変更履歴の管理が容易であることなどを挙げている。

IaCのメリット

その上でコード上でクレデンシャルを扱う上で気をつけるべき点を紹介した。ここではクレデンシャルがコードの上で平文で残され、それが履歴という形でも残ってしまうことを説明した。

クレデンシャルがコードの上に残ってしまうことに気をつけるべき

ここからTerraformで起こり得るクレデンシャルをコードに含めてしまうケースを列挙して解説。

Terraformでクレデンシャルを扱うケースの解説

インフラストラクチャー構成に関する情報をGitで管理している場合などに「構成情報の主な部分はGit内で管理、クレデンシャルに関わる部分だけを外に出して管理すれば良いかも」と考えることはあり得るが、実際にはこれも良くないと説明。

Gitの中にクレデンシャルを残さない方法も良くない

この方式であっても実際にはクレデンシャルが平文でtfstateファイルに残ってしまうことを説明。ここで、Terraformには構成情報を定義するtfファイルと構成の状態を維持するtfstateファイルが存在することを解説。内部の動作を詳しく見ていくことでクレデンシャルがどのように保存されるのかを説明した。

tfファイルとtfstateファイルとは

HCLで書かれた構成情報をtfファイルとしてTerraformに与えると、tfstateファイルに示されたシステムの状態とtfファイルの情報を比較して違いを検出し、その違いを実際のインフラストラクチャーに反映するというのが動作原理だ。

Applyコマンドで構成ファイルの内容がシステムに反映される

結果としてtfstateファイルと実際のシステム構成は同じになる原理

しかしtfstateファイルを個人で利用するのではなく企業システムの開発のように複数の人間がインフラストラクチャーを利用する場合には問題も多いと説明。ここでは同じAWSの環境に対して複数のエンジニアが構成を変更する場合に言及して、ローカルにtfstateファイルが保存されてしまう状態では問題が発生してしまう例を紹介した。

複数のユーザーが変更を加えるケースでは問題が発生する

対応策としてtfstateファイルを共有するためにS3に保存して使うというパターンもあり得るが、その場合でも排他制御ができないため、問題が発生してしまうことを説明。

S3で共有しても問題が発生する

TerraformのDataSourceを使っても最終的にtfstateファイルには平文でクレデンシャルが保存されてしまうことを再度強調して、この発想では上手くいかないことを説明した。

共存案を考えてみたが、やはり限界がある

このスライドでは3つのパターンで検討してみたが、どれも上手くいかないことを解説した。

リソース名を変更する際にmvコマンドを使う方法なども解説しながら、どのパターンも限界があるとした。

「そもそもtfstateファイルにクレデンシャルを載せてはいけない」

またクレデンシャルがtfファイルに含まれるかどうかをチェックするためにはAqua Securityのtfsecを使うことを推奨。

tfファイルにクレデンシャルが入っているかをチェックするツールを紹介

ここから解決策として、クレデンシャルが必要なパターンを2つに分けて解説を行った。AWSのデータベースでクレデンシャルが要求されるリソースはRDS、DocumentDBそしてRedShiftの3つしかないことを説明。

AWSでクレデンシャルが必要なリソースについて解説

ここからはパスワードローテーションを行うメカニズムについて解説を行った。パスワードローテーションでパスワードの寿命を短くすることで、クレデンシャルの管理が効果的に行えることを解説した。

Secrets Managerを使ってパスワードローテーションを説明

同時にTerraformがパスワード変更を修正とみなして差分検知されないようにする方法を説明。

そもそもタイプの違うリソースに対して、同じようなアプローチでクレデンシャル管理をTerraformに任せる必要があるのかを再考するべきだと強調した。

もう一度、リソースの特性に合わせてクレデンシャル管理を考えるべき

最後にまとめとして、Terraformの実行原理としてtfstateファイルにクレデンシャルをはじめとしてすべての構成情報が書かれてしまうことを説明。HashiCorpが勧める「tfstateファイルに機密情報が書き込まれることを許容した上でtfstateファイルをセキュアに扱う」という発想は間違っていると強く訴えた。そして変更が頻繁に必要となるリソースについてはパスワードローテーションを使うこと、ローテーションが不要なリソースについてはCLIや手動で実行することが現実的と総括してセッションを終えた。

全体としてAWSを使っているエンジニアとしての経験（汗と涙？）が活かされたセッションとなったが、多分にAWSに特化した内容となっていること、HashiCorpにはクレデンシャル管理のツールであるVaultがオープンソース版もエンタープライズ版も存在していることに特に言及されていないのが不思議ではある。どうしてVaultに言及していないのかについては崎原氏に質問を送ったところ、「AWSでのシステム構築が主な経験」であり、「今回は時間が限られていたから」Vaultには言及しなかったという回答を得た。

ちなみにTerraformとVaultの連携については以下のブログが参考になるだろう。

参考：Vaultの動的シークレットでTerraformのセキュリティレベルを向上させるには