利益:
- IaC の概念と Terraform の作業サイクル (初期化、計画、適用、状態、モジュール) を理解し、人工知能に安全な HCL ドラフトを生成させる能力
- 適用前に計画を使用して各変更をチェックし、予期しない破棄/置換行を検出する機能
- コードに秘密を漏らさない、状態を安全に維持する、IAM 権限を最小限に抑えるという原則を適用する能力
以前は、サーバーのセットアップはクラウド パネルをクリックするだけで、仮想マシンの作成、ネットワークのセットアップ、セキュリティ ルールの追加を行うだけでした。この方法は時間がかかり、エラーが発生しやすく、再現性がありませんでした。同じ環境を 2 回セットアップすることはほぼ不可能でした。現在、インフラストラクチャはコードとして管理されています。 IaC (Infra Structure as Code) は、サーバー、ネットワーク、データベースなどのクラウド リソースを手動ではなくテキスト ファイルで記述するアプローチです。これらのファイルはバージョン管理 (Git) 内にあります。誰が、いつ、何を変更したかを確認できます。 1 つのコマンドで、まったく同じ方法で同じインフラストラクチャを何度でもセットアップできます。
最も一般的な IaC ツールは Terraform です。 Terraform は、HCL (HashiCorp Configuration Language - Terraform の構成言語) と呼ばれる可読言語で記述された定義を取得し、それをクラウド プロバイダー (AWS、Azure、GCP) の API に変換して、リソースを作成します。 AI は HCL をよく理解しており、複雑なブロックを迅速に生成します。しかし、IaC では、間違いの代償は高くなります。定義を 1 つ間違えると、運用データベース全体が消去されてしまう可能性があります。そのため、Terraform の黄金律は、すべての変更を実装する前に「計画」を立てて確認することです。
Terraform のランタイム
Terraform は 3 つの基本的なコマンドで動作します。これらを理解していることは、AI 出力を制御するための前提条件です。
- `terraform init`: プロジェクトを開始し、必要なプロバイダー プラグインをダウンロードします。
- `terraform plan`: 現在の状況と望ましい状況を比較し、何を追加するか、何を変更するか、何を削除するかを示します。何も実装しません。これは最も重要なセキュリティ手順です。
- `terraform apply`: 実際にプランを適用し、リソースを作成/変更します。
さらに、2 つの概念が重要です。状態 (状態ファイル): これは、Terraform が管理するリソースの現在の状態を保持するファイルです。通常、2 人が同時に変更したり破壊したりできないように、遠隔地の施錠された倉庫に保管されます。モジュール: 再利用可能な構成パッケージ。たとえば、「ネットワークのセットアップ」モジュールは多くのプロジェクトで使用できます。
ヒント: Terraform 出力で最も危険な兆候は、プラン出力の破棄行または -/+ (置換) 行です。これらは、リソースが削除されることを意味します。計画内で予期しない破壊が発生した場合は決して適用せず、まずそれが発生した理由を理解してください。
ステップバイステップ: AI を使用して IaC を作成する
- 必要なインフラストラクチャを明確にします。 「eu-central-1 上の 1 つの VPC、2 つのサブネット、1 つのセキュリティ グループ、および 1 つの t3.micro EC2」のように具体的にします。
- プロバイダーとバージョンを指定します。どのクラウド、どの Terraform、プロバイダーのバージョンですか?バージョンを指定しない場合、AI は古い構文または互換性のない構文を返す可能性があります。
- HCL ドラフトを作成してもらいます。変数と出力もリクエストします。
- シークレットを取り出します。パスワードやキーなどの値は、コードではなく変数と秘密保管庫に保存する必要があります。
- `init` + `plan` を実行します。計画の出力を 1 行ずつ読みます。予期しない削除がないか確認します。
- 小さなことから始めて、徐々に実装してください。まず、分離されたテスト アカウント/環境に適用します。
セキュリティ: IaC 固有のリスク
IaC は強力であると同時にリスクも伴います。 3 つの重要なポイント:
- 状態ファイルにシークレットがあります。 Terraform 状態では、データベース パスワードなどの機密値が平文で保持されることがあります。 State をパブリック リポジトリに決して置かないでください。暗号化され、アクセスが制限されたリモート バックエンドを使用します。
- HCL にシークレットを埋め込まないでください。 password="prod123" のような行は、Git 履歴に永続的に書き込まれます。代わりに変数を使用し、実行時に環境変数 (TF_VAR_...) またはシークレット ボールトから値を指定します。
- 非常に広範な IAM 権限。 AI は、「動作させる」ために Action: "*" (すべてを許可) のようなブロックを生成することがあります。これは脆弱性です。許可を必要最小限に絞ります。
注意: シークレットが Git 履歴に入ると、そのシークレットは過去に残り、たとえファイルを削除したとしても侵害される可能性があります。誤ってコミットした場合は、すぐにシークレットをキャンセルしてローテーションしてください。削除するだけでは十分ではありません。
危険な計画の兆候の表
計画の印刷物
意味
何をすべきか
+作成
新しいリソースが追加されます
一般的には安全ですが、レビューしてください
~ インプレース更新
ソースはその場で変わります
影響を確認する (停止は発生するか?)
-/+ 置換
削除されて再作成されます
注意: データ損失が発生する可能性があります
- 破壊する
リソースは破壊されます
停止: 期待していない場合は決して適用しないでください
ミニケース3個
ケース 1 — 2 日分の作業を 3 時間で完了します。あるチームは、新しいテスト環境 (VPC、サブネット、RDS データベース、ECS クラスター) をセットアップするために Terraform を作成しようとしていましたが、HCL に移行したばかりでした。彼らは AI のアーキテクチャとバージョンを説明し、モジュール式の青写真を作成しました。彼らは各モジュールを計画に従って検証し、3 時間以内に稼働させました。手動による試行錯誤には 2 日かかります。
ケース 2 — 計画が削除を検出しました。エンジニアは、AI が生成した更新コードを適用せずに計画を実行しました。出力には、運用データベースの -/+ replace が含まれていました。AI は置換不可能なフィールドを置換しようとしました。これは、データベースを削除して再作成することを意味します。エンジニアは適用を中止し、安全な方法に変更しました。計画を立てる習慣が災害を防ぎました。
ケース 3 — 埋もれた秘密の漏洩。後輩の YZ が db_password = "S3cret!" を発行しました。そのままラインをコミットして押し込んだ。コードレビューに巻き込まれました。パスワードはすぐにキャンセルされて変更され、値は変数に移されて秘密保管庫から供給されました。教訓: HCL には平文のシークレットは存在しません。
コピー可能な 4 つのテンプレート
1) インフラストラクチャ ドラフトの作成:
Terraform (バージョン ~> 1.7) を使用して、[CLOUD: AWS] に次のインフラストラクチャを書き込みます: [SOURCE LIST]。領域[X]。ルール:- すべての機密値を変数にし、HCL に埋め込まないでください。- プロバイダーのバージョンを修正します (required_providers)。- IAM 権限を最小限に抑え、「*」を使用しないでください。- 出力として [X, Y] を返します。コードをモジュール化して説明付きで提供します。
2) 計画出力の解釈:
以下の「terraform plan」出力を分析します。リストしてください:(1) どのリソースが追加/変更/削除されたか、(2) データ損失または中断のリスクがある行、(3) 申請前に尋ねるべき 3 つの質問。計画: [出力]
3) 既存の HCL のセキュリティを検査します。
セキュリティについては、次の Terraform コードを確認してください: 埋め込みシークレット、広すぎる IAM 権限、オープン ネットワーク ルール (0.0.0.0/0)、暗号化されていないストレージ?各発見事項を重要性と修正の順に書きます。コード: [HCL]
4) 繰り返しコードをモジュールに変換します。
次の反復的な Terraform コードを再利用可能なモジュールに変換します。どの値が変数であるべきか、モジュール インターフェイスは何であるべきか?使用例も示します。コード: [HCL]
弱いプロンプト / 強いプロンプト
弱者: 「Terraform でデータベースを作成します。」
結果: どのクラウド、どのエンジン、どのバージョンが暗号化されているかどうかが不明。従来の構文を使用すると、AI はパスワードをコードに埋め込む公開された例を提供できます。
Strong: 「Terraform ~> 1.7 を使用して AWS に RDS PostgreSQL 15 インスタンスを作成します。パスワードを変数にして、コードに埋め込まないでください。ストレージは暗号化されており、パブリックではなくプライベート サブネットからのみアクセスできます。プロバイダーのバージョンを修正します。エンドポイントを出力として返します。」
違い: 2 番目のプロンプトでは、エンジン、バージョン、暗号化、ネットワーク制約、およびシークレット ルールが提供されます。出力は安全で本番に近いものです。
よくある間違い
- 「計画」を立てずに「申し込む」こと。 IaC で最も高価な間違い。常に最初に計画を立てます。
- HCL へのシークレットの埋め込み。 Git 履歴に永久的な漏洩を引き起こします。
- 保管状態が不安定です。暗号化もロックも解除された公開状態は大惨事です。
- バージョン修正はしておりません。バージョンを指定せずにプロバイダーを使用すると、将来的に突然障害が発生する可能性があります。
- *`アクション: ""` などの広範な権限。** 最小特権の原則に違反します。
- 予期せぬ「破壊」を無視します。疑問を持たずに計画の削除行を適用します。
要約すると
IaC は、インフラストラクチャを反復可能、バージョン管理可能、監査可能なコードに変換します。最も一般的なツールは Terraform です。 AI は HCL スタブをすぐに生成しますが、バージョン、クラウド固有の詳細、およびセキュリティ ルールを提供する必要があります。 Terraform の絶対的なルール: 計画に基づいてすべての変更を確認し、予期しない削除をクエリし、コードから秘密を遠ざけ、状態を安全に維持します。プラン出力の破棄行と置換行は、最も注意深く読む必要がある場所です。
アプリケーションタスク
上記の「インフラストラクチャ スケッチの生成」テンプレートを使用して、AI に小規模なインフラストラクチャ (ストレージ バケットやアクセス ポリシーなど) を生成させます。次に: (1) コードに埋め込まれたシークレットまたは * 権限を「検査」テンプレートでチェックします。 (2) 可能であれば、テスト アカウントで init + plan を実行し、「プラン解釈」テンプレートを使用してプラン出力を読み取ります。 (3) 予期しない削除/変更がある場合は注意してください。
チェックリスト
- [ ] クラウド、Terraform/プロバイダーのバージョン、暗号化/ネットワークの制約をプロンプトに追加しました。
- [ ] コードには平文の秘密はありません。精度値は変数です。
- [ ] IAM/権限を最小限の権限に絞りました、※使用しませんでした。
- [ ] apply の前に plan を実行し、出力を 1 行ずつ読み取りました。
- [ ] 計画に予期しない破棄/置換がないことを確認しました。
- [ ] この状態は、暗号化され、ロックされ、制限されたバックエンドに保持されていると確信しています。