認可ポリシーの概要

アプリケーションロードバランサの転送ルールに適用される認可ポリシー（AuthzPolicy）は、受信トラフィックの送信元と、その送信元に対して許可または制限されるオペレーションを指定するルールを定義します。また、認可ポリシーでは、ルールが適用される条件の概要を記述し、トラフィックを許可、拒否、または詳細に評価するアクションを指定します。

認可ポリシーを使用すると、アプリケーションロードバランサへの受信トラフィックのアクセス制御チェックを確立できます。これらのチェックに合格したリクエストは、バックエンドサービスに転送されます。これらのチェックに失敗したリクエストは、未認可のレスポンスで停止します。

認可ポリシーは、ロードバランシングスキームが EXTERNAL_MANAGED または INTERNAL_MANAGED のすべてのアプリケーションロードバランサの転送ルールで構成できます。認可ポリシーをサポートするアプリケーションロードバランサは次のとおりです。

グローバル外部アプリケーションロードバランサ

リージョン外部アプリケーションロードバランサ
リージョン内部アプリケーションロードバランサ

クロスリージョン内部アプリケーションロードバランサ

アプリケーションロードバランサでは、認可ポリシーは、ルート拡張、ネットワークセキュリティポリシー（Google Cloud Armor によって評価）、クロスオリジンリソースシェアリング（CORS）ポリシー、Identity-Aware Proxy（IAP）ポリシーが評価されてからトラフィック管理アクションが実行される前までの間に呼び出されます。

リクエスト処理パスで認可ポリシーが呼び出されるタイミングの詳細については、ロードバランシングデータパスの拡張性ポイントをご覧ください。

Cloud Service Mesh でデプロイされたサービスに認可ポリシーを使用する場合は、Envoy を使用してサービスセキュリティを設定するをご覧ください。

認可ポリシールール

認可ポリシーは、受信リクエストと照合する HTTP ルールのリストで構成されています。

ALLOW アクションまたは DENY アクションを含む認可ポリシーの場合、HTTP ルール（AuthzRule）は、トラフィックがロードバランサを通過できるかどうかを決定する条件を定義します。少なくとも 1 つの HTTP ルールが必要です

CUSTOM アクションを含む認可ポリシーの場合、HTTP ルール（AuthzRule）で、トラフィックが認可のためにカスタムプロバイダに委任されるかどうかを決定する条件を定義します。カスタムプロバイダは必須ですが、HTTP ルールは省略可能です。

ポリシーが一致するのは、1 つ以上の HTTP ルールがリクエストと一致する場合、またはポリシーに HTTP ルールが定義されていない場合です。

認可ポリシーの HTTP ルールは、次のフィールドで構成されます。

from: ルールで許可されるクライアントの ID を指定します。ID は、相互 TLS 接続のクライアント証明書から取得できます。また、サービスアカウントやセキュアタグなど、クライアント仮想マシン（VM）インスタンスに関連付けられたアンビエント ID にすることもできます。
to: ルールで許可されるオペレーション（アクセス可能な URL や許可される HTTP メソッドなど）を指定します。
when: 満たす必要がある追加の制約を指定します。制約を定義するには、Common Expression Language（CEL）式を使用します。

認可ポリシーのアクション

リクエストを評価するときに、認可ポリシーはリクエストに適用するアクション（AuthzAction）を指定します。認可ポリシーには、少なくとも 1 つのアクションが必要です。アクションは次のいずれかです。

ALLOW: リクエストが ALLOW ポリシー内で指定されたいずれかのルールと一致する場合、リクエストをバックエンドに転送することを許可します。ALLOW ポリシーが存在しても一致しない場合、リクエストは拒否されます。つまり、ALLOW アクションで構成された認可ポリシーのいずれもリクエストと一致しない場合、リクエストは拒否されます。Cloud Logging では、このアクションは denied_as_no_allow_policies_matched_request としてログに記録されます。

ALLOW アクションを適用するには、少なくとも 1 つの HTTP ルールが必要です。
DENY: リクエストが DENY ポリシー内で指定されたいずれかのルールと一致する場合、リクエストを拒否します。DENY ポリシーが存在しても一致しない場合、リクエストは許可されます。つまり、DENY アクションで構成された認可ポリシーがリクエストと一致しない場合、リクエストは許可されます。Cloud Logging では、このアクションは allowed_as_no_deny_policies_matched_request としてログに記録されます。

