Authorization policy overview

This page describes authorization policies that let you establish access control checks for incoming traffic to Envoy-based Application Load Balancers. Requests that pass these checks are routed to backend services. Requests that fail these checks are ended with an unauthorized response.

An authorization policy is a set of rules that define the source of the incoming traffic and a set of operations allowed or denied for the source. An authorization policy also specifies conditions must be met for the rule to be applied and specifies an action that determines whether traffic is to be allowed, denied, or evaluated further.

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