アプリケーション ロードバランサの転送ルールに適用される認可ポリシー（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 インスタンスまたはオンプレミスで実行されているカスタム認可エンジンに認可決定を委任します。これにより、組み込みポリシーでカバーされていない複雑な認可ポリシーを柔軟に設定できます。詳細については、認可拡張機能を構成するをご覧ください。
プリンシパルに基づく認可ポリシー
トラフィックのソースを高い粒度で識別するには、クライアントの証明書から派生した 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 ロードバランサを使用すると、ネットワーク料金が発生します。料金については、こちらをご覧ください。