Terraform用CI/CD。CodePipeline vs GitHub Actions どっちがいい？

GHAのUXに未練タラタラ…まるで高級ベッドを諦めて畳に戻るみたいな気分ですね。でも、セキュリティ重視ならその判断、筋が通ってます！

ご指摘の通り、TerraformのCI/CDにおいて「どこで危険な権限を持たせるか」は設計上の重要ポイントです。以下、それぞれの選択肢についての観点と、CodePipelineを選んだ理由の妥当性を少し掘り下げてみます。

CodePipelineを選んだ理由の整理

1. AWS内に権限を閉じ込められる

   • IAMロール、AssumeRole、KMSなどの制御がCodePipeline内で一元管理できます。
   • 秘匿情報（たとえばTerraformのバックエンドS3やState Lock用のDynamoDB）もAWSの中で閉じられるので、外部への情報流出リスクを減らせます。

2. GHAでのセキュリティ維持コストが高い

   • OIDC連携やブランチ制限、Secretsの最小化などを工夫すれば確かに安全にはできます。
   • ただ、その設計・運用をずっと維持するのはなかなか骨が折れます。チームが大きくないなら、その手間をCodePipelineに丸投げできるのは利点です。

少しだけ補足

• GHAを使った構成でもCodePipeline同様にIAMロールを使ったセキュアなアクセスは可能です。
• ただし、OIDC設定のミスやSecretsの扱い方次第でセキュリティ事故が起きやすいです。

総じて、「セキュリティ優先」かつ「権限管理の中央集権化」を志向するなら、CodePipelineという選択は合理的です。Terraformを扱うならなおさらですね。畳の上でも安心してデプロイできます。

セキュリティ設計の話になると一気に“刀鍛冶”みたいなテンションになりますね。「折れない、曲がらない、切れ味鋭いCI/CDパイプラインをくれ！」という声が聞こえてきそうです。

おっしゃる通り、GHAでも強固なOIDC設定とコード管理の徹底ができていれば、セキュリティ事故の可能性はかなり低く抑えられます。ただ、CI/CDは「少しのミスが全てをひっくり返す」領域ですので、「一つ穴が開いただけでアウト」という表現、非常に本質を突いています。

GHAの課題とリスク

• OIDC設定のミス
  • 条件を絞らずに権限を付与してしまうと、他のリポジトリやブランチからも使えてしまうケースがあります。
• リポジトリのコード改変
  • 権限を扱うコードがPull Requestで改変されたとき、レビュープロセスや保護ブランチの設定が甘いと、即デプロイの道が開かれる可能性も。

CodePipelineのメリット

• IAM権限の範囲がAWSに閉じている
  • 信頼されたエンティティとして他のAWSサービスを使う分には、IAMポリシーで制御が完結します。
• Secrets ManagerやKMS連携がスムーズ
  • コマンド一つで暗号化・復号ができるので、外部との秘密情報の受け渡しが減ります。
• 実行ログ・履歴が統一的に管理できる
  • CloudWatch LogsやEventBridgeと統合して監査しやすいのもポイントです。

UXで言えばGHAに軍配が上がりますが、「AWSリソースに対する高い権限を誰に渡すか？」という点で、CodePipelineで権限の境界をAWS内に収めておくという考え方は、非常に堅実です。安全第一、Terraformの神様もニッコリです。

それですそれです！GHAでのアプリケーションのビルド・デプロイは、言わば“フライパンの中で炒め物を作る”ようなもので、万一失敗しても火傷で済みます。でもTerraformみたいなIaC（Infrastructure as Code）は、ガス管を引き直すレベルの話になるので、ちょっとのミスで家が吹っ飛びます。

GHAでのアプリケーションビルド・デプロイは比較的安全な理由

• 権限スコープが狭い
  • ECSやLambdaの更新、S3へのアップロードなどが中心で、影響範囲が「そのアプリケーション」に限られることが多いです。
• 変更が即座にインフラ全体に波及しにくい
  • たとえばAPIに不具合が出ても、RDSの消失とかVPC構成の破壊にはつながりにくいです。
• 段階的にロールアウト可能
  • Blue/Greenデプロイやカナリアリリースで、影響を少しずつ観測できます。

一方で、Terraformでやらかすと…

• IAMの悪用
  • 管理者権限を持つユーザーを作って外部に流すことすら可能。
• ネットワーク全体の閉塞
  • ルートテーブルやセキュリティグループ、NACLの設定をミスるとVPCごと通信不能に。
• データの永続的損失
  • terraform destroyを事故ってRDS本番が吹っ飛んだ…というのはよくある都市伝説（たまに実話）。

なので、ご指摘のように用途に応じてCI/CDの安全設計の“レベル”を分けるという考え方は、非常に理にかなっています。

• アプリの更新＝GHA（使い勝手重視＋中程度のセキュリティ設計）
• インフラ構成の更新＝CodePipeline（権限管理重視＋高セキュリティ設計）