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

Authorization policies let you establish access control checks for incomingtraffic to Application Load Balancers. Requests that pass these checks are routedto backend services. Requests that fail these checks are terminated with anunauthorized response.

Authorization policies can be configured on the forwarding rule of allApplication Load Balancers with aload balancing scheme ofEXTERNAL_MANAGED orINTERNAL_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 invokedafterevaluating route extensions, network security policies (evaluated byGoogle Cloud Armor), cross-origin resource sharing (CORS) policies andIdentity-Aware Proxy (IAP) policies, butbefore executing traffic managementactions.

To learn more about when authorization policies are invoked in therequest processing path, seeExtensibility points in the load balancing datapath.

If you want to use authorization policies for services deployed withCloud Service Mesh, seeSet up service security withEnvoy.

Authorization policy rules

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

For an authorization policy with anALLOW orDENY action, an HTTP rule(AuthzRule) defines the conditions that determine whether traffic is allowedto pass through the load balancer. At least one HTTP rule is required.

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

A policy match occurs when at least one HTTP rule matches the request or when noHTTP 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 TLSconnection, or it can be the ambient identity associated with the clientvirtual 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 thatcan be accessed or the HTTP methods allowed.
• when: specifies additional constraints that must be met. You can useCommon Expression Language(CEL) expressionsto 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 tohave at least one action, which can be one of the following:

• ALLOW: allows the request to pass through to the backend if the requestmatches any of the rules specified within anALLOW policy. IfALLOWpolicies exist, but there is no match, the request is denied. In otherwords, the request is denied if none of the configuredauthorization policies with anALLOW action match the request. InCloud Logging, this action is logged asdenied_as_no_allow_policies_matched_request.

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

• DENY: denies the request if the request matches any of the rules specifiedwithin aDENY policy. IfDENY policies exist, but there is no match, therequest is allowed. In other words, the request is allowed if none of theconfigured authorization policies with aDENY action match the request. InCloud Logging, this action is logged asallowed_as_no_deny_policies_matched_request.

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

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

  Note: You can define only one authorization policy with theCUSTOM actionfor a given forwarding rule or gateway.

  If there are HTTP rules configured for aCUSTOM policy, the request needsto match the HTTP rules to invoke the custom provider. However, ifno HTTPrules are defined, then the authorization policy always delegates theauthorization decision to a custom authorization provider. To learn more,see the following example where no HTTP rules are defined and theauthorization policy delegates the authorization decision to anIAP:

  Create the authorization policy and enableIAP

Authorization policy evaluation order

An authorization policy supportsCUSTOM,DENY, andALLOW policies foraccess control. When multiple authorization policies are associated with asingle resource, theCUSTOM policy is evaluated first, then theDENY policy,and finally theALLOW policy. The evaluation is determined by the followingrules:

1. If there is aCUSTOM policy that matches the request, theCUSTOM policyis evaluated using the custom authorization providers and the request isdenied if the provider rejects the request.DENY orALLOW policiesaren't evaluated, even if any are configured.

2. If there are anyDENY policies that match the request, the request isdenied. AnyALLOW policies aren't evaluated, even if they are configured.

3. If noALLOW policies exist, the request is allowed.

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

5. IfALLOW policies exist, but there is no match, the request is denied. Inother words, the request is denied by default if none of the configuredAuthzPolicies withALLOW action match the request.

Use authorization policies to delegate authorization decisions

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

• IAP: configure IAP to control access toapplications 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 tokensand evaluate IAM policies, protecting access to backendbuckets exposed from the Application Load Balancer. For more information, seeDelegate authorization to IAP andIAM.

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

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

• Service Extensions: delegate authorization decisions to yourcustom authorization engine running on Google Cloud VM instances oron-premises. This provides flexibility for complex authorization policiesthat aren't covered by built-in policies. For more information, seeConfigure an authorization extension.

Authorization policy based on principals

To identify the source of traffic with high granularity, you can configureauthorization policies based on identities derived from a client's certificate.This method requiresfrontend mTLS to be enabled onthe load balancer and uses the following certificate attributes as aprincipalselector for identification:

• Client certificate URI SANs (CLIENT_CERT_URI_SAN)
• Client certificate DNS Name SANs (CLIENT_CERT_DNS_NAME_SAN)
• Client certificate Common Name (CLIENT_CERT_COMMON_NAME)

If no principal selector is specified for identification,CLIENT_CERT_URI_SANis used as the default principal selector. This means that the clientcertificate's URI SANs are evaluated when making authorization decisions.

For principal-based authorization to work, the following conditions must apply:

• Frontend mTLS must be enabled. If frontend mTLS isn't enabled,the client doesn't present a certificate. As a result,any principal-based rules in the authorization policy find nocertificate information to evaluate.For example, a rule checkingCLIENT_CERT_URI_SAN sees an empty value.

• There must be a valid client certificate. Even with mTLS enabled, aclient certificate isn't used for authorization if the connection wasestablished with a missing or an invalid certificate. This scenario occurswhen the mTLS client validation mode is set to the permissive modeALLOW_INVALID_OR_MISSING_CLIENT_CERT.In this case as well,any principal-based rules in the authorization policy find nocertificate information to evaluate.For example, a rule checkingCLIENT_CERT_URI_SAN sees an empty value.

Impact of attribute size limits

Authorization decisions are sensitive to the size of client certificateattributes. A request isrejected if an attribute exceeds its size limit andthe policy is configured to validate that specific attribute.

A rejection can occur under the following conditions:

• The policy validates againstCLIENT_CERT_URI_SAN, and the certificate's URISANs exceed the size limit.
• The policy validates againstCLIENT_CERT_DNS_NAME_SAN, and the certificate'sDNS Name SANs exceed the size limit.
• The policy validates againstCLIENT_CERT_COMMON_NAME, and the certificate'sSubject (which contains the Common Name) exceeds the size limit.

If a certificate's attribute exceeds its size limit but isnot explicitlyvalidated by the policy's principal selector, the request is still evaluatedagainst the configured principal rules. For example, if a policy is configuredto validate only theCLIENT_CERT_DNS_NAME_SAN, a request from a client withoversized URI SANs is not rejected for that reason. The policy proceeds toevaluate the request based on its DNS Name SANs.

To see an example of an authorization policy based on principals,seeAuthorization policy to deny requests.

Authorization policy based on service accounts or tags

You can use attributes such asservice accounts ortags to identify the source of trafficfor internal Application Load Balancers.

For internal Application Load Balancers, you can apply authorization policies based on serviceaccounts or tags attached to Google Cloud resources. Any trafficoriginating from these Google Cloud resources that are linked to aspecific service account or tag can be either allowed, denied, or delegatedto an external service.

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

Quotas

For information about quotas for authorization policies, seequotas andlimits for authorization policies.

Pricing

For pricing information, seePricing.

What's next

• Set up authorization policies forApplication Load Balancers

• Delegate authorization to IAP andIAM

• Configure an authorization extension