アプリケーション ロードバランサの転送ルールに適用される認可ポリシー（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ポリシーに HTTP ルールが構成されている場合、リクエストが HTTP ルールと一致してカスタム プロバイダを呼び出す必要があります。ただし、HTTP ルールが定義されていない場合、認可ポリシーは常に認可の決定をカスタム認可プロバイダに委任します。詳細については、HTTP ルールが定義されておらず、認可ポリシーが認可の決定を 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 インスタンスまたはオンプレミスで実行されているカスタム認可エンジンに認可決定を委任します。これにより、組み込みポリシーでカバーされていない複雑な認可ポリシーを柔軟に設定できます。詳細については、認可拡張機能を構成するをご覧ください。
サービス アカウントまたはタグに基づく認可ポリシー
サービス アカウントやタグなどの属性を使用して、内部アプリケーション ロードバランサのトラフィックのソースを識別できます。
内部アプリケーション ロードバランサの場合は、 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 ロードバランサを使用すると、ネットワーク料金が発生します。料金については、こちらをご覧ください。