🔐 New: A CISO’s benchmark for authorization maturity ➔ [Download the ebook](https://solutions.cerbos.dev/authorization-maturity-model-a-cisos-benchmark)

# Policy-driven authorization for Gloo Gateway via Envoy ext_authz

Cerbos enforces fine-grained authorization at the Gloo Gateway edge, using the same Envoy ext_authz protocol that powers the native Envoy integration.

### Built on Envoy ext_authz

Gloo Gateway uses Envoy as its data plane, so Cerbos integrates via the same native ext_authz protocol

### Unified policies

The same Cerbos policies that govern your application layer extend to your API gateway

### Gateway-level enforcement

Unauthorized requests are rejected at the gateway before reaching your services

## How Cerbos works with Gloo Gateway

Gloo Gateway provides a native integration point for Cerbos, extending policy-driven authorization to another layer of your stack without custom glue code.

Cerbos policies are written in human-readable YAML supporting [RBAC](/content/features-benefits-and-use-cases/rbac/index.html), [ABAC](/content/features-benefits-and-use-cases/abac/index.html), and [conditional rules](/content/features-benefits-and-use-cases/pbac/index.html). The same policies that govern your application layer now extend to Gloo Gateway, enforced consistently everywhere.

A unified control plane means one set of policies, one audit trail, and one management workflow, regardless of how many services and infrastructure layers your system spans.

[Policy-as-code Human-readable YAML policies managed like source code](/content/features-benefits-and-use-cases/human-readable-authorization/index.html) [Scalable PDP Stateless policy decision point with sub-millisecond latency](/content/features-benefits-and-use-cases/scalability/index.html) [Centralized management Manage, test, and deploy policies from a single control plane](/content/features-benefits-and-use-cases/centralized-management/index.html)

### How Cerbos works with Gloo Gateway

Gloo Gateway is an Envoy-based API gateway from Solo.io. Because it uses Envoy as its data plane, Cerbos integrates via the same [ext_authz gRPC protocol](/content/ecosystem/cerbos-envoy/index.html) used in standalone Envoy deployments.

1. **Configure an AuthConfig resource**: Define an AuthConfig in Gloo that points to your Cerbos PDP as an external authorization service.
2. **Gloo forwards requests to Cerbos**: On each request, Gloo extracts identity and request metadata and sends it to Cerbos via ext_authz.
3. **Cerbos evaluates your policies**: The same YAML policies used across your entire stack are evaluated and an allow or deny decision is returned.
4. **Gloo enforces the decision**: Authorized requests are routed to your upstream services. Unauthorized requests receive a 403.

## FAQ

### How does Cerbos integrate with Gloo Gateway?

Gloo Gateway is built on Envoy, so it inherits Envoy's ext_authz protocol. Cerbos acts as the external authorization service — Gloo forwards each request to Cerbos for policy evaluation before routing to your upstream services.

### Is this the same integration as Envoy?

Yes. Gloo Gateway uses Envoy as its data plane. The Cerbos integration uses the same ext_authz gRPC protocol, same policy evaluation, and same configuration. You configure ext_authz via Gloo's AuthConfig resource.

### Do I need to change my application code?

No. Authorization happens at the gateway layer. Your services receive only pre-authorized traffic.

## Cerbos + Gloo Gateway

- Gloo Gateway delegates authorization to Cerbos via native integration
- One set of policies enforced across the entire stack
- Unified audit trail for all authorization decisions
- Policies managed without code changes or redeployments