DENY アクションを適用するには、少なくとも 1 つの HTTP ルールが必要です。
CUSTOM: 認可の決定をカスタム認可プロバイダ（IAP やサービス拡張機能など）に委任します。詳細については、認可ポリシーを使用して認可の決定を委任するをご覧ください。

注: 特定の転送ルールまたはゲートウェイに対して CUSTOM アクションで定義できる認可ポリシーは 1 つだけです。
CUSTOM ポリシーに HTTP ルールが構成されている場合、リクエストが HTTP ルールと一致してカスタムプロバイダを呼び出す必要があります。ただし、HTTP ルールが定義されていない場合、認可ポリシーは常に認可の決定をカスタム認可プロバイダに委任します。詳細については、HTTP ルールが定義されておらず、認可ポリシーが認可の決定を IAP に委任している次の例をご覧ください。

認可ポリシーを作成し、IAP を有効にする

認可ポリシーの評価順序

認可ポリシーは、アクセス制御用の CUSTOM、DENY、ALLOW ポリシーをサポートしています。1 つのリソースに複数の認可ポリシーが関連付けられている場合、最初に CUSTOM ポリシーが評価され、次に DENY ポリシーが評価され、最後に ALLOW ポリシーが評価されます。評価は次のルールによって決定されます。

リクエストに一致する CUSTOM ポリシーがある場合、カスタム認可プロバイダを使用して CUSTOM ポリシーが評価されます。プロバイダがリクエストを拒否すると、リクエストは拒否されます。DENY ポリシーまたは ALLOW ポリシーは、構成されている場合でも評価されません。
リクエストに一致する DENY ポリシーがある場合、リクエストは拒否されます。ALLOW ポリシーは、構成されている場合でも評価されません。
ALLOW ポリシーが存在しない場合、リクエストは許可されます。
ALLOW ポリシーのいずれかがリクエストと一致する場合は、リクエストを許可します。
ALLOW ポリシーが存在しても一致しない場合、リクエストは拒否されます。つまり、ALLOW アクションで構成された AuthzPolicies がリクエストと一致しない場合、リクエストはデフォルトで拒否されます。

認可ポリシーを使用して認可の決定を委任する

認可ポリシーを使用して表現できない複雑な認可の決定の場合は、Identity-Aware Proxy（IAP）などのカスタム認可プロバイダに認可決定を委任するか、サービス拡張機能を使用して独自の認可拡張機能を作成します。これは、IAP を介してオンプレミス認可エンジンまたはサードパーティ ID プロバイダを使用する場合に便利です。

IAP: アプリケーションロードバランサの転送ルールの背後にあるアプリケーションへのアクセスを制御するように IAP を構成します。IAP は、ユーザー ID とコンテキストを確認してアクセスを判断します。また、Identity and Access Management（IAM）サービスアカウントトークンを認証し、IAM ポリシーを評価して、アプリケーションロードバランサから公開されるバックエンドバケットへのアクセスを保護することもできます。詳細については、IAP と IAM に認可を委任するをご覧ください。

次のシナリオでは、認証を IAP と IAM に委任できます。
- IAM を使用して権限を管理する。
- コンテキストアウェアアクセスを実装する。
- インタラクティブな認証が必要なウェブアプリケーションには、ブラウザベースの認証を使用する。
Service Extensions: Google Cloud VM インスタンスまたはオンプレミスで実行されているカスタム認可エンジンに認可決定を委任します。これにより、組み込みポリシーでカバーされていない複雑な認可ポリシーを柔軟に設定できます。詳細については、認可拡張機能を構成するをご覧ください。

プリンシパルに基づく認可ポリシー

トラフィックのソースを高い粒度で識別するには、クライアントの証明書から派生した ID に基づいて認可ポリシーを構成します。この方法では、ロードバランサでフロントエンド mTLS を有効にする必要があります。また、次の証明書属性を識別用のプリンシパルセレクタとして使用します。

クライアント証明書の URI SAN（CLIENT_CERT_URI_SAN）
クライアント証明書の DNS 名 SAN（CLIENT_CERT_DNS_NAME_SAN）
クライアント証明書の共通名（CLIENT_CERT_COMMON_NAME）

