Authorization policy overview

An authorization policy 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 ended with an unauthorized response.

This page provides an overview of authorization policies for the following Application Load Balancers:

  • Global external Application Load Balancers
  • Regional external Application Load Balancers
  • Cross-region internal Application Load Balancers
  • Regional internal Application Load Balancers

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

Authorization policy rule components

An authorization policy rule has the following components:

  • 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 VM, 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: lets you define additional constraints that must be met. You can use Common Expression Language (CEL) expressions to define the constraints.
  • action: specifies the action of the rule. It can be one of ALLOW, DENY, or CUSTOM.

Authorization policy actions

When evaluating a request, an authorization policy takes any of the following actions:

  • ALLOW: grants access to the requested resource if the request matches the defined rules within the authorization policy. The authorization policy blocks access to the requested resource if the request doesn't match any defined rules within the authorization policy. A request is denied if it doesn't match an ALLOW policy, even if other policies allow it.

  • DENY: blocks access to the resource if a request matches any of the rules specified within a DENY policy. The authorization policy grants access to the requested resource if the request doesn't match any defined rules within the authorization policy. A request is denied if it matches a DENY policy, even if other policies allow it.

  • CUSTOM: enables integration with external authorization systems for complex authorization decisions. CUSTOM actions are used for policies that use service extensions or IAP for authorization decisions.

Authorization policy evaluation order

When multiple authorization policies are associated with a single resource, they are evaluated in the following order to determine whether a request is allowed or denied.

  1. Policies with CUSTOM actions: if the CUSTOM policy denies the request, the request is rejected immediately. DENY or ALLOW policies aren't evaluated, even if any are configured.

  2. Policies with DENY actions: if any DENY policies match the request, the request is denied. Any ALLOW policies aren't evaluated, even if any are configured.

  3. Policies with ALLOW actions: if there are no ALLOW policies or if any ALLOW policy matches the request, the request is allowed. However, if no ALLOW policies match the request, the request is denied.

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.

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