EntraID や N8N の管理者権限が作業時必要になります

• Entra ID のグローバル管理者権限、またはアプリケーション管理者権限
• N8N のインスタンスオーナーまたは管理者権限
• N8N の契約プランが Buisiness or Enterprise であること

設定

手順1: N8N 側で必要な情報を取得

1. N8N に管理者権限でログイン
2. Settings > SSO に移動
3. 以下の情報をメモ：
   • ACS URL (Redirect URL): https://your-n8n-domain.com/rest/sso/saml/acs
   • Entity ID: https://your-n8n-domain.com/rest/sso/saml/metadata

手順2: EntraID でエンタープライズアプリケーションを作成

2-1. 新規アプリケーションの作成

1. Entra ID にサインイン
2. 左トグルから [Entra ID] > [Enterprise applications] > [New application] をクリック
3. Create your own application をクリック
4. 以下を入力して Create をクリック
   • Name: n8n (任意)
   • 選択: 「ギャラリーにない他のアプリケーションを統合する（Non-gallery）」

2-2. SAML シングルサインオンの設定

1. 作成したアプリケーションを開く
2. 左メニューから Single sign-on を選択
3. SAML をクリックし、以下の項目を設定する

💡Tips: SAML の設定項目の意味について

• 基本的な SAML 構成とは？
  • Identifier (Entity ID):
    • N8N を一意に識別するための ID
    • 「この SAML リクエストは、どのアプリケーションから来たのか？」を Entra ID が判断するために使用
    • 世界中で唯一無二の識別子である必要がある
  • Reply URL (Assertion Consumer Service URL):
    • 認証完了後に SAML Response（認証結果）を受け取る URL
    • Entra ID が「認証成功しました！」という情報を送る先
    • セキュリティ上、この URL だけが SAML Response を受け取れる
• 属性とクレーム とは？
  • SAML では 認証先のアプリ と EntraID 間でログインに必要な情報を受け渡すが、各アプリで何の情報が必要なのか異なる.
  • 「認証のやり取りの中に何の情報をふくめるか？」を定義しているのクレーム
  • N8N ではクレーム情報をもとに：
    • ユーザーアカウントを作成/識別
    • ユーザー情報を表示
    • 権限を割り当て（アプリによる）

2-3. メタデータ情報の取得

SAML Certificates セクションから Metadata URL を取得：

1. シングルサインオンの設定画面から [SAML証明書] のセクションに移動
2. App Federation Metadata Url をコピー
   • 例: https://login.microsoftonline.com/[tenant-id]/federationmetadata/2007-06/federationmetadata.xml

💡Tips: SAML メタデータとは

Entra ID が N8N に渡す「私の情報と使い方」：

• メタデータに含まれる情報:
  • 誰か？（Entity ID / Issuer）
  • どこに認証リクエストを送るか？（SSO URL）
  • どこにログアウトリクエストを送るか？（Logout URL）
  • どうやって安全に通信するか？（証明書）
  • どんなフォーマットで通信するか？（設定）

ex. 実際のメタデータのサンプル

<?xml version="1.0" encoding="UTF-8"?>
<EntityDescriptor 
  xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
  entityID="https://sts.windows.net/12345678-abcd-1234-abcd-123456789abc/">
  
  <!-- 1️⃣ IDプロバイダー（Entra ID）の基本情報 -->
  <IDPSSODescriptor>
    
    <!-- 2️⃣ 証明書（公開鍵）- 重要！ -->
    <KeyDescriptor use="signing">
      <X509Certificate>
        MIIDPjCCAiqgAwI...
      </X509Certificate>
    </KeyDescriptor>
    
    <!-- 3️⃣ ログインURL（認証リクエストの送信先） -->
    <SingleSignOnService 
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://login.microsoftonline.com/12345678.../saml2"/>
    
    <!-- 4️⃣ ログアウトURL -->
    <SingleLogoutService 
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
      Location="https://login.microsoftonline.com/12345678.../saml2/logout"/>
    
  </IDPSSODescriptor>
</EntityDescriptor>

2-4. ユーザー・グループの割り当て

