►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Intro: Introduction to Open Policy Agent - Tim Hinrichs, Styra
This session introduces the Open Policy Agent (OPA) project. OPA is a general-purpose policy engine used by hundreds of companies for policy enforcement across the stack. Use cases include compliance & admission control for Kubernetes, configuration validation for CI/CD systems, API authorization for microservices, data filtering for apps, and more. Attendees can expect to learn about OPA’s core features as well as integrations like Gatekeeper and Conftest. This is an excellent session to attend if you are new the cloud native ecosystem or want to get started with OPA.
https://sched.co/cpAb
A
Okay,
hi
all
my
name's
tim
henricks
and
in
this
session
we're
going
to
be
covering
an
introduction
to
the
open
policy
agent
project.
First
of
all,
I
thought
we'd
start
off
a
little
bit
with
a
little
bit
about
me.
My
name's
tim
hendrix,
like
I
said
I
am
the
co-founder
and
cto
at
styra.
I'm
also
one
of
the
co-creators
of
the
open
policy
agent
project
feel
free
to
go
ahead
and
hit
me
up
with
questions
either
on
slack
or
twitter,
wherever
you
can
get
a
hold
of
me.
A
So
when
we
started
oppa,
we
really
realized
that
there
was
a
very
clear
problem
out
in
the
in
the
world,
and
that
was
that
there
were
all
kinds
of
different
pieces
of
software
that
you
see
shown
on
this
slide
and
all
those
different
pieces
of
software
and
the
cloud
native
ecosystem
had
their
own
way
of
solving
the
policy
problem.
So
any
time
someone
tried
to
deploy
a
resource
under
kubernetes,
there's
a
policy
or
an
authorization
problem
that
needs
to
be
decided
on
every
time.
A
An
api
call
gets
made
on
a
microservice
there's
an
authorization
problem
that
needs
to
be
solved
every
time.
A
person
or
a
machine
runs
a
query
on
a
database
or
on
a
or
on
kafka
or
any
other
sort
of
messaging
messaging
system.
There's
a
policy,
an
authorization
problem
that
needs
to
be
solved
every
time
somebody
tries
to
spin
up
or
or
update
or
delete
resources
on
the
public
cloud,
there's
an
authorization
problem
that
needs
to
be
solved.
A
Every
time
someone
tries
to
ssh
to
a
linux,
server
or
or
spin
up
a
docker
container,
there's
an
authorization
problem
that
needs
to
be
solved,
and
the
same
is
true
of
ci
cd,
anytime,
someone's
trying
to
merge
code
or
deploy
resources
through
a
ci
cd
pipeline.
An
authorization
policy
problem
needs
to
be
solved.
A
The
challenge
here
is
that
each
and
every
one
of
these
different
pieces
of
software
have
their
own
way
of
solving
that
policy,
that
authorization
problem
and
what
that
means
from
a
user's
point
of
view
is
that,
even
though
I
am
perhaps
tasked
I'm
handed
an
email
or
a
wiki
or
a
pdf
that
describes
in
english
what
the
authorization
policy
should
be
for
one
or
many
of
these
different
pieces
of
software.
I
need
to
learn
a
different
api.
A
A
different
gui,
a
different,
even
model
for
thinking
about
how
you
enforce
authorization
policies
across
all
of
these
different
technologies,
and
so
when
we
started
opal,
we
said
well,
that's
that's,
not
a
great
state
of
affairs.
What
would
be
great
is
if
we
had
a
unified
way
of
enforcing
authorization
more
generally
policy
across
all
of
these
different
cloud-native
pieces
of
software,
and
so
that's
what
we
designed
open
to
do
is
provide
that
unified
policy
solution
in
particular.
A
The
way
we
talk
about
opa
is
that
it
is
a
general
purpose
policy
engine
which
means
that
you
can
use
it
to
make
policy
decisions
for
all
the
different
pieces
of
software
that
you
see
here
on
this
slide
now
I'll
go
into
this
a
little
bit
in
a
bit
more
detail
later,
but
but
for
now
keep
in
mind
that
a
couple
of
the
most
popular
use
cases
for
opa
are
are
shown
here
on
the
slide.
In
fact,
all
of
the
use
cases
here
for
oppa
are
used
by
someone
in
production
today.
A
So
this
is
not
a
theoretical
exercise
in
enumerating
potential
use
cases
for
opa.
Rather,
these
are
production,
use
cases
for
opa.
Today,
so
one
of
the
most
popular
and
we'll
talk
more
about
it
later
is
this
kubernetes
admission
control
use
case
so
every
time,
a
user,
whether
it's
a
person
or
a
machine,
tries
to
create,
update
or
delete
a
resource
on
kubernetes
opa
is
often
used
to
make
a
decision
as
to
whether
or
not
that
resource
is
safe
to
deploy.
A
A
Now,
one
of
the
things
that
we'll
get
into
a
little
bit
later
is
that
architecturally.
The
way
that
you
think
about
opa
is
that
it
really
is
designed
to
run
sort
of,
as
shown
here
in
this
picture,
it's
designed
to
run
on
the
same
server
as
whatever
software
needs
authorization
decisions.
So
in
the
kubernetes
use
case,
that
would
mean
you'd
run
a
handful
of
opas
on
each
and
every
kubernetes
cluster
in
the
microservice
use
case.
A
A
The
reason
opel
was
designed
architecturally
that
way,
is
to
provide
high
availability
and
high
performance
nearly
the
same
availability
and
performance
that
you
would
get
if
you
left
the
policy
like
hard-coded
into
that
microservice
or
into
that
kubernetes
cluster,
but
obviously
oppa's
job
is
to
decouple
policy
to
pull
policy
out
of
that
microservice
or
out
of
that
kubernetes
cluster,
so
that
you
can
manage
it
separately.
You
you
have
a
unified
tool
set
to
to
manage
policy
and
to
write
policy
all
right.
Now
we
do
on
the
opal
website.
A
Oppa
is
a
completely
if
you
don't
know
this
already
and
a
completely
open
source
cloud
native
computing
foundation
project.
Every
single
line
of
code-
that's
ever
been
written
for
opa
has
been
done
in
a
public
github
repository.
We
found
it
at
styra
back
in
2016.
We
donated
it
to
the
cncf
in
2018
about
two
years
later
and
about
a
year
after
that,
in
2019
it
became
an
incubating
project.
A
A
I
would
definitely
point
you
to
the
kubecon
us
back
in
2019.
There
were
a
bunch
of
sessions
in
the
standard
kubecon
track.
You
see
those
listed
here,
but
what
I'll
also
call
your
attention
to
is
the
opa
summit.
So
this
was
about
a
half
day
where
we
had
a
bunch
of
users
from
opa
come
and
talk
about
how
they
were
using
it,
and
this
covered
a
bunch
of
the
different
use
cases.
A
The
application
use
case,
kubernetes
use
case,
microservices
kafka,
and
I
think
those
are
the
those
are
the
the
most
of
them,
but
definitely
check
those
out.
There
are
definitely
good
lists
of
these
of
these
sessions
that
you
can
find
now.
Okay,
what
is
oppa
exactly?
I
mentioned
it
a
little
bit
ago
that
it's
a
general
purpose
policy
engine,
but
and
what
does
that
mean
really
well
so
the
way
that
opel
works
is
pretty
much
the
same
for
all
of
those
different
use
cases
for
all
those
different
software
systems.
A
We
saw
in
the
last
couple
of
slides
in
terms
of
how
that
software
system
works
with
opa,
so
that
what
we
know
is
that
we
start
with
some
service.
That
service
could
be
the
kubernetes
api
server.
It
could
be
a
micro
service
or
a
network
proxy,
a
service
mesh,
a
database.
It
doesn't
really
matter
that
service
at
some
point
in
its
life
cycle
decides
that
it
needs
a
policy
or
an
authorization
decision,
and
so
it
sends
a
policy
query
over
to
opa.
Oppa's
job
is
to
return
a
policy
decision
quickly
to
that
service.
A
It
is
the
services
responsibility
to
enforce
that
policy.
It
is
oppa's
responsibility
to
make
that
policy
decision,
and
so
that's
how
that
separation
of
responsibility
really
lies.
Now
there
are
a
couple
of
important
things
about
that
about
that
fairly,
simple
interaction,
one
of
which
is
the
policy
query
that
the
service
hands
over
to
oppa.
This
policy
query,
as
it's
noted
here,
can
really
be
any
json
value,
so
in
an
http
api
authorization
use
case
that
service
might
send
over
a
user,
a
method
and
a
path.
A
In
the
kubernetes
example,
the
service,
the
kubernetes
api
server
might
hand
over
100
or
200
or
500
lines
of
yaml
or
json
that
represents
whatever
pod
ingress
or
whatever
other
resource
the
user
is
trying
to
create
on
the
cluster.
So
in
both
those
cases,
what
opa
sees
is
just
some
json
data
that
comes
across
and
it's
oppa's
responsibility
to
make
the
decision.
The
fact
that
the
policy
queries
is
itself
just
json
data.
A
It's
not
something
that
oppa
understands
what
what
in
the
real
world
that
json
data
represents
is
why
opa
can
be
used
so
easily
across
all
of
these
different
use
cases.
So
oppa
has
not
one
line
of
code
about
what
a
kubernetes
pod
or
an
ingress
means,
or
an
http
method
or
a
kafka
queue.
Not
none
of
those
are
things
that
opa
itself
knows
about.
So
then
the
question
becomes.
How
does
this
all
work?
Well,
when
I,
as
a
person,
I'm
writing
a
policy.
A
I
know
what
a
http
method
a
path
and
a
user
represent
in
the
real
world.
I
know
what
a
kubernetes
pot
or
kubernetes
ingress
or
a
cathode
q
mean
in
the
real
world,
and
so
I,
as
a
policy
author,
can
go
ahead
and
write
whatever
policies
is,
is
correct
for
making
this
decision,
and
so
it
is
really
a
contract
between
the
service
and
the
policy
author
that,
at
the
end
of
the
day,
assigns
a
semantics
to
that
policy.
Query!
A
A
Imagine
that
the
api
server
is
handed
over
to
oppa,
100
or
200
lines
of
json,
representing,
let's
say
a
new
pod,
that
a
user
is
trying
to
create
well
in
order
to
write
policy,
and,
let's
say
the
concrete
policy
we
want
to
write,
ensures
that
all
images
in
that
pod
come
from
a
trusted
registry
all
right
now.
In
order
to
write
that
policy
within
the
rego
language,
you
need
to
be
able
to
dig
down
through
that
deeply
nested
json
data
that
represents
a
pod.
You
need
to
be
able
to
find
that
containers
array.
A
A
A
My
favorite
example
here
is:
let's
imagine
that
you
wanted
to
write
a
policy
that
allowed
only
people
who
are
on
call
to
make
changes
to
a
production,
kubernetes
cluster,
to
query
production
databases
into
ssh
into
production
servers
well,
who's
on
call,
kubernetes
doesn't
know
the
servers,
don't
know
the
databases,
don't
know
who's
on
call.
Even
the
the
identity
store,
whether
it's
active
directory
or
ldap,
or
your
whoever
your
identity
provider.
Is
they
don't
know
either
so
who's
on
call
is
usually
information.
A
That's
stored
in
a
third
party
like
pagerduty,
and
so
what
you
can
do
with
opa
opal
allows
you
to
inject
arbitrary
external
data
into
it,
so
that
you
can
write
policies
using
that
data.
So,
in
this
case,
what
you
could
do
is
you
could
pull
that
data
out
of
pagerduty
inject
it
that
list
of
who
is
on
call
into
opa,
and
now
it
just
looks
like
more
json
data
to
open.
A
So
as
a
policy
author,
now
you
can
go
ahead
and
write
exactly
that
policy
that
ensures
that
only
on-call
people
have
those
elevated
rights
all
right.
So
that's
another
thing
that
people
really
like
about
opa
is
being
able
to
inject
arbitrary
data
to
make
decisions.
The
last
thing
that
I'll
call
out
here
is
this
policy
decision.
A
There's
a
note
here
that
says
the
policy
decision
can
be
any
arbitrary,
json
value,
and
this
speaks
to
the
fact
that
oppa
is
a
general
purpose
policy
engine,
meaning
that,
yes,
you
can
and
many
people
do
use
opa
to
make
authorization
decisions,
meaning
allow
deny
boolean
true
false
one
or
zero
decisions,
but
you
can
also
use
opa
to
make
policy
decisions
that
are
far
richer
than
that.
You
could
use
open
to
write
a
policy
that
makes
a
decision,
which
is
a
rate
limit.
A
Returning
a
number
you
could
return,
you
could
write
a
policy
that
ensures
that
that
that
says,
where
which
clusters
to
deploy
an
application
to
for
that,
the
answer
might
be
an
array
of
strings.
You
can
even
have
opa
make
policy
decisions
that
are
represented
by
arbitrarily
deeply
structured
json
objects
and,
in
fact,
that
kind
of
of
of
return
value
is
often
quite
useful
because,
in
addition
to
maybe
even
in
the
authorization
setting
in
addition
to
just
returning
a
lower
deny,
you
might
also
want
to
return.
A
Let's
look
at
a
couple
of
concrete
examples
quickly,
so
one
of
which
is
one
of
the
most
popular
applications
of
opa,
and
that
is
micro
service,
api
authorization.
So
the
way
this
works
is
pictured
here.
What
we
have
here
on
the
right
hand,
side
is
really
this
micro
service
and
one
of
the
common
questions
that
we
get
is
well.
Do
I
have
to
modify
my
microservice
to
talk
to
oppa
and
in
this
picture
we
show
quite
clearly
that
the
answer
to
that
is
no.
A
The
answer
to
that
is
no.
If
you
use
a
network
proxy,
which
is
what
we
often
see,
people
do
when
they're
using
opa
for
microservice
api
authorization,
the
idea
behind
the
network
proxy
integration
is
that
you
use
a
network
proxy
like
envoy
link
or
decon
apogee
or
any
of
the
others
that
you
might
care
to
use,
and
you
run
that
network
proxy
on
the
same
server
as
that
microservice
and
route
all
network
traffic
through
that
network
proxy.
A
Then
what
you
do
is
you
integrate
opa
with
the
network
proxy
so
that
each
and
every
time
a
request
comes
in
to
the
network
proxy
intended
to
go
to
the
microservice.
The
network
proxy
can
send
that
request
over
to
opa.
Ask:
is
this
authorized
or
not
if
oppa
responds
and
says
yes,
that's
authorized
in
the
network.
Proxy
can
go
ahead
and
forward
it
to
the
microservice
as
usual,
but
if
opus
says
that
that
api
call
is
not
authorized,
the
network
proxy
can
return
a
403
drop.
It
do
whatever
you've
configured
the
proxy
to
do
so.
A
A
Let's
look
at
another
example:
integration.
This
time
it's
with
the
kubernetes
api
server.
The
popular
integration
here
is
using
opa
to
make
policy
decisions
about
as
part
of
the
admission
control
process
that
kubernetes
supports
natively.
So
the
way
this
works
is
that
each
and
every
time
a
user
tries
to
create,
update
well
each
every
time
the
user
tries
to
make
a
change
to
the
the
resources
running
on
the
kubernetes
cluster.
A
That
request
goes
through
the
kube
api
server
and
the
cube
api
server
has
a
whole
pipeline
of
changes
of
checks
that
it
goes
through,
the
first
of
which
is
authentication
who
are
you,
the
second
of
which
is
authorization?
This
would
be
basically
arbok,
so
you
know
if
it's
me
trying
to
make
the
change
then
can
tim
is
tim
authorized
to
create
a
pod
at
all
on
this
cluster
or
not
once
it
makes
it
through
authorization
on
rboc,
then
it
goes
to
admission
control.
A
The
mission
control
is
run
on
every
create,
update
and
delete,
and
what
happens
is
that
this
admission
control
hands
over
that
entire
100
200
lines
of
json
or
yaml
that
describes
that
new
pod
or
that
new
ingress
or
that
updated
pot
or
ingress,
and
it
sends
that
entire
chunk
of
json
over
to
oppa
and
asks
oppa
for
decision?
Is
this
resource
safe
or
not?
The
nice
thing
about
this
particular
integration?
Oh
and
that
integration
works?
A
A
So
if
you're
interested
in
running
policies
over
configuration
files
either
in
a
cicd
pipeline
or
maybe
even
on
developer
laptops,
I
also
recommend
you
check
this
one
out
all
right,
so
we've
gone
over
how
you
integrate
opa
and
kind
of
what
opa
is
well.
What
other
features
does
opa?
Have
that's
what
we're
going
to
cover
here
so
the
first
of
which
we've
already
talked
about
it
does
have
that
declarative
policy
language
that
is
quite
powerful.
We've
already
also
talked
about
a
couple
of
the
language
features.
A
A
We've
already
talked
about
context-to-word
policies,
a
pager
duty
example,
there's
also
composition
and
delegation.
One
of
the
nice
things
about
oppa
was
that
the
language
was
designed
to
allow
you
to
break
your
policies
up
into
one
or
more
modules,
each
module
just
think
of
it.
As
a
name
space
like
you
would
in
a
in
a
traditional
programming
language,
but
what
that
also
allows
you
to
do
is
also
delegate
decisions
to
different
policies
based
on
whatever
conditions
you
care
care
about.
A
So
my
the
example
I
always
use
is
imagine
you
had
a
compute
team
writes
a
policy
for
compute
resources.
You
have
a
networking
team
writing
a
policy
for
networking
resources.
Then,
anytime,
a
a
a
request
comes
in
you
can
write
a
third
policy
that
looks
at
that
request
and
says:
well
is
this
a
compute
resource
or
a
networking
resource
if
it's
compute
resource
make
delegate
the
decision
to
the
compute
policy?
A
If
it's
a
networking
resource
delegate
the
decision
to
the
networking
policy,
if
it's
actually
a
resource
that
has
a
bit
of
both
well,
then
maybe
you
require
both
the
compute
and
the
networking
policies
to
allow
the
request
before
you
allow
it
at
all.
So
that's
composition,
delegation.
Another
important
thing
about
open
is
that
it
was
designed
to
take
as
much
of
the
burden
for
performance
away
from
the
policy
author
as
possible.
A
In
order
to
answer
this,
the
the
incoming
query-
partial
evaluation-
I
like
to
think
of
this
as
a
compiler
technique
that
evaluates
as
much
of
the
policy
at
compile
time
as
it
can
again
leaving
the
amount
of
work
that
it
needs
to
do
for
evaluation
at
run
time
to
the
minimal
extent
possible
in
terms
of
architecture.
I've
already
mentioned
that
oppa
was
designed
to
be
effectively
host
local
cache
of
any
policy
and
data
that
it
needs
in
order
to
make
decisions.
A
So
what
we
see
most
people
doing
is
running
opa
as
a
side,
car
or
a
host
level
daemon.
You
can
also
run
opa
as
a
go
library.
If
you
like
one
of
the
important
things,
though,
that
we
decided
early
on
was
that
oppa
is
not
intended
to
be
a
source
of
truth
for
policy
or
for
data.
It
is
a
cache
all
of
the
policy
and
memory
are
kept
or
sorry
all
the
policy
and
data
are
kept
in
memory
and
one
of
the
nice.
Things,
therefore,
is
that
there
are
zero
decision
time
dependencies.
A
What
that
does,
though,
is
beg
the
question?
Well,
how
do
you
get
policies
into
oppo,
where,
from
the
source
of
truth
into
into
opa,
oppa
does
provide
a
number
of
what
we
call
management
apis
for
control
and
observability,
so
the
bundle
api
allows
you
to
configure
opa
to
download
policies
from
some
source
of
truth.
The
status
api
allows
opa
to
periodically
upload
how
it's
doing
up
to
some
third-party
service.
A
The
logging
service
allows
oppa
to
record
each
and
every
decision
that
it
makes
again
to
to
to
some
centralized
service
and
there
in
particular
I'll
mention
that
the
logs
that
are
recorded
are
not
just
text
files.
They
are
what
I
like
to
call
high
fidelity,
json
logs,
so
the
inputs
that
open
receive
the
output
it
received.
All
of
that
is
stored
in
json,
and
so
you've
got
quite
a
bit
of
information
to
work
with
there.
It's
great
for
audit
and
then
finally,
there's
a
discovery.
A
In
addition
to
management,
apis
opa
does
come
with
a
bunch
of
tooling
a
lot
of
the
same
tooling
that
you
would
expect
from
a
traditional
programming
language.
So
here
in
particular,
there's
a
unit
test
framework.
We
highly
recommend
you
write
unit
tests
and
to
make
sure
your
policies
are
correct
before
you
deploy
them
dependency
analysis,
a
formatter,
open,
checker,
there's
a
vs
code
plug-in
as
well.
There's
a
tracer
there's
a
profiler
when
you
start
looking
at
performance,
there's
also
a
playground.
A
If
you
have
not
checked
out
the
playground,
it's
a
great
place
to
write
some
policy
evaluate
it.
There
are
a
number
of
of
well-documented
examples
there
to
get
you
started
and
then
it
also
implements
the
bundle
service.
So
you
can
also
hook
up
your
opa
and
just
to
try
out
what
what
how
how
everything
works
together.
You
can
run
your
opa
on
your
laptop
or
wherever
you
want
and
have
it
download
policies
from
the
playground.
A
Stepping
back
the
way
I
like
to
think
about
oppa
is
that
what
it
really
is
embodies
is
policy
is
code.
It
and
just
like
we
have
a
software
development
life
cycle
opa
and
all
of
its
tooling
enables
a
policy
development
life
cycle,
a
whole
collection
of
activities
that
need
to
happen
in
order
to
safely
and
securely
build
and
enforce
and
monitor
the
policies
that
are
important
throughout
an
organization,
so
the
requirements
gathering
there
on
the
left-hand
side.
A
That's
obviously
not
really
something
opal
can
help
with,
but
it's
an
important
part
of
the
policy
development
life
cycle
policy
authoring.
Obviously
there.
How
do
you
write
policies?
You
need
diversion
control
them
and
so
on,
there's
a
ci
step
where
you
want
to
test
policies.
I
already
mentioned
the
the
the
opa
test
framework.
There's
also
a
build
step
where
you
can
build
those
bundles
and,
and
you
know,
assemble
those
policies
from
wherever
they
from
wherever
their
sources
of
truth
actually
are
deployment.
A
You
need
to
deploy
those
policies
to
open,
make
sure
that
it's
always
got
whatever
policies.
It
needs
to
make
decisions
monitoring
all
of
the
oppas
logging,
all
the
all
the
decisions
that
open
makes,
so
all
of
those
headings
should
sound
very
familiar
to
anyone.
Who's
working
in
software
development.
Those
same
kinds
of
activities
are
the
things
that
the
opa
that
oppa
and
all
of
its
tooling
enables,
but
for
policy
that
is
all
for
today.
So
thank
you
so
much
for
giving
me
your
time.