Authorization policy overview

Preview

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

An authorization policy (AuthzPolicy) applied on the forwarding rule of Application Load Balancers defines rules specifying the source of incoming traffic and the operations permitted or restricted for that source. Additionally, the authorization policy outlines the conditions under which a rule applies and specifies an action to either allow, deny, or further evaluate the traffic.

Authorization policies let you establish access control checks for incoming traffic to Application Load Balancers. Requests that pass these checks are routed to backend services. Requests that fail these checks are terminated with an unauthorized response.

Authorization policies can be configured on the forwarding rule of all Application Load Balancers with a load balancing scheme of EXTERNAL_MANAGED or INTERNAL_MANAGED. The following Application Load Balancers support authorization policies:

• Global external Application Load Balancers

• Regional external Application Load Balancers

• Regional internal Application Load Balancers

• Cross-region internal Application Load Balancers

In Application Load Balancers, authorization policies are invoked after evaluating route extensions, network security policies (evaluated by Google Cloud Armor), cross-origin resource sharing (CORS) policies and Identity-Aware Proxy (IAP) policies, but before executing traffic management actions. To learn more about when authorization policies are invoked in the request processing path, see Extensibility points in the load balancing data path.

If you want to use authorization policies for services deployed with Cloud Service Mesh, see Set up service security with Envoy.

Authorization policy rules

An authorization policy consists of a list of HTTP rules to match against the incoming request.

For an authorization policy with an ALLOW or DENY action, an HTTP rule (AuthzRule) defines the conditions that determine whether traffic is allowed to pass through the load balancer. At least one HTTP rule is required.

For an authorization policy with a CUSTOM action, an HTTP rule (AuthzRule) defines the conditions that determine whether traffic is delegated to the custom provider for authorization. A custom provider is required while HTTP rules are optional.

A policy match occurs when at least one HTTP rule matches the request or when no HTTP rules are defined in the policy.

An authorization policy HTTP rule consists of the following fields:

• from: specifies the identity of the client that is allowed by the rule. The identity can be derived from a client certificate in a mutual TLS connection, or it can be the ambient identity associated with the client virtual machine (VM) instance, such as from a service account or a secure tag.
• to: specifies the operations allowed by the rule, such as the URLs that can be accessed or the HTTP methods allowed.
• when: specifies additional constraints that must be met. You can use Common Expression Language (CEL) expressions to define the constraints.

Authorization policy actions

When evaluating a request, an authorization policy specifies the action (AuthzAction) to be applied on the request. An authorization policy needs to have at least one action, which can be one of the following:

• ALLOW: allows the request to pass through to the backend if the request matches any of the rules specified within an ALLOW policy. If ALLOW policies exist, but there is no match, the request is denied. In other words, the request is denied if none of the configured authorization policies with an ALLOW action match the request. In Cloud Logging, this action is logged as denied_as_no_allow_policies_matched_request.

  For an ALLOW action to be applied, you need at least one HTTP rule.

• DENY: denies the request if the request matches any of the rules specified within a DENY policy. If DENY policies exist, but there is no match, the request is allowed. In other words, the request is allowed if none of the configured authorization policies with a DENY action match the request. In Cloud Logging, this action is logged as allowed_as_no_deny_policies_matched_request.

  For a DENY action to be applied, you need at least one HTTP rule.

• CUSTOM: delegates the authorization decision to a custom authorization provider, such as IAP or service extensions. To learn more, see Use authorization policies to delegate authorization decisions.

  Note: You can define only one authorization policy with the CUSTOM action for a given forwarding rule or gateway.

  If there are HTTP rules configured for a CUSTOM policy, the request needs to match the HTTP rules to invoke the custom provider. However, if no HTTP rules are defined, then the authorization policy always delegates the authorization decision to a custom authorization provider. To learn more, see the following example where no HTTP rules are defined and the authorization policy delegates the authorization decision to an IAP:

  Create the authorization policy and enable IAP

Authorization policy evaluation order

An authorization policy supports CUSTOM, DENY, and ALLOW policies for access control. When multiple authorization policies are associated with a single resource, the CUSTOM policy is evaluated first, then the DENY policy, and finally the ALLOW policy. The evaluation is determined by the following rules:

1. If there is a CUSTOM policy that matches the request, the CUSTOM policy is evaluated using the custom authorization providers and the request is denied if the provider rejects the request. DENY or ALLOW policies aren't evaluated, even if any are configured.

2. If there are any DENY policies that match the request, the request is denied. Any ALLOW policies aren't evaluated, even if they are configured.

3. If no ALLOW policies exist, the request is allowed.

4. If any of the ALLOW policies match the request, allow the request.

5. If ALLOW policies exist, but there is no match, the request is denied. In other words, the request is denied by default if none of the configured AuthzPolicies with ALLOW action match the request.

Use authorization policies to delegate authorization decisions

For complex authorization decisions that can't be expressed using the authorization policy, delegate the authorization decision to custom authorization providers, such as Identity-Aware Proxy (IAP), or create your own authorization extension built using Service Extensions. This is useful when you want to use your on-premises authorization engine or third-party identity providers through IAP.

• IAP: configure IAP to control access to applications behind Application Load Balancer forwarding rules. IAP verifies user identity and context to determine access. It can also authenticate Identity and Access Management (IAM) service account tokens and evaluate IAM policies, protecting access to backend buckets exposed from the Application Load Balancer. For more information, see Delegate authorization to IAP and IAM.

  You might choose to delegate authentication to IAP and IAM in the following scenarios:

  • Use IAM for permission management.
  • Implement Context-Aware Access.
  • Use browser-based authentication for web applications that require interactive authentication.

• Service Extensions: delegate authorization decisions to your custom authorization engine running on Google Cloud VM instances or on-premises. This provides flexibility for complex authorization policies that are not covered by built-in policies. For more information, see Configure an authorization extension.

Authorization policy based on service accounts or tags

You can use attributes such as service accounts or tags to identify the source of traffic for internal Application Load Balancers.

For internal Application Load Balancers, you can apply authorization policies based on service accounts or tags attached to Google Cloud resources. Any traffic originating from these Google Cloud resources that are linked to a specific service account or tag can be either allowed, denied, or delegated to an external service.

Note: Applying authorization policies based on service accounts or tags isn't supported for external Application Load Balancers.

The following tables list the source resources and different Virtual Private Cloud (VPC) architectures that support the use of service accounts and tags.

Source	Service account support	Tag support
VM
GKE node
GKE container	*	*
Direct VPC for Cloud Run		*
Serverless VPC Access connector	†	†
Cloud VPN	*	*
Cloud Interconnect on premises	*	*
Application Load Balancer
Network Load Balancer

^* Not supported by Google Cloud.
^† Source IP address is unique and can be used instead.

VPC	VPC architecture	Support
Within VPC	Cross project (Shared VPC)
Within VPC	Cross region
Cross VPC	Cross peering link (peer VPC)
Cross VPC	Cross Private Service Connect
Cross VPC	Cross Network Connectivity Center spokes

To learn more about setting up an authorization policy that is based on service accounts and tags attached to a Google Cloud VM resource, see Authorization policy based on service accounts or tags.

Quotas

For information about quotas for authorization policies, see quotas and limits for authorization policies.

Pricing

Authorization policies are not charged during the Preview period. However, you incur networking charges when you use Google Cloud load balancers. For pricing information, see Pricing.

What's next

• Set up authorization policies for Application Load Balancers

• Delegate authorization to IAP and IAM

• Configure an authorization extension