1. 左メニューから Users and groups を選択
2. 「ユーザーまたはグループの追加」をクリック
3. N8N にアクセスさせるユーザーまたはグループを選択
4. Assign をクリック

手順 3: N8N 側でメタデータを設定

1. N8N に戻り、Settings > SSO を開く
2. Identity Provider Settings フィールドに Metadata URL を貼り付け
3. Activated トグルを押して SSO を有効化する
4. Save をクリック
5. Test Settings ボタンをクリックし SSO がうまくいったかを確認
   • うまくいくと [SAML Connection Test was Successful] のメッセージがでます
6. あとはログイン画面で SSO で sign-in するボタンが表示されます

先日ALBの前段にCloudFrontを導入した際に、4XX系のエラーが爆増する現象に遭遇しました

開発環境での確認段階で気づけたのでセーフでしたが、ある程度リクエスト量をかけないと再現しない現象で見落としそうになったため、備忘録を残しておきます

同様の構成を検討されている方々の参考になれば幸いです。

構成図

今回想定しているインフラの構成は以下です

なお、Cloudfront の後ろに WAF を配置した理由は、 CDNキャッシュ後にWAFを通すことでWAFルールが検査するリクエスト数が減るのでコストメリットがありそうと考えたためです。

4XX 系エラーの原因

Cloudfront 導入後に 4XX 系エラーが増加してしまった原因は大きく 2 つありました

1. WAFのRatelimitルールによるブロック
2. アプリケーション(PHP, Laravel)のRatelimit

両方に共通する根本原因は、Cloudfrontを経由することで、WAFやアプリケーションから見たクライアントのIPアドレスが、実際のユーザーのIPではなくCloudfrontのエッジサーバーのIPアドレスに置き換わってしまったことでした。

図解すると、以前は以下のように User IP を直接とれていましたが

Cloudfront導入後は IP が置換されてしまうため、正しいクライアントIPが認識できなくなり、多数のリクエストがレートリミットでブロックされてしまいました。

原因1. WAF の Ratelimit による 403 エラー

400 系エラーが増えた 1 つ目の原因は WAF によるレート制限です

WAFには、DDos的なアクセスへの対策として、同一IPからの一定レートを超えるアクセスはブロックするルールが設定されていました

ただ構成図で示した通り、今回はWAFの前段にCloudfrontがいるため、何も意識をしないと Cloudfront の IP を見てレート制限をかけてしまいます

対策としては、WAFのレート制限はIPアドレスをどの値で集計するか選ぶことが出来るため、Source IP を使った集計ではなく、X-Fowarded-For ヘッダーの値から集計するように設定することで、クライアントのIPを正しく判定できるようになりました。

コンソールから設定する場合、リクエストの集約を [ヘッダー内のIPアドレス]、ヘッダーフィールド名 を「X-Forwarded-For」に設定することで、Cloudfrontの前段にあるIPアドレスを見てレート制限をかけることができます

原因2. アプリケーション (laravel) API Throttle による 429 エラー

Webアプリケーション側でも、IPベースでのAPIのレート制限機能を持っています。
今回の環境でも、Laravel の API Throttle 機能が有効化されており、アプリケーションレイヤーでも 429 エラーを返していました

API Throttleの参考: https://kinsta.com/jp/blog/laravel-throttle/

そこで、対策として以下の設定を追加しました

1. Cloudfront で、CloudFront-Viewer-Address をヘッダーを付与して後続のALBに流す
2. Apche で CloudFront-Viewer-Address を受け取り、RemoteIP として扱う設定を追加する

Cloudfront で、CloudFront-Viewer-Address をヘッダーを付与

Cloudfront では後続のALBになどにHTTPリクエストをリレーする際、追加ヘッダーを設定することができ、そのうちの一つに「CloudFront-Viewer-Address」というヘッダーがあります。

CloudFront-Viewer-Address – ビューワーの IP アドレスと、リクエストのソースポートを示します。例えば、198.51.100.10:46532 のヘッダー値は、ビューワーの IP アドレスが 198.51.100.10 で、リクエストのソースポートが 46532 であることを意味します。

