The OPA is an open-source, general-purpose policy engine that can be used to enforce policies on various types of software systems like micro services, CI/CD pipelines, gateways, Kubernetes, etc. OPA was developed by Styra and is currently a part of CNCF.

1. Presented By: Rahul Soni
OPA - Open Policy Agent

2. Lack of etiquette and manners is a huge turn off.
KnolX Etiquettes
Punctuality
Join the session 5 minutes prior to
the session start time. We start on
time and conclude on time!
Feedback
Make sure to submit a constructive
feedback for all sessions as it is
very helpful for the presenter.
Silent Mode
Keep your mobile devices in silent
mode, feel free to move out of
session in case you need to attend
an urgent call.
Avoid Disturbance
Avoid unwanted chit chat during
the session.

3. Our Agenda
01 Open Policy Agent
02 what is OPA? Need of OPA
03 OPA with Kubernetes
04 Rego Lang - Policies & Rules
05 Demo

4. Open Policy Agent
● The Open Policy Agent (OPA, pronounced “oh-pa”) is an open
source, general-purpose policy engine that unifies policy
enforcement across the stack. OPA provides a high-level
declarative language that lets you specify policy as code and
simple APIs to offload policy decision-making from your
software.
● OPA embraces policy-as-code, complete with tools that help
people use and understand the policies they put in place.
Introduction

5. Open Policy Agent
OPA generates policy decisions by evaluating the query input against policies and data. OPA and Rego
are domain-agnostic so you can describe almost any kind of invariant in your policies. For example:
● Which users can access which resources.
● Which subnets egress traffic is allowed to.
● Which clusters a workload must be deployed to.
● Which registries binaries can be downloaded from.
● Which OS capabilities a container can execute with.
● Which times of day the system can be accessed at.
● Policy decisions are not limited to simple yes/no or allow/deny answers. Like query inputs, your
policies can generate arbitrary structured data as output.
Overview

6. Why we need Open Policy Agent ?
● Suppose we have a service deployed somewhere on a
VM, Docker or maybe in kubernetes.
● Now, we have multiple clients and they can access our
service inside the environment. But we only want few of
them to make request to our service.
● In the right side picture you can see in same
environment all clients can access the service because
the are in same namespace of network or environment.
● How we gonna restrict bad clients to access service?
Scenario - 1
Service
bad client
Nice client

7. Why we need Open Policy Agent ?
● Suppose in a kubernetes clusters we have 2
namespaces as Production and Non-prod.
● We want to restrict that only *.knoldus.com ingress
hostname are allowed in production.
● We want to restrict that only test.*.knoldus.com ingress
hostname are allowed in Non-production.
● How we gonna do that on top of kubernetes ?
Scenario - 2
Ingress
Production - namespace
home.app.knoldus.com
Ingress
Non-prod - namespace
test.app.knoldus.com

8. OPA in Game

9. Why we need Open Policy Agent ?
● Suppose we have a service deployed somewhere on a
VM, Docker or maybe in kubernetes.
● Now, we have multiple clients and they can access our
service inside the environment. But we only want few of
them to make request to our service.
● In the right side picture you can see in same
environment all clients can access the service because
the are in same namespace of network or environment.
● How we gonna restrict bad clients to access service?
Scenario - 1
Service
bad client
Nice client
Request Query
JSON
Decision Query
JSON
Policies &
Data

10. Why we need Open Policy Agent ?
● Suppose in a kubernetes clusters we have 2
namespaces as Production and Non-prod.
● We want to restrict that only *.knoldus.com ingress
hostname are allowed in production.
● We want to restrict that only test.*.knoldus.com ingress
hostname are allowed in Non-production.
● How we gonna do that on top of kubernetes ?
Scenario - 2
Ingress
Production - namespace
home.app.knoldus.com
Ingress
Non-prod - namespace
test.app.knoldus.com
OPA Admission
Controller

11. OPA with Kubernetes ?
● In Kubernetes, Admission Controllers enforce policies on objects
during create, update, and delete operations. Admission control
is fundamental to policy enforcement in Kubernetes.
● OPA can be deployed as an admission controller in kubernetes
which talks to kube API server to make final decision for request
coming from client.
● The Kubernetes API Server is configured to query OPA for
admission control decisions when objects (e.g., Pods, Services,
etc.) are created, updated, or deleted

12. Rego Lang - Policies & Rules
● Rego was inspired by Datalog, which is a well understood,
decades old query language. Rego extends Datalog to support
structured document models such as JSON.
● Rego queries are assertions on data stored in OPA. These
queries can be used to define policies that enumerate
instances of data that violate the expected state of the
system.
What is Rego Lang?
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "Pod"
image := input.request.object.spec.containers[_].image
not startswith(image, "hooli.com/")
msg := sprintf("image '%v' comes from untrusted registry",
[image])
}
Policy & Rules

13. Demo

14. Thank You !