こんにちは。インフラの現場で「IaCの理想と現実」の狭間で戦い続けているエンジニアです。
Terraformを触り始めたばかりの頃、誰もが一度は誘惑に駆られるものがあります。そう、`.tf` ファイルの中に、データベースのパスワードやAPIキーを直接書き込んでしまう「魔の誘惑」です。
はっきり言います。コードへのハードコードは、インフラエンジニアにとっての「時限爆弾」です。
今日は、Terraformを使って機密情報を安全に、かつ美しく管理するための「プロの作法」を伝授します。これをマスターすれば、コードをGitHubにプッシュする際、冷や汗をかく必要はもうありません。
—
1. なぜ「ハードコード」が許されないのか？
Terraformの設計思想の根幹には「状態（State）の可視化」があります。`terraform.tfstate` というファイルには、あなたが構築したインフラの全容が記録されます。ここにパスワードが平文で保存されたらどうなるか？ 想像するだけで恐ろしいですよね。
機密情報は「コード（Git）」とは切り離し、「シークレットストア」に隔離するのが鉄則です。今回は、AWSにおける最強の相棒、AWS Systems Manager (SSM) パラメータストアとの連携を例に解説します。
—
2. 基礎準備：SSMに鍵を預ける
まず、AWSコンソールまたはCLIから、SSMに値を保存しましょう。
データベースのパスワードをセキュアな形式で保存
aws ssm put-parameter \
–name “/production/db/password” \
–value “SuperSecretPassword123!” \
–type “SecureString”
ポイントは `–type “SecureString”` です。これで値がKMSで暗号化され、誰にも中身が見られない状態で保管されます。
—
3. Terraformでの呼び出し：魔法のデータソース
Terraformには、外部の情報を読み取るための `data` ブロックという機能があります。これを使うと、パスワードを直接書かずに、SSMから「参照」する構成が作れます。
実装例：main.tf
SSMから機密情報を取得するデータソース
data “aws_ssm_parameter” “db_password” {
name = “/production/db/password”
}
リソース側では変数として渡す
resource “aws_db_instance” “default” {
allocated_storage = 20
engine = “mysql”
instance_class = “db.t3.micro”
# ここでSSMの値を参照！
# sensitive = true を指定することで、CLI出力でもマスクされる
password = data.aws_ssm_parameter.db_password.value
}
—
4. ここが現場のプロの技：`sensitive = true` の徹底
Terraformには `sensitive = true` という強力なオプションがあります。これを設定すると、`terraform plan` や `apply` の実行時に、コンソール上で値が `(sensitive value)` と表示され、誤って画面共有中にパスワードが晒される事故を防げます。
設計の極意：
常に「出力される変数には `sensitive = true` を付ける」ことを習慣化してください。これは自分を守るための、最も簡単な防衛策です。
—
5. 動作確認：安全を証明する
設定が終わったら、以下のコマンドで確認してみましょう。
実行結果がマスクされているか確認
terraform plan
コンソール上に `password = (sensitive value)` と表示されましたか？ それが成功の証です。もし平文が見えていたら、どこかで設定が漏れています。即座に修正しましょう。
—
まとめ：インフラエンジニアとしての誇り
今回紹介した「SSM + Terraform」の連携は、単なるツールの使い分けではありません。「コードと機密を分離する」という、堅牢なインフラを構築するための思想そのものです。
1. ハードコードは絶対NG：コードはクリーンに保つ。
2. SSM/Secrets Managerを活用：権限管理を中央集権化する。
3. `sensitive`フラグを愛する：運用中の事故を未然に防ぐ。
この3つを守るだけで、あなたの書くインフラコードは格段に信頼性の高いものになります。
「面倒だな」と感じるかもしれません。でも、その一手間が、深夜の障害対応や重大な情報漏洩からあなたを救います。インフラエンジニアの仕事は、「見えないところで、いかにリスクを排除するか」に尽きます。
さあ、今日からコードをクリーンに保ち、より安全なクラウド運用を楽しんでいきましょう！何か詰まったら、いつでも聞きに来てくださいね。応援しています。