CloudFront のリクエストヘッダーを追加する - Amazon CloudFront

CloudFront HTTP リクエストヘッダーを追加して、ビューワーのデバイスタイプ、IP アドレス、地理的位置、リクエストプロトコル (HTTP または HTTPS)、HTTP バージョン、TLS 接続の詳細、および JA4 フィンガ...

docs.aws.amazon.com

これを使えば後続処理に、実際のリクエスト元の IP を渡すことができます

以下のようなオリジンリクエストポリシーを作成し、対象のビヘイビアに紐づけることで、「CloudFront-Viewer-Address」ヘッダーを後続に送ることができます。

• ポリシー名等: 任意
• ヘッダー: すべてのビューワーヘッダーと次の Cloudfront ヘッダー
• add header: CloudFront-Viewer-Address

ApacheでCloudFront-Viewer-Addressを受け取り、RemoteIP に設定

上記ステップにより、Cloudfront から CloudFront-Viewer-Address ヘッダーが送られてきます。

これを Apache 側で RemoteIP としてセットしてあげることで、PHPなどアプリケーション層でも正しいIPを認識できるようになります。

CloudFront-Viewer-Address は形式に少し癖があり、198.51.100.10:46532 のように IP アドレスの後ろにポート番号がついてしまうため、これを取り除いてあげる必要があります。

apache の httpd.conf ファイルに以下を追加してあげることで、Remote IP に正しいIPが設定されました。

... (もとの設定) ...

# CloudFront-Viewer-Address から IP 部分のみを抽出 (例: CloudFront-Viewer-Address: 192.30.252.129:443)
SetEnvIf CloudFront-Viewer-Address "^([0-9.]+):" VIEWER_IP=$1

# 抽出した IP アドレスを RemoteIPHeader として使用
RequestHeader set X-VIEWER-IP %{VIEWER_IP}e env=VIEWER_IP
RemoteIPHeader X-VIEWER-IP

... (もとの設定) ...

まとめ

Cloudfront 導入時などはIPがつけ変わるため、後段のアプリケーションやWAFなどでIP制限をかけている場合はそこにも注意が必要だよというお話でした。

今回はIdentiy Centerで管理しているSSOユーザーごとにS3アクセスを制御したいときのバケットポリシーの書き方について記事になります。

ポリシー自体はシンプルになったのですが、どの条件でコントロールすればうまくいくか案外迷ったので、同じような方の参考になれば幸いです。

想定している構成

細かい要件としては以下を想定しています

• AWS 利用者は authority-A という許可セットを使って、対象のAWSアカウントにアクセスする
• authority-A は対象AWSアカウント内のS3全般に対して広めのアクセス権限をもっている
• AWSアカウント内の特定のS3バケットだけは、特定ユーザーだけ見れるようにしたい。

SSOの許可セットで広めに AWS 権限を与えているものの、特定のS3バケットについては見れるユーザーを絞りたいというケースになります

ポリシーの書き方

結果シンプルになりましたが、以下のようなポリシーで実現できました

S3に限らずIAM全般では明示的な Deny がある場合、それが最初に評価されるため、許可セット(authority-A)がアクセス権限を持っていたとしても、Deny 条件にマッチすればアクセスできなくなります。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "SSOTest",
			"Effect": "Deny",
			"Principal": "*",
			"Action": "*",
			"Resource": [
                             "arn:aws:s3:::<S3 バケット名>/*",
                             "arn:aws:s3:::<S3 バケット名>"
                        ],
			"Condition": {
				"StringNotLike": {
					"aws:userId": "AROA*:<SSO ユーザー名>*"
				}
			}
		}
	]
}

SSO ユーザー名を確認したい場合は、以下コマンドを叩いて確認できます

aws sts get-caller-identity --output yaml

注意点としては先ほど書いたように、Deny 句があると最初にそれが評価されるため、SSOユーザー以外にもアクセスしてくるプリンシパル(例えばECSやlambda)がいる場合、適宜 Condition 句でdeny対象から外す必要があります。

おまけ

最初やろうとしてダメだった方法も書いておきます