識別用のプリンシパルセレクタが指定されていない場合、CLIENT_CERT_URI_SAN がデフォルトのプリンシパルセレクタとして使用されます。つまり、認可を判断する際に、クライアント証明書の URI SAN が評価されます。

プリンシパルベースの認可が機能するには、次の条件を満たしている必要があります。

フロントエンド mTLS が有効になっている。フロントエンド mTLS が有効になっていない場合、クライアントは証明書を提示しません。その結果、認可ポリシーのプリンシパルベースのルールは、評価する証明書情報を見つけられません。たとえば、CLIENT_CERT_URI_SAN をチェックするルールは空の値を確認します。
有効なクライアント証明書が存在する。mTLS が有効になっていても、欠落している証明書または無効な証明書で接続が確立された場合、クライアント証明書は認可に使用されません。このシナリオは、mTLS クライアント検証モードが permissive モード ALLOW_INVALID_OR_MISSING_CLIENT_CERT に設定されている場合に発生します。この場合も、認可ポリシーのプリンシパルベースのルールは、評価する証明書情報を見つけられません。たとえば、CLIENT_CERT_URI_SAN をチェックするルールは空の値を確認します。

属性のサイズ上限の影響

認可の決定は、クライアント証明書の属性のサイズに影響されます。属性がサイズの上限を超え、その特定の属性を検証するようにポリシーが構成されている場合、リクエストは拒否されます。

却下されるのは、次のような場合です。

ポリシーが CLIENT_CERT_URI_SAN に対して検証され、証明書の URI SAN がサイズ上限を超えている。
ポリシーが CLIENT_CERT_DNS_NAME_SAN に対して検証され、証明書の DNS 名 SAN がサイズ上限を超えている。
ポリシーが CLIENT_CERT_COMMON_NAME に対して検証され、証明書のサブジェクト（共通名を含む）がサイズの上限を超えている。

証明書の属性がサイズ上限を超えていても、ポリシーのプリンシパルセレクタによって明示的に検証されていない場合、リクエストは構成されたプリンシパルルールに対して評価されます。このため、たとえば CLIENT_CERT_DNS_NAME_SAN のみを検証するようにポリシーが構成されていると、URI SAN が大きすぎるクライアントからのリクエストは拒否されません。ポリシーは、DNS 名 SAN に基づいてリクエストの評価に進みます。

サービスアカウントまたはタグに基づく認可ポリシー

サービスアカウントやタグなどの属性を使用して、内部アプリケーションロードバランサのトラフィックのソースを識別できます。

内部アプリケーションロードバランサの場合は、 Google Cloud リソースに接続されているサービスアカウントまたはタグに基づいて認可ポリシーを適用できます。特定のサービスアカウントまたはタグにリンクされているこれらの Google Cloud リソースから発生するトラフィックは、許可することも、拒否することも、外部サービスに委任することもできます。

次の表に、サービスアカウントとタグの使用をサポートするソースリソースとさまざまな Virtual Private Cloud（VPC）アーキテクチャを示します。

ソース	サービスアカウントのサポート	タグのサポート
VM
GKE ノード
GKE コンテナ	*	*
Cloud Run のダイレクト VPC		*
サーバーレス VPC アクセスコネクタ	†	†
Cloud VPN	*	*
オンプレミスの Cloud Interconnect	*	*
アプリケーションロードバランサ
ネットワークロードバランサ

^* Google Cloudではサポートされていません。

^† 送信元 IP アドレスは一意であるため、代わりに使用できます。

VPC	VPC アーキテクチャ	サポート
VPC 内	プロジェクト間（共有 VPC）
VPC 内	クロスリージョン
VPC 間	ピアリング間リンク（ピア VPC）
VPC 間	Private Service Connect 間
VPC 間	Network Connectivity Center スポーク間

サービスアカウントと Google Cloud VM リソースに適用されたタグに基づく認可ポリシーの設定の詳細については、サービスアカウントまたはタグに基づく認可ポリシーをご覧ください。

割り当て

認可ポリシーの割り当てについては、認可ポリシーの割り当てと上限をご覧ください。

料金

プレビュー期間中は、認証ポリシーの料金は発生しません。ただし、 Google Cloud ロードバランサを使用すると、ネットワーク料金が発生します。料金については、こちらをご覧ください。

次のステップ

アプリケーションロードバランサの認可ポリシーを設定する