In just a few years, Open Policy Agent (OPA) has emerged as one of the hotter technologies for policy management and fine grained access control in the cloud native ecosystem. Now it’s coming for your APIs! In this session we will explore the underlying concepts and some of the components involved in OPA before we get hands on in live coding test driven authorization policies to protect API endpoints.

1. Anders Eknert, Developer Advocate, Bisnode
Decoupling authorization decisions and other policies
Securing APIs with Open Policy
Agent

2. What’s a policy, and what’s a policy engine?
• Apolicyconsistsofa setofrules.Wemay querythesepoliciesformaking decisions.
• For the programmer – a policy may be thought of as decoupled “if – else if –
else” for when it makes sense.
• Policy engines have many use cases ranging from
authorization, data validation, infrastructure
(as code) policies, cost control, verification of configuration, and much more.
• Policy engines decouples policy decisions from enforcement.
• Policieswork togetherwithdata –ruleswithoutdata are notofmuchuse.

3. Decoupling of policies
Separating policies from enforcement (application code) has many benefits,
including:
• Some policies are “universal” –may be shared within an organization.
• Enables centralized policy management.
• Changesinpolicymay bedeployedseparatelyfromtheapplicationsusingthem.
• Makes policies discoverable – searching through application code is non-trivial.
• Shared knowledge, language and code for policy making regardless of languages
and platforms used for applications.
• Logging and auditing clearly separated from application logs.

4. Open Policy Agent
• A modern open source policy engine.
• Incubatingprojectin the CloudNativeComputingFoundation(CNCF).
OtherCNCFprojectsincludeKubernetes,Prometheus,containerdandmany
more.
• Policies represented in Rego language. Data represented as JSON.
• DevOps friendly – fits in well with infrastructure as code, distributed
environments, containerization, etc.
• Does not force organizational changes – not One True Way of using it.
• Commercial support available.
• Used bycompanieslike Netflix,Atlassian,Pinterest,andmanymore.
”The Open Policy Agent is an open source, general-purpose policy
engine”

5. Documents and data
• Data is the known state of the world with relevance for decision making.
• Policies and data together form the documents on which we base our decisions.
• While policies are normally updated infrequently, data is constantly changing. OPA provides many options
for retrieving and keeping data up-to-date – which method to use depends on the use case:
• Input – data is sent along the request and used for decisioning. Think username, roles, app state, etc.
JSON Web Tokens (JWT) natively supported.
• Push – data is pushed to OPA’s REST API at any rate which makes sense in the context.
• Bundle server – data (and possibly policies) is kept at a centralized location and fetched by OPA at a pre-
defined rate.
• Pull – data is pulled into OPA at evaluation time by the included HTTP client. Always up-to-date but at a
high cost (network calls).

6. Rego
• Declarative high-level language for writing policies, inspired by Datalog.
• Somesimilarities with SQL, but working with hierarchical structured data (JSON)ratherthan rows and tables.
• Easy to read and write! Many concepts and datatypes easily recognizable from otherlanguages and contexts.
• Rego queries essentially assertions.
• Like other declarative languages, OPA is able to optimize query execution for improved performance.
• Well documented at openpolicyagent.org

7. Rego rules
• Formatofarule:rule-nameISvalue IF body(bydefaultvalue is true butmaybeset towhatever)
• Eachline ofthe bodymust evaluatetotrueforbodytobetrue(AND)
• Rulesmayreturnobjectsof anydatatypeandcouldbeused fordatatransformations.
• Tonsofbuilt-infunctionsandhelpersforwriting policies (https://www.openpolicyagent.org/docs/latest/policy-reference/#built-in-
functions)

8. Running OPA
• OPAis aself containedsingle file (~25 MB)
executable.
• Maybecalled eitheras alibrary(Go
applicationsonly)or throughit’sRESTAPI.
• Recommendedsetupis torunOPAon the
samehostasyourapplication,eitheras a
service runningon thesameOS orasa
sidecarcontainer.
• The RESTAPI maythenbequeriedasa
localhostapplicationto ensurefastand
reliablecommunication.
Image of openpolicyagent.org

9. Testing
• Oneof the main benefits of OPA compared to the competition is howeasy it is to test policies. Given the importance
of the policies often involved (like those for authorization), this is crucial.
• Even given readable Rego policies, no language maps perfectly to intentions –tests act both to clarify intent as well
as to enforce it.
• OPA ships with it’s own framework for writing and running unit tests, allowing for test drivendevelopment (TDD) of
policies! Unit tests “offline” – does not require network.
• Veryeasy to providetest data and mockinput data.
• All the ordinary benefits oftesting apply –mucheasier toavoid regressions overtime, refactoring without fear of
breaking stuff.

10. Authorization policies
Popular models of authorization include:
• Role based access control (RBAC) –authorization decisions based on role or group membership.
• Attribute based access control – (ABAC) –authorization decisions based on any arbitrary attributes. Could be
attributes originating from an authentication, contextual attributes orentirely external attributes.
• Access Control Lists (ACL) – List of users and their attached permissions to various objects –“user Xhas read and
write permissions to objectY”.
• Most authorization systems today using one, two orall ofthe above.

11. Demo

12. Tooling
• Manytoolsshippedwith OPA
itself suchas “fmt”for
automaticformatting,”check”
forchecking Regopolicies,
“test”forrunningtests,andso
on.
• Regoplaygroundat
play.openpolicyagent.org
Fastestwaytotryit out!
• Plugin forVisualStudioCode
• Hopefullymoretocome!

13. OPA vs. alternatives
• Should policies bekept centralized, distributed with apps or something in between? Up to you!
• Howshould data be loaded into OPAand kept upto date? Again, many options.
• Many of the more “enterprise” targeted offerings dictate rules around deployment, data and policy management,
often requiring certain organizational structures (like who owns/manages the policies). What makes sense for a bank
might notmake sense fora startup.
• Many of the alternatives are only focused on authorization. OPAused for any type of policies.
• XACML, ALFA, and othersimilar languages –standardized and old, for better or worse.

14. XACML

15. Thank you