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, ABAC, and conditional rules. 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 used in standalone Envoy deployments.
- Configure an AuthService resource, Point Emissary's AuthService CRD at your Cerbos PDP instance to enable external authorization on incoming requests.
- Emissary forwards requests to Cerbos, On each request, Emissary extracts identity and request metadata and sends it to Cerbos via ext_authz.
- Cerbos evaluates your policies, The same YAML policies used across your entire stack are evaluated and an allow or deny decision is returned.
- 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.
Learn more about Cerbos
Related integrations
View all integrations →
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
Authorization for AI systems
By industry
By business requirement
Useful links
What is Cerbos?
Cerbos is an end-to-end enterprise authorization software for Zero Trust environments and AI-powered systems. It enforces fine-grained, contextual, and continuous authorization across apps, APIs, AI agents, MCP servers, services, and workloads.
Cerbos consists of an open-source Policy Decision Point, Enforcement Point integrations, and a centrally managed Policy Administration Plane (Cerbos Hub) that coordinates unified policy-based authorization across your architecture. Enforce least privilege & maintain full visibility into access decisions with Cerbos authorization.