# Policy-driven authorization for Emissary-Ingress via Envoy ext_authz

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

### Built on Envoy ext_authz

Emissary-Ingress 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 Kubernetes ingress

### Ingress-level enforcement

Unauthorized requests are rejected at the gateway before reaching your services

## How Cerbos works with Emissary-Ingress (Ambassador)

Emissary-Ingress (Ambassador) 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 Emissary-Ingress (Ambassador), 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.

### How Cerbos works with Emissary-Ingress

Emissary-Ingress is a Kubernetes-native API gateway built on Envoy. 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 AuthService resource**: Point Emissary's AuthService CRD at your Cerbos PDP instance to enable external authorization on incoming requests.
2. **Emissary forwards requests to Cerbos**: On each request, Emissary 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. **Emissary enforces the decision**: Authorized requests are routed to your upstream services. Unauthorized requests receive a 403.

## FAQ

### How does Cerbos integrate with Emissary-Ingress?

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

### Is this the same integration as Envoy?

Yes. Emissary-Ingress uses Envoy as its data plane. The Cerbos integration uses the same ext_authz gRPC protocol, same policy evaluation, and same configuration. The only difference is how you configure the AuthService resource in Emissary.

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

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

## Cerbos + Emissary-Ingress (Ambassador)

- Emissary-Ingress (Ambassador) 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.