Cloud Armor のプレビューモードの動作確認をする

Cloud Armor のプレビューモードの動作確認をする

2026.02.23

こんにちは、すらぼです。

Cloud Armor のプレビューモードについて、初めて触ったので実際の挙動について調べてみました。
今回は、実際に検証用のリソースを作成し、ログの確認、フィルタまでを試してみます。

0. 準備

準備として、以下のリソースを作成します。本題ではないので、軽めの説明で進めていきます。

  • Cloud Run サービス
  • Cloud Load Balancing
    • サーバーレスNEG
  • Cloud Armor ポリシー(※自動で作成される)

Cloud Run を作る

検証用の Cloud Run サービスを作ります。
「サンプルコンテナでテスト」をクリックすると、検証用のコンテナで起動できるので、今回はこれを使用します。

CleanShot 2026-02-22 at 21.03.33.png

その他の設定は基本デフォルトで、「認証」の部分は「公開アクセスを許可する」と設定します。

CleanShot 2026-02-22 at 21.04.35.png

ロードバランサを作る

今回は全てデフォルトで作ります。

CleanShot 2026-02-22 at 21.12.42.png

フロントエンドの構成

デフォルトのまま変更なしで作成します。

バックエンドの構成

「バックエンド サービスの作成」から、

CleanShot 2026-02-22 at 21.15.39.png

「サーバーレスネットワークエンドポイントグループ」を選択し、次のステップで作成します。

CleanShot 2026-02-22 at 21.22.32.png

サーバーレスNEGは以下のように設定します。

CleanShot 2026-02-22 at 21.21.22.png

また、後述の検証のためにロギングを有効化しておきます。

CleanShot 2026-02-22 at 22.18.42.png

ロードバランサの作成が完了したら、準備完了です。

CleanShot 2026-02-22 at 21.53.29.png

動作確認のため、詳細ページにある「フロントエンド」に表示されているIPアドレスにアクセスしてみます。

CleanShot 2026-02-22 at 21.53.53.png

以下のような画面が表示されることを確認します。正しく起動できていますね。

CleanShot 2026-02-22 at 21.58.00.png

1. Cloud Armor ポリシーを作って検証する。

ここから、ルールを作っていきます。
ロードバランサを作成したときに自動で作られるポリシーがあります。このポリシーにルールを追加します。

CleanShot 2026-02-22 at 21.39.34.png

今回は自分のIPアドレスを拒否する形で検証を行います。

まずは、実際にブロックされる場合の挙動を確認するために、「プレビューのみを有効にする」にはチェックを入れずにルールを追加してみます。

CleanShot 2026-02-22 at 22.03.27.png

反映までに数分かかりますが、ブロックされると以下の 403 エラーが表示されます。

CleanShot 2026-02-22 at 22.39.42.png

また、ログにも以下のように 403 エラーが記録されています。

CleanShot 2026-02-22 at 22.38.54.png

2. プレビューモードに変えてみる。

以下のようにプレビューモードに変更してみます。

CleanShot 2026-02-22 at 22.41.25.png

すると、アクセスできるようになります。

CleanShot 2026-02-22 at 21.58.00.png

エラーログでは、実際のレスポンスコードと同じ 200 と表示されています。

CleanShot 2026-02-22 at 22.51.02.png

しかし、ログの詳細を確認すると previewSecurityPolicy というパラメータが存在し、その中ではエラーに該当するリクエストであることが判断できます。
また、enforcedSecurityPolicy では実際に適用されたルールが確認できます。

CleanShot 2026-02-22 at 22.55.12.png

この結果から、プレビューモードを使うことで実際のリクエストには影響を出さず、ルールに該当するリクエストの検証ができることがわかりました。

3. プレビューモードの結果をクエリする

プレビューモードを実際の環境で使う場合には、膨大なリクエストログの中からプレビューモードに該当するルールを検証する必要があります。
ログには以下のパラメータが含まれます。これらを組み合わせて、該当するクエリを作成することで、調査が可能です。

パラメータ 概要
name Cloud Armor ポリシーの名前
configuredAction 設定されているアクション(DENY, ALLOW など)
outcome このルールが適用された場合に想定されるアクション
preview プレビューモードの場合 true
priority 設定した優先度の値

例えば、特定のトラフィックを DENY するルールをプレビューモードで適応した際、実際にブロックされるリクエストが意図したものかどうかをチェックするには以下のようなクエリを作成します。

resource.type="http_load_balancer"
jsonPayload.previewSecurityPolicy.name="{{Cloud Armor ポリシー名}}"
jsonPayload.previewSecurityPolicy.outcome="DENY"  --このプレビュー中のポリシーによって DENY されるリクエストをフィルタ

また、下位ルールで既にDENYしているリクエストを非表示にしたい場合、以下のように1行追加することでプレビューモード単体でのブロックをフィルタすることもできます。

resource.type="http_load_balancer"
jsonPayload.previewSecurityPolicy.name="{{Cloud Armor ポリシー名}}"
jsonPayload.previewSecurityPolicy.outcome="DENY"
-jsonPayload.enforcedSecurityPolicy.outcome="DENY" --下位ルールでDENY済みのリクエストを除外

注意点: 優先度が高いルールに一致する場合は評価されない

プレビューモードでも、通常のルールと同様に「より高い優先度のルールで一致した場合は評価されない」挙動になります。

例えば、以下のようにプレビュールールと全く同じルールを、より高い優先度で設定した場合の動作を確認します。

CleanShot 2026-02-23 at 18.11.20.png

この場合は、以下の挙動となります。

  • 403 エラーが発生
  • ログには previewSecurityPolicy は記録されない(評価していないため)

ログ記録に関しては、 DENY ではなく ALLOW など、他のアクションの場合でも同様です。

そのため、プレビューモードのルールを追加しても previewSecurityPolicy を含むログが出力されない場合、より優先度が高いルールでアクションが決定されている可能性が高いです。

終わりに

今回は Cloud Armor のプレビューモードの挙動を調査してみました。実際のリクエストに影響を与えずに検証ができるため、既に稼働中の環境に対して検証を行うとき特に有効な機能です。
今回はIP制限というシンプルなルールでのみ検証しましたが、複雑なルールになると検証が困難になるためプレビューモードが役に立ちます。

この記事がどなたかの役に立てば幸いです。以上、すらぼでした。

この記事をシェアする

FacebookHatena blogX

関連記事