SSO から 払いだされるフェデレーテッドユーザーの形式も <許可セット名>/<SSO ユーザー名> で、SSOユーザー名含んでいたので、これでポリシーかけないかな？と思ったのですがダメそうでした。

↓の感じで条件書いてみたのですが、許可セットまでは制御がきくものの SSO ユーザー名までは aws:PrincipalARN に含められないようです

"Condition": {
	"StringNotLike": {
		"aws:PrincipalARN": "arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*/AWSReservedSSO_<許可セット名>/<SSO ユーザー名>"
        }
}

# XXX@XXX:~/app$ /usr/bin/supervisorctl status
unix:///tmp/supervisor.sock no such file

socket ファイルがなくて怒られているようですが、今まで動いていたのに何で？と思い調べた時のメモになります。

結論

お察しの方も多いかもしれませんが、「supervisor のソケットパスを /tmp 以外に指定」すれば解決しました。

[unix_http_server] と [supervisorctl] に設定が必要で、具体的には以下のようになります。

[unix_http_server]
;file=/tmp/supervisor.sock   ; デフォルトだと /tmp に作られる。
file=/var/run/supervisor.sock 
...(中略)

[supervisorctl]
serverurl=unix:///var/run/supervisor.sock
...(中略)

多くのディストリビューションで /tmp 配下のファイルは定期的にお掃除されるようになっています。

supervisor のデフォルト設定では /tmp 以下にソケットを作ろうとするので、折角作られたソケットファイルが掃除されてしまっていたことが原因でした。

今回の自分の実行環境は amazon linux 2023 で、10 日ごとに tmp ディレクトリ配下をお掃除する設定が入っていました。確認時のコマンドは以下です。

# XXX@XXX:~/app$ /usr/lib/tmpfiles.d/tmp.conf
q /tmp 1777 root root 10d # /tmp 以下は 10 days で消える
q /var/tmp 1777 root root 30d

CloudFront や WAF が既に立っている構成では、そちらでメンテ画面を制御する方法がメジャーかと思いますが、そうでない場合 ALB で制御するケースもあるかと思います。

ALB で制御する方法もいろいろアイデアはあるかと思いますが、今回は lambda + S3 のお手軽実装でメンテページを表示させる方法について紹介したいと思います。

構成図

ALB のリスナーに メンテナンス用のLambdaを向いたルールを追加します。

普段は通常時用のリスナールールより優先順位を下げておき、メンテイン時は優先順位を上げることでメンテナンス画面を表示させます

ALB の操作だけでぱっとメンテインできるので、運用が楽ちんで嬉しいですね

Lambda の実装

Lambda コード

メインとなる lambda ロジックはこんな感じで実装をしました

import boto3
import os
import base64

# 環境変数からS3の情報を取得
BUCKET_NAME = os.environ['BUCKET_NAME']

s3 = boto3.client('s3')

def lambda_handler(event, context):
    try:
        # リクエストされたパスからファイル名を取得
        file_name = event.get('path', '').lstrip('/')
        if not file_name:
            file_name = 'maintenance.html'  # デフォルトのファイル名

        # S3バケットからファイルを取得
        s3response = s3.get_object(Bucket=BUCKET_NAME, Key=file_name)
        body = s3response['Body'].read()
        # S3オブジェクトのメタデータからContent-Typeを取得
        content_type = s3response['ContentType']

        # content_type が text 以外の場合は base64 エンコードを挟んでから utf-8 でデコード。
        if 'text' in content_type:
            response_body = body.decode('utf-8')
            is_base64_encoded = False
        else:
            response_body = base64.b64encode(body).decode('utf-8')
            is_base64_encoded = True

        return {
            # メンテ画面のため 正常系だが 503 を返す
            'statusCode': 503,
            'headers': {
                'Content-Type': content_type
            },
            'body': response_body,
            'isBase64Encoded': is_base64_encoded
        }
    except Exception as e:
        return {
            'statusCode': 500,
            'body': f"Error getting the file from S3: {str(e)}"
        }

実装のポイントとしては以下となります

• event.get('path', '').lstrip('/')で HTTP リクエストからパス部分のみ取り出して、S3のファイルパスとして使用しています

