►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
The Battle of Policies: OPA’s Rego vs. JSON Schema - Shimon Tolts, Datree
Virtual Track
Speakers: Shimon Tolts
On the one hand, it’s well known that OPA's Rego is very popular and easy to get started with, but hard to master. On the other hand, JSON Schema is considered one of the fundamental libraries for validating manifests… but which one is THE ONE for you? In this talk, we'll battle it out head to head with the two ultimate libraries OPA's Rego and JSON Schema. We'll test both of the solutions by validating Kubernetes manifests against real-life use cases and review their pros and cons. We’ll explore how we can integrate each one of them into the CI/CD pipeline, and learn how they work under the hood. Finally, we’ll make the case for which one to use in which scenario. May the best config language win!
A
Hi
silicon
welcome
to
my
talk,
the
battle
of
policies,
oppa
oppas
rego
versus
json
schema.
Thank
you
very
much
for
coming
on.
My
name
is
shimon
told,
and
I
made
this
talk,
because
this
is
something
really
personal
that
we
experienced
and
I
personally
experienced,
and
I
would
like
to
share
it
with
you.
So
I'm
just
gonna
share
my
slides
here
and
in
this
talk,
what
we're
going
to
do
is
we're
going
to
talk
about
why
you
would
want
to
use
either
one
of
them
and
then.
A
Secondly,
what
are
the
advantages
and
disadvantages
of
the
different
usages
of
oppa
oppas
rego
and
the
json
schema,
so
let's
jump
into
it.
So
my
name
is
shimon.
I'm
the
ceo
and
co-founder
of
the
tree
and
the
tree
is
a
company
that
prevents
misconfigurations
in
cloud
native
workloads
such
as
kubernetes,
so
I'm
also
very
active
within
the
community.
A
So,
let's
talk
about
how
we
even
got
to
here
so
what
we
provide
the
trees,
a
solution
to
prevent
these
configurations
in
cloud
native
workloads
and
we
help
delegate
infrastructures,
code
responsibilities
and
kubernetes
responsibilities
to
dev
teams.
So
it's
an
open
source,
centralized
policy
engine
that
allows
companies
to
actually
define
policies
and
we're
going
to
talk
a
lot
about
policies
today
and
integrate
them
within
the
cicd
within
the
dev
platforms,
let's
say
vs
code
or
actually
even
as
an
admission
controller
web
hook
inside
your
kubernetes,
and
this
really
allows
you
to
configure
rules.
A
Let's
say
you
want
to
make
sure
that
there's
a
memory
limit,
cpu
limit,
liveness
pro
readiness
probe
in
your
ci
cd
pipeline,
for
example-
and
you
know,
in
order
to
to
get
deeper
into
examining,
should
we
use
oppas,
rego
or
json
schema.
Let's
look
at
what
types
of
misconfigurations
do
we
want
to
identify
in
order
to
test
out
which
engine
do
we
want
to
actually
use
if
you
were
to
maybe
run
to
build
your
own
policies
or
build
your
own
solution
so
number
one.
A
When
people
write
a,
you
know
configuration
files,
whether
it
is
helm,
charts
or
a
jumble
files,
and
so
on
number
one.
You
want
to
identify
syntax
errors
want
to
make
sure
that
it's
even
a
valid
yaml.
You
know.
Secondly,
you
want
to
make
sure
that
this
yaml,
for
example,
is
a
valid
schema.
So
kubernetes
has
different
versions
and,
let's
say
the
latest
one
in
aws
to
this
date
is
1.22,
so
it
runs
a
specific
schema
version.
A
Secondly,
we
want
to
really
delegate
the
knowledge
and
really
help
people
in
our
organization
make
the
right
thing
by
applying
policies
within
the
pipeline.
So
let's
say
I
want
people
to
pull
docker
containers
that
are
not
using
the
latest
tag,
but
have
a
specific
tag,
a
specific
version,
a
specific
shop
and
so
by
writing
a
policy
that
prevents
you
from
actually
pulling
a
docker
with
the
latest
tag.
A
And
thirdly,
we
want
to
to
make
team
alignment.
So
maybe
there
are
some
rules
and
policies
that
we
want
to
actually
configure
that
are
not
industry,
best
practices
they're
specific
to
our
company.
So
maybe
we
have
a
private
docker
registry
and
we
want
people
to
only
pull
images
from
this
doc
registry,
or
maybe
we
have
different
configurations,
different
labels
that
we
want
to
apply.
All
of
those
things
can
be
achieved
by
using
a
custom
policies
and
by
centralized
policy
solutions.
A
So,
as
we
said,
we
want
to
enforce
best
practices
and
define
the
policies
that
we
want.
So
let's
say
you
want
to
make
sure
that
you
have
a
cron
job
deadline,
and
so
it
won't
really
go
forever.
You
want
to
make
sure
that
you
have
a
liveness
probe
and
readiness
probe
and
docker
registry
and
resource
limits
like
cpu
and
memory,
and
you
really
want
to
distribute
all
those
policies
inside
of
your
ci
cd
pipeline.
A
So
now
you're
saying:
okay,
shimon!
You,
you
convinced
me,
I
want
to
implement
policies
in
order
to
achieve
all
of
those
great
things
but
which
policy
engines
should
I
adopt,
and
this
is
why
we're
here-
and
this
is
actually
the
question
that
we
asked
ourselves
so
for
our
engine-
that
we
want
to
use.
Should
we
enable
our
customers
to
write
custom
policies
and
submitting
them
to
us
using
oppa's,
rego
language
or
by
using
json
schema,
and
we
went
into
this
journey
and
you
know
when
you
go
deeper
down
the
rabbit
hole.
A
A
A
What
you
write
is
what
you
see,
because
you
know
when,
when
writing
a
tests
in
a
way
you
want
it
to
be
as
intuitive
as
you
can,
and
this
is
the
journey
that
that
we
went
into
so,
let's
start
with
the
first
one
rego.
So
what
is
rego
so
rego
is
a
language
that
was
developed
by
a
oppa
open
policy
agent,
which
is
a
graduated
project
of
the
cncf.
The
cloud
native
foundation
and
rego
is
actually
the
official
language
of
the
oppa
open
policy
agent.
A
A
So
what
is
the
syntax?
So
it
is
designed
to
to
really
be
easy
to
read.
Policies
and
rego
goes
and
runs
against
the
json
data
scheme,
and
then
it
applies
different
tests
and
decision
making
and
it
it's
more
like
a
query
language.
So
you
it
reads
the
the
data
that
you
have,
that
you
provide
it
and
then
it
applies
different,
logical
queries
and
it
decides
whether
it
abides
by
the
policy
or
not.
A
Very
interestingly,
today,
the
example
that
I'm
giving
is
around
misconfigurations
and
config
files,
but,
for
example,
there
are
many
companies
like
pyramid.io
that
do
authorization
as
a
service
and
they
use
oppa
and
rego
because
they
want
to
verify
whether
a
person
has
access
to
a
resource.
So
it's
it's
like
a
completely
different
use
case,
but
it
also
works
with
policies.
You
can
say
I
have
this
object.
Can
this
person
perform
this
action
and
does
it
work
according
to
the
policy
or
not?
A
So
how
does
it
actually
work?
There
are
three
main
layers,
so
there's
a
rules,
definition
there's
the
import
statement
that
a
you
use
and
then
there's
the
a
package
that
you
execute.
So
here
we
have
package
main.
This
is
the
package
itself
and
then
it
will
pass
if
the
the
the
data
that
we
passed
to
it
input
it
has
an
as
a
attribute
method
that
is
equal
get
and
if
not,
it
will
not
allow
it.
It
will
fail
so
actually
rego
supports
modules.
A
A
So
what
is
the
input
and
input
is
a
a
data
keyword
that
is
saved.
You
can't
use
this
keyword
and
any
time
you
execute
a
test,
you
actually
have
to
go
and
a
query.
This
input
a
variable
and
and
apply
different
tests
to
it.
So
you
can
go
and
say:
does
this
input
has
the
label
environment
and
is
the
label
environment
a
par,
a
qa,
dev
or
test,
and
you
actually
query
it
inside
so
the
output
is
again
is,
is
in
json
documents
and,
and
you
can
work
and
query
your
data
in
it.
A
So
how
do
you
actually
implement
a
regular
statement?
So
if
we
go
and
look
at
a
regular
example
in
javascript-
and
we
can
look
at
a
a
regular
example,
so
it's
the
same
example
as
I
showed
you
now,
so
you
have
an
allow
flag
that
says
it
will
pass
if
the
data
that
we
pass
to
it
input
has
a
method
of
get.
A
So
it
is
really
straightforward.
It
tells
you
what
it
is
doing
and
it
is
really
straightforward
to
understand
under
the
hood
there
are.
You
can
use
many
different
if
blocks
end
blocks
or
blocks,
so
you
can
have
a
really
a
variety
of
a
rule.
Sets
that
that
that
you
can
build
on
top
of
them
and
on
top
of
them,
and
you
can
end
something
in
or
an
orange
create,
really
complex
a
test
cases.
If,
if
you
need
so.
A
So
in
this
case,
we
see
that
we
have
two
allow
statements.
The
first
one
is
the
same
input
method
get
the
second
one
is
check.
If
it
is
post,
then,
if
the
user
is
an
admin
and
again
if
one
of
them
does
not
return
a
true,
if
it
does
not
exist,
then
it
will
fail
and
the
way
it
works
is
really.
Let's
say
you
have.
A
A
A
It
is
provides
a
clear
human
and
machine,
readable
interface,
so
it
is
on
on
both
sides
really
really
conv
convenient
and-
and
it
really
helps
you
validate
data
like
for
automated
testing
quality
and
so
on
now,
as
opposed
to
rego
and
so
rego
is
only
implemented
in
oppa
and
oppa
is
a
very
specific,
so
you
actually
need
to
bring
gopa
and
and
really
always
use
it.
Json
is
the
old
good
json,
you
all
know
json.
We
know
json
for
years
we
know
json,
we
used
to
know
xml.
A
Now
we
know
json
and
you
know
yaml.
We
know
thomas
so
really
because
it's
really
json
schema
is
a
wide
applicable
standard.
So
what
happens
is
that
there
are
many
many
many
like
a
lot
of
packages
that
implemented
this
spec
and
almost
every
possible
language.
Has
it
and
you
can
use
it
everywhere
you
want,
and
so
I
don't
think
anyone's
gonna.
Be
too
surprised
here,
it's
a
json,
it's
it's
really
simple,
so
hello
world
for
json
schema
just
json
and
I'm
not
gonna
educate
you
on
json.
A
But
let's
let's
talk
about
json
schema,
so
you
define
a
schema
and
then
you
have
a
data
and
then
you
check
whether
it
it
corresponds
and
whether
it
works.
So
here
is
an
example.
There
is
an
id
title
and
so
on,
and
it
says
that
it's
an
example
of
a
person
and
the
person
has
the
properties
of
first
name,
which
should
be
of
type
string
and
it
will
describe
the
person's
name
and
last
name.
A
A
This
cannot
be
a
string
and
vice
versa.
So
you
define
the
schema
and
then
you
pass
in
data
and
you
validate
it.
I
know
crazy
right,
very
simple.
Another
example,
so
in
this
example
we're
doing
longitude
and
latitude.
So
again
you
define
the
properties.
In
this
case,
we
have
a
latitude,
it's
a
number,
you
can
give
it
scoping
minimum
maximum,
and
then
you
pass
it
data.
So,
as
you
see
very
similar
to
rego,
you
can
start
going
deeper
and
deeper.
A
A
I
chose
to
to
show
one
example
of
a
very
popular
open
source
repository
module
in
javascript
because
everyone
loves
and
hates
javascript.
So
I
chose
javascript
and
then
it's
like
at
11,
000
stars,
repo
and
here's
an
example.
So
it's
called
agv.
So
there's
a
schema,
it
says:
there's
an
object
properties
foo
in
bars.
One
is
an
integer.
The
second
one
is
a
string
and
who
is
required
and
then
you
just
pass
it
to
to
the
validate
variable,
and
then
you
just
do
a
avg
compile
and
you
give
it
the
schema.
A
A
Now.
The
very
interesting
part
is
you
know
when
we
actually
went
into
this.
We
we
interviewed
our
users,
we
have
more
than
a
thousand
companies
using
our
product
and
we
had
a
lot
of
built-in
rules
and
we
really
wanted
to
expand
the
usage
of
our
solution
and
we
started
interviewing
people
and
asking
them
like
which
types
of
custom
rules
would
you
want.
A
Basically,
it's
not
rocket
science
on
both
sides.
It's
pretty
easy
to
learn
and
I
personally
think
the
json
schema
is
even
easier
than
rego,
because
you
don't
need
to
learn
a
new
language
because
it's
just
a
json
and
there
is
an
implementation
in
even
in
common
lists,
for
any
language
that
you
would
like.
So
it's
really
really
easy
for
you
to
use,
but
I
gave
them
both
the
win,
so
they
still
have
100
hp
each
one.
A
The
second
one
is
the
syntax.
So
in
this
case
I
think
that
rego
has
a
richer
options
for
policy
decisions,
because
it
was
json.
Schema
is
broader
sense
engine,
so
it
is
really
wider,
so
you
can
achieve
the
same
things
as
you
do
with
drago,
but
but
maybe
with
regexes
and
stuff
that
are
less
easy
and
intuitive.
While
with
rego
you
have
conditions
and
conditions
and
more
and
more
options
to
go
down
the
rabbit
hole,
but
it
is
more
proprietary
and
harder
to
master,
but
in
this
case
I'd
say:
json
schema
loses.
A
The
next
thing
is
maintaining
and
debugging.
So
really.
I
think
that,
because
rego
is,
is
a
proprietary
language
in
a
sort
of
a
proprietary
engine,
oppa
the
debugging
and
the
developing,
and
it's
it's
it's
not
like
again
debugging
json
in
any
language
that
you
would
want,
because
there
are
so
many
implementations.
A
A
Really
both
of
them
it's
a
very,
very
good
situation.
Rego
is
a
child
of
oppa,
which
is
part
of
the
cncf
foundation,
which
is
amazing,
json
schema
again
has
so
so
many
implementations
and
rfc
and
and
everyone
uses
it
and
there's
so
so.
Many
things
that
are
based
on
json
schema
that
it
is
really
a
no-brainer
and
both
of
them
has
very
active
slacks
and
communities
and
stuck
overflow,
and
you
can
use
them
in
terms
of
versatility.
A
There
are
so
many
implementations
of
like
anything
you
would
think
of
and
because
it
is
so
easy
and
intuitive.
I
think
it
wins.
I
want
greg
also
has
examples,
but
it
is
really
harder
to
master
and-
and
it
is
much
younger,
much
younger,
so
this
is
my
take
and
finally,
in
terms
of
performance
again,
you
know
you
can
have
json
schema
with
a
compiled
languages
that
are
like
really
really
fast,
and
then
you
can
apply
it
to.
A
A
You
can
use
our
solution
to
specify
policies
in
a
policy
as
code
mode,
so
you
just
have
a
policies.yaml
file
and
you
can
specify
whether
you
want
to
turn
on
or
off
the
proprietary
policies
and
secondly,
you
can
there
is
a
custom
rule
key
and
then
you
can
put
in
custom
policies
in
this
way.
You
can
extend
our
engine
and
people
are
doing
really
crazy
things.
Our
project
has
more
than
5000
github
stars,
so
it
brings
really
a
lot
of
people.
A
So
let's
look
at
this
example.
So,
first
of
all,
you're
going
to
tell
me
shimon,
you
chose
jason
schema,
but
you
said
you're
showing
me
ayamal
example.
What
is
this?
So
you
know
jason
and
yamo
they're
interruptable
operable,
so
it
was
really
easy
for
us
to
to
give
people
the
ability
to
write
it
in
yammels,
because
in
json
this
would
have
a
lot
of
you
know
semicolons,
and
it
would
really
not
look
so
good,
so
they
write
it
in
yaml.
A
We
change
it
to
json
and
and
we
we
really
scan
it,
because
it's
it's
not
a
problem,
and
here
in
this
case,
as
you
can
see,
custom
workload
in
correct
environment
labels.
So
we
want
to
make
sure
that
the
workload
that
we're
going
to
run
on
our
kubernetes
is
is
tagged
correctly
and
it
is.
It
has
an
environment
tag
that
is
one
of
prod
staging
or
test
environment.