GraphQL Authorization with Open Policy Agent
summary
Indeed centralizes field-level GraphQL authorization using Open Policy Agent and Rego policies deployed as sidecars, with about 200 subgraphs each owning a policy package. The Apollo Router calls an Apollo Router external co-processor (TypeScript) which posts input like mutation name and user roles to OPA at path subgraph.jobs.allow; OPA returns JSON allow=true/false. If true the router proceeds, if false the co-processor replaces control to break and returns a 403. This setup yields low-latency, versioned, centralized authorization that works in production.
AI-written summary · about
chapters (10)
- 0:00Introduction and speaker intro
- 2:38Why authorization needs improvement
- 5:04Open Policy Agent overview
- 6:30Rego policy language basics
- 9:23Benefits of policy as code
- 10:27Getting policy decisions from OPA
- 12:35Deploying OPA for performance
- 15:03Apollo router external coprocessing
- 16:53Coprocessor integration code
- 19:43Summary and conclusion
related talks
19mDynamic Authorization and Policy Control for Your Kubernetes Cluster
32mOPA: So What Does the Policy Do?
16mDistributed application level RBAC with OPA
34mFine-grained Authorization in a Containerized World
17mOpen Policy Agent Intro
29mIntroduction to Open Policy Agent
25mMake Your Security Policy Auditable
32mImplementing Authorization