• content_type は S3 ファイルのメタタグから Content-type を取得しています
  • 小ネタですが、Content-type を何も指定せずにS3にファイルアップロードした場合は python 製のライブラリによって、そのファイルの型が自動で推測されるようです(aws cli)
• text は utf-8 でそのままデコードが可能ですが、画像ファイルなどは 一度 base64 でエンコードしてから utf-8 に直すとうまく表示されました

その他リスナールールやS3の作成

Lamda を作った後は上記構成図の S3 や ALB のリスナールールを作成します

そのあたりの作業は特に特徴はないので、参考になる記事の紹介に留めたいと思います

ALBリスナールールとLambdaだけでメンテナンスページへの切替が簡単にできる仕組みを作る | DevelopersIO

dev.classmethod.jp

ALBで1025文字以上のメンテナンス画面を表示する方法 - Qiita

背景 AWSのALB（Application Load Balancer）のリスナールールを使ってメンテナンス画面を表示することは一般的ですが、ALBのリスナールールには1024文字の制限があります。 そのため、1024文字を超えるメンテナ...

qiita.com

上記の記事の手順に加えて、 Lambda -> S3 の間に、Gateway 型の VPC エンドポイントを噛ませておけると、S3 のアウトバウンドの転送料金がかからなくなるため、ある程度のトラフィック量が見込まれる場合は入れておくといいかもしれません。

ERROR: The request could not be satisfied

repost.aws

おまけ: メンテナンス画面の表示方法いろいろ

冒頭で軽く触れた通り、ALB でメンテナンス画面を表示させるにはいろいろな実装方法があります。

個人的に方法を比較した際のメモを残しておきます。

今回はサービスの性質上あまり大量アクセスを見込んでいなかったため、実装のお手軽さを重視して Lambda を採用してみました。トラフィックがある程度見込まれるサービスの場合は、Cloudfront 経由がなんだかんだ綺麗なのかもなという印象でした。

1.ALBの固定レスポンスで返す

• 参考記事: https://www.netassist.ne.jp/techblog/29666/
• ALB 単体で完結するため、実装としては一番楽だしコストも安い
• 別ファイルのCSSや画像の読み込みはできない
• レスポンスの内容は1024文字までに制限されるのでリッチなページは返せない

2.Cloudfrontを経由してメンテ画面を表示

• 参考記事:https://techblog.nhn-techorus.com/archives/21488
• AWS上で完結させる要件だとおそらく一番メジャーな実装方法
• CDNキャッシュが効く分、早くレスポンスが返る嬉しさがある
• CDNキャッシュされて、S3へのリクエスト量が節約できるので若干のコストメリットがある
• この中だと実装が比較的重め (IaC してる場合だと設定値多いリソースなので特に)

3.Privatelinkを経由してメンテ画面を表示

• 参考記事:https://aws.amazon.com/jp/blogs/news/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/
• VPC エンドポイント追加して向けるだけなので実装はかなり楽
• インターフェース型 VPC エンドポイントを使うので、コストは結構かかっちゃう

4.Lambda を経由してメンテ画面を表示 (今回の方法)

• 参考記事: https://dev.classmethod.jp/articles/alb-listener-rule-lambda-maintenance-page/
• 実装はまあまあお手軽
• lambda ロジックの管理コストがかかる
  • とはいえ layer も不要で、大分軽微な実装なので運用負荷はそんな高くないはず

皆さんは Terraform リポジトリを管理する際、CIを組んでいるでしょうか？

プルリク公開時に Terraform Plan を自動実行して、結果をGithub上で確認できると、変更箇所が伝わりやすくなりハッピーかと思います。

tfcmt はそんなTerraformのCIを組みたいときに活躍するツールで、terraform plan の結果を素敵な感じに整形して、プルリクにコメントしてくれます

ただ、Terragrunt のような複数の Statefile を管理するリポジトリの場合、プルリク上に大量にコメントが流れてしまい、かえって見づらくなることもあるかなと思います。

