Configure an authorization extension

Service Extensions enables Application Load Balancers to send callouts to backend services to inject custom processing in the processing path. Authorization extensions run in the request processing path when the load balancer receives request headers and after the URL map chooses the backend service. This page describes how to configure authorization extensions to use a custom authorization engine defined in an authorization policy.

For an overview about Application Load Balancer extensions, see Cloud Load Balancing extensions overview.

Introduction

Cloud Load Balancing lets you configure authorization policies that enforce access control on traffic entering load balancers. Sometimes, complex authorization decisions cannot be readily expressed using an authorization policy.

You can configure authorization policies with authorization extensions to delegate authorization decisions to custom authorization engines. In the data path, authorization extensions are executed after route extensions but before traffic extensions. For each authorization request, Envoy forwards the request headers to the extension. Depending on the response from the provider, the Envoy proxy either forwards or rejects the request.

For information about the limits related to Application Load Balancer extensions, see the Quotas and limits page.

Before you begin

Create the required resources as described in Configure a callout backend service.

Configure an authorization extension

The following example shows how to configure an authorization extension, my-authz-ext, with an authorization policy to delegate authorization decisions for a regional internal Application Load Balancer in us-east1.

gcloud

  1. Configure the authorization extension.

    1. Define the extension in a YAML file that associates it with the backend service, authz-service. Use the sample values provided.

      cat >authz-extension.yaml <<EOF
    name: my-authz-ext
    authority: ext11.com
    loadBalancingScheme: INTERNAL_MANAGED
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/backendServices/authz-service
    forwardHeaders:
      - Authorization
    failOpen: false
    timeout: "0.1s"
EOF

      Replace PROJECT_ID with the project ID.

    2. Import the authorization extension. Use the gcloud beta service-extensions authz-extensions import command with the following sample values.

      gcloud beta service-extensions authz-extensions import my-authz-ext \
    --source=authz-extension.yaml \
    --location=us-east1

  2. Configure an authorization policy with the extension.

    1. Define an authorization policy that associates the extension, my-authz-ext with the forwarding rule, fr1. Use the sample values provided. The CUSTOM action indicates that an extension is being used.

      cat >authz-policy.yaml <<EOF
    name: my-authz-policy
    target:
      loadBalancingScheme: INTERNAL_MANAGED
      resources:
        - "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-east1/forwardingRules/fr1"
    action: CUSTOM
    customProvider:
      authzExtension:
        resources:
          - "projects/PROJECT_ID/locations/us-east1/authzExtensions/my-authz-ext"
EOF

    2. Import the authorization policy to the project. Use the gcloud beta network-security authz-policies import command with the following sample values.

      gcloud beta network-security authz-policies import my-authz-policy \
    --source=authz-policy.yaml \
    --location=us-east1

Limitations for authorization extensions

The following are some limitations of authorization extensions:

  • An authorization policy can have only one authorization extension.
  • A forwarding rule can be used with several authorization policies of which only one can be a custom authorization policy.
  • Cross-project referencing between extensions and a forwarding rule is not supported.

What's next