今回触っていた IaC リポジトリでも、6環境×モジュールが6~7個あったため、最大40個強のPlan結果がプルリクコメントに並んでしまうことになり、さすがにこれを運用すると辛そうだな…という印象でした。

↓ は Bot が PR に大量にコメントを流している様子です

そこで、Github Workflow の Summary に結果を見やすくまとめることで、上記の課題を解決しつつ、快適に terraform の CI を運用する方法を紹介したいと思います。

Terragrunt でなく生の Terraform を使っていても、Module 等で State の分割管理を行っている場合、同様の課題感を持っていたりすると思うので、そういった方の参考にもなれば幸いです。

ついでに Github Enterprise 環境で tfcmt を構築している記事もあまり見かけなかったので、その解説もできたらと思っています。

結論

いろいろ試した結果、こんな形で落ち着きました。

環境ごとに Github Actions のワークフローを作成し、サマリー部分にモジュールごと実行した Plan 結果を見やすくまとめています。

逆にプルリクのラベル付けやコメントを書き込む機能などは、明示的に無効化を行いました。

実装

全体のディレクトリ構成

Terraform リポジトリのディレクトリ構成としてはこんな感じになっています

.
├── .github
│   ├── workflows
│   │   ├── develop_terraform_plan.yml
│   │   ├── staging_terraform_plan.yml
│   │   └── ... (other files)
│   └── tfcmt
│       ├── tfcmt.yml
│       └── tfwrapper.sh
├── environments
│   ├── develop
│   │   └── ap-northeast-1
│   │       └── ... (modules)
│   └── ... (other environments)
├── modules
│   ├── ecs
│   │   ├── main.tf
│   │   ├── outputs.tf
│   │   ├── variables.tf
│   │   └── ... (other files)
│   └── ... (other modules)
└── terragrunt.hcl

tfcmt.yml の設定

tfcmt.yml という名前で config ファイルを書いておき、tfcmt コマンド実行時にオプションに指定してあげることで、plan 結果を整形するフォーマットをカスタマイズできます。

かなりカスタマイズしやすく、個人的に感動したポイントでした。

参考: https://suzuki-shunsuke.github.io/tfcmt/config#default-configuration

今回設定した tfcmt.yml の内容になります

embedded_var_names: []
terraform:
  plan:
    # github enterprise の時のみ設定が必要
    # 参考: https://suzuki-shunsuke.github.io/tfcmt/github-enterprise
    ghe_base_url: https://XXX.github.com
    ghe_graphql_endpoint: https://XXX.github.com/api/graphql
    # terragrunt だと statefile 毎ラベルが上書きされて逆に管理し辛かったので無効化
    disable_label: true
    template: |
      <details><summary><strong> :package: Target Module: {{.Vars.target}} </strong></summary>
        {{template "result" .}}
        {{template "updated_resources" .}}
        {{template "changed_result" .}}
        {{template "change_outside_terraform" .}}
        {{template "warning" .}}
        {{template "error_messages" .}}
      </details>

ポイントとしては以下になります

• Github Enterprise の場合は plan 実行時の 環境変数に ghe_base_url と ghe_graphql_endpoint を足してあげる必要があります。
• tfcmt は自動で plan 結果を要約するようなラベル付けを行ってくれるのですが、複数の Statefile を管理するリポジトリの場合は、逆に見辛さが勝ってしまったので無効化しています。
• template: に続くブロックで plan 結果をどんな感じで整形するか指定できるので、お好みでいじってみても良いかと思います。

tfwrapper.sh の設定

Terragrunt の場合、tfcmt が terragrunt run-all plan コマンドをそのまま叩けないので wrapper のスクリプトをかませてあげる必要があります。

Terraform をそのまま使っている場合はこの作業は不要かなと思います。

#!/bin/bash
set -euo pipefail

# コマンドの種類を取得(例: apply, plan, fmt...)
type=$(echo "$@" |  awk '{print $1}')

# カレントディレクトリを整形して、target の module 名を取得
base_dir=$(git rev-parse --show-toplevel)
target=${PWD#"$base_dir"/}
target=$(echo "$target" | sed 's|/\.terragrunt-cache/.*||')

if [ "$type" == "plan" ]; then
    tfcmt --config "$GITHUB_WORKSPACE/.github/tfcmt/tfcmt.yml" \
          --output "/tmp/tgplan.md" \
          -var "target:${target}" \
          plan -patch -- terraform "$@"
fi

ここが terragrunt run-all plan コマンドを実行した時の実体のスクリプトになるのですが、その際に　tfcmt の処理を噛ませてあげる流れとなっています

以下オプションの説明になります

• –config オプション: plan 結果の整形フォーマットなどを config ファイルに書くことができます。上のステップで作成した tfcmt.yml ファイルを config として指定します

• –output オプション: tfcmt のメインの使い方は、プルリクのコメントに plan 結果を出力することだと思いますが、今回はそれを無効化しローカルにファイルに吐き出しています

• -var オプション: tfcmt に変数を渡すことができます。今回は terraform のモジュール名を渡して、tfcmt が Plan 結果を整形する際に、モジュール名も含めて出力できるようにしています

細かい仕様は 公式 doc を参照ください。

参考: https://suzuki-shunsuke.github.io/tfcmt/terragrunt-run-all

Github Actions のワークフロー

name: Execute terragrunt plan
on:
  pull_request:
    branches:
      - 'main'
    paths:
      - 'environments/develop/**'
      - 'modules/**'
  workflow_dispatch:
env:
  Enviromnet: develop
  IAM_ROLE_ARN: XXX
jobs:
  plan-common:
    runs-on: XXX
    steps:
      - uses: actions/checkout@v3

     # plan 用の権限を assume する
      - name: assume ECS Role
 　　 　uses: aws-actions/configure-aws-credentials@v4
   　　　 with:
   　　　   aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      　　　aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      　　　aws-region: ap-northeast-1

      # tfcmt のインストール
      - name: setup tfcmt
        env:
          TFCMT_VERSION: v4.13.0
        run: |
          curl -L "https://github.com/suzuki-shunsuke/tfcmt/releases/download/${TFCMT_VERSION}/tfcmt_linux_amd64.tar.gz" -o /tmp/tfcmt.tar.gz
          tar xzf /tmp/tfcmt.tar.gz -C /tmp
          mv /tmp/tfcmt /usr/local/bin
          tfcmt --version

      # terragrunt plan の実行
      - name: Excute terragrunt plan
        shell: bash
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          cd ./environments/${{ env.Enviromnet }}
          terragrunt run-all init
          chmod a+x $GITHUB_WORKSPACE/.github/tfcmt/tfwrapper.sh
          terragrunt run-all plan -no-color -input=false --terragrunt-tfpath $GITHUB_WORKSPACE/.github/tfcmt/tfwrapper.sh

      # actions の workflow summary に plan 結果の summary を通知する
      - name: Create Job Summary
        if: always()
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const fs = require('fs');
            const filePath = '/tmp/tgplan.md';
            const output = fs.readFileSync(filePath, 'utf8');
            await core.summary
              .addHeading('Terragrunt plan report')
              .addRaw(output)
              .write();

まず terragrunt plan を実行するための IAM 権限の Assume Role と、tfcmt をローカルにインストール処理を実行後、メインとなる terragrunt run-all plan を実行しています。

ここで補足した通り、tfcmt が直接 terragrunt run-all plan を実行することができないので、--terragrunt-tfpath オプションで wrapper スクリプトを呼び出し、そのスクリプト内で tfcmt を実行させています。

その後、actions/github-script@v6 を使い、tfcmt が吐き出した md ファイルを Github の Summary 部分に書き込む処理を入れています。

結果、こんな感じで Summary に環境ごとの Plan 結果をまとめることができました！

改善ポイント

使い勝手自体の改善は満足したので、このまま他のいろんなIaCリポジトリに横展開していきたいと考えています。

横展開する際、毎回 tfcmt の Config やらを設定するのは面倒なので、共通部品化して Actions モジュールを他の IaC リポジトリに配布できるといいなと考えています。機会があればチャレンジしてみようと思います。

tfcmt のおかげで Terraform の CI 体験が大分改善しそうで楽しみです！