►
Description
Open Policy Agent (OPA) is a general purpose policy engine that enables teams to de-couple policies from the application code to unify policy deployment and enforcement across cloud-native environments.
In this hoot, we explore how OPA can be used for Envoy Proxy and Envoy based solutions like Gloo, Istio, and more with examples and demos.
https://www.openpolicyagent.org
https://www.solo.io
Code Samples: https://github.com/solo-io/hoot
Suggest a topic to cover here: https://github.com/solo-io/hoot/issues/new?title=episode+suggestion:
A
All
right,
another
episode
of
hoot
with
us
and
today
we're
talking
about
a
open
policy
agent
together
with
envoy.
So
let's
start
with
saying
that
we
now
have
a
repository
for
past
and
future
episodes,
and
let
me
bring
it
up
right
here,
so
you
can
see
that
it
is
in
solaio
hoot
and
you
can
create
issues
with
episode,
suggestions
and
please
start
it.
A
So
we
it
will
help
us
and
motivate
us
to
create
and
produce
more
content
and
just
to
see
that
you
know
people
like
what
we're
doing
so
in
this
episode,
we'll
be
demonstrating
showing
how
to
integrate
envoy
together
with
open
policy
agent.
If
you
like
this
series
subscribe
to
our
channel
we're
trying
to
do
an
episode
one
every
two
weeks
and
the
episode
in
two
weeks
from
now
we'll
announce
it
soon
so
stay
tuned,
so
yeah
subscribe
like
us
and
and
feel
free
to
look
back
at
the
series.
A
A
And
let's
start
with
this,
I
have
actually
prepared
a
little
slideshow
to
demonstrate
it
and
it's
my
first
time
doing
animations.
So
so,
let's
see
how
that
turned
out
alright.
So
the
way
we
use
open
policy
agent
with
together
with
envoy
is
that
the
it's
essentially,
we
use
envoy
as
a
proxy
and
oppa
to
enforce
a
policy
and
authorization.
So
the
way
this
works.
Sorry.
A
Coffee
very
important.
The
way
it
works
is
that
what
we
want
to
achieve
is
to
have
oppa
examine
their
incoming
request
and
using
opa
policy
determine
whether
or
not
we
should
allow
or
disallow
the
request
and
I'm
watching
the
chat.
So
if
you
have
any
questions,
just
drop
them
up
right
there
and
I'll
answer
them
live.
So
let's
go
on
with
this
animation
here,
so
this
is
kind
of
the
way
it's
going
to
work.
A
We
have
a
user
and
the
user
want
to
do
a
get
request
and
it
sends
it
through
envoy
to
the
upstream
service
in
android,
we're
configuring,
the
x
of
z,
filter
and
that
filter
the
thing
that
it
does
and
we'll
review
its
documentation
soon
when
we
go
a
bit
deeper
and
we're
also
going
to
see
all
of
this
in
a
demo
of
course,
of
course.
So
the
way
this
will
work
is
that
the
request
goes
into
android
goes
through.
Oh,
my
god.
A
Look
at
this
animation
so
proud
of
myself
right
now,
we'll
get
into
the
xoz
filter.
The
xoz
filter
will
before
it
forwards
the
request
to
the
next
filter.
It
will
first
ask
an
external
server
if
this
request
is
allowed
and
if
it's
allowed
it
will
go
back
and
continue
to
the
upstream
service
right.
So
in
our
case,
oppa
acts
as
an
external
auth
server
right.
So
android
has
the
external
filter
that
acts
as
a
client
issues.
A
A
Let's
go
back
to
the
browser
and
let's
first
review
the
envoy
side
and
let's
look
at
what's
an
anvil
authorization
service,
so
an
available
authorization
service
is
something
that
accepts
a
check
request,
and
maybe
I
can
even
show
you
the
the
proto
service
definition
here
right.
It
has
a
check
that
accepts
a
check,
request
and
returns.
A
check
response
and
a
check
request
has
some
attributes
which
we
will
review
in
a
second
and
a
check
response
has
a
status
if
it's
okay,
the
request
is
accepted.
If
it's
not
okay,
the
request
is
not
accepted.
A
Right,
so
let's
say
look
at
what
is
check
requested.
It
has
an
attributes
and
in
the
attributes
you
have
a
request,
sorry
request.
So
let's
go
to
the
request
here
and
request:
it
could
be
a
http
request
and
it
has
all
the
properties
of
the
http
request.
So
you
can
see
the
path
and
the
host
header
or
authority
header,
the
other
headers.
The
method
so
essentially,
android
gives
all
this
information
using
a
grpc
service
to
an
external
service.
A
And
now,
let's
quick,
look
on
how
the
filter
is
configured
and
I'll
review,
the
android
configuration
in
more
depth
just
so
it'd
be
easier
to
understand.
Where
we
see
it,
we
create
an
http
filter
with
this
name
xoz
and
give
it
a
config,
and
in
that
config
we
tell
it
where
to
go
to
ask
the
authorization
question
right.
So
this
points
to
an
envoy
cluster
and
that
onward
cluster
hosts
the
authorization
server.
So,
whenever
request
comes
to
the
xoth
filter,
excel
filter
will
hold.
A
A
Here
here
right,
so
you
have
you
create
a
plugin,
you
register
it
internally
and
then
you
create
a
main
function
that
has
your
plugin
and
also
the
rest
of
oepa
right.
So
the
result
of
this
will
be
a
new
binary
that
does
everything
that
opa
the
original
opa
binary
does.
But
in
addition
also
has
this
plugin
built
into
it
right.
So
it's
kind
of
like
a
statically
built
plugin
and
now,
let's
see
the
plugin
that
the
good
folks
at
opa
wrote.
A
They
created
an
opa
envoy,
plugin
right,
so
what
this
plugin
does
and
the
demo
I'm
going
to
show
is
really
based
on
this
repository.
I
just
the
way
I
like
to
do.
Demos
is
kind
of
simplify
them
as
much
as
I
can
so
I
can
run
everything
locally
and
if
I
can
do
it
without
kubernetes,
I
do
it
without
just
so
it's
easier
to
probe
and
change
and
play
around
with
things.
A
A
Here
we
go
all
right.
So
let's
talk
specifics
right.
What
we're
seeing,
if
you
remember
the
the
little
animation
we
have
a
request
going
through
envoy
and
then
from
envoy.
It
goes
into
oepa
as
a
server
and
then
goes
back
and
continues
to
the
server.
So
how
do
we
do
this
in
android?
So,
let's
start
with
the
envoy
configuration
we
have
here
the
list
of
filters
and
you
can
see
that
we
have
two
http
filters.
Configured
one
is
exoth
and
the
one
is
the
rather
we
always
have
to
have
the
other.
A
Now
it's
very
important
to
have
exot
before
other
filters
right,
because
the
order
of
filter
matters,
the
request,
transverses
the
filters
in
order.
So
if
you
have
exoth
not
first
right,
the
authorization
decision
will
be
deferred
to
to
where
exod
is
positioned,
and
usually
you
want
to
make
authorization
decisions
pretty
early.
So
usually
you
want
to
have
the
xor
filter
unless
you
really
know
what
you're
doing
you
want
to
have
it
first.
A
All
right,
so,
let's
review
the
excel
configuration.
It's
pretty
simple.
The
one
notable
change
over
the
defaults
is
that
we
are
allowing
to
have
eight
kilobytes
of
the
request
body
and
if
the
body
is
bigger,
only
the
first
eight
kilobytes
will
go
through
so
by
default.
Exoth
only
passes
in
headers.
A
If
you
want
to
pass
in
the
body,
you
can
add
this
extra
configuration
that
tells
it
pass
some
of
the
body
up
to
this
limit
and
whether
or
not
if,
if
the
body
is
bigger,
what
to
do
test
the
partial
body
or
press,
nothing
and
failure
would
allow
what
to
do
in
case
of
failure.
Then,
in
this
case
we
not
allow
the
request
and
sometimes
there's
use
cases
where
you
still
want
to
let
the
request
through
when
exoth
does
some
of
the
authentication,
and
some
of
it
will
be
done
upstream.
A
All
sorts
of
you
know
it's
really
up
to
you
and
the
last
part
the
grpc
service,
pointing
it
to
an
excel
service,
and
in
our
case
it's
just
localhost,
as
you
can
see
here
in
the
cluster
definition,
it's
just
localhost
at
port
1991
and
we'll
get
to
that
port.
In
a
sec,
all
right
so
and
all
this
code
will
be
uploaded
to
the
repo,
as
you
can
see,
it'll
be
a
new
folder,
a
zero
eight
open
envoy,
and
I
will
push
it
when
the
episode
is
over
now.
A
A
So
I
just
put
it
in
a
plain
file
here
and
you
can
see
that
this
policy
essentially
takes
the
request,
reads
a
jot
of
the
of
the
requests
and
then,
according
to
the
jot,
the
jot
has
a
role
inside
it
according
to
the
role
and
the
in
the
method
and
the
path
decides
if
to
allow
the
request.
So
the
request
is
allowed
if
the
jot
is
valid
and
if
an
action
is
allowed
right,
so
an
action
is
allowed.
A
A
That's
a
good
question
and
it's
hard
to
answer
because
there's
a
lot
of
stuff
you
can
tune
and
there's
also,
even
if
it's
an
http
service,
it
can
still
be
http
too,
and
if
it's
http
2
both
cases.
I
don't
know
if
I'll
expect
to
see
a
lot
of
performance
differences,
though
I
did
not
measure
so
with
performance.
You
always
want
to
measure.
A
If
you
look
at
the
exhaust
configuration
with
http,
you
can
actually
fine
tune
it
a
little
bit
more
and
you
can
tell
it
and
maybe
I'll
just
show
it
instead
of
talking
and
where
is
that
you
can
tell
it
which
headers
you
want
to
include
so
the
way
http
works,
because
there's
no
grpc,
there's
no
check
request.
What
excel
does
essentially
resends
the
request
with
the
same
header
to
the
authorization
server
and
expects
the
authorization
server
to
understand
that
it
needs
to
either
return
a
200
or
a
note
and
deny
the
request.
A
A
If
I
had
to
guess,
I
would
guess
that
the
performance
would
be
similar
if
you
use
http
2
for
both,
but
I
didn't
test
it.
You
want
to
test
it
and
fine
tune
it
to
your
use
case
right.
So
in
general,
it's
a
network
hope
with
http
2.
Everything
is
multiplex,
so
it
should
be
pretty
similar
in
terms
of
performance
and
obviously
there's
the
server
performance,
but
that's
a
different
issue.
A
Let's
see
it
all
in
action,
and
I
have
this
readme
with
exactly
the
instructions
and
how
to
replicate
this
setup
yourself.
So,
let's
start
here
the
terminal,
hopefully
everybody
see
everything
and
let's
start
some
commands.
So
first
thing
we
do
is
start
open
envoy
and
the
reason
I'm
starting
up
and
when
not
regular
oppa.
If
you
remember,
plugins
generate
a
new
binary
and
this
binaries
contains
all
of
oppa
and
the
plugin.
So
I
have
to
start
this
new
binary.
A
A
server
give
it
a
config
file,
tell
it
where
the
oppa
server
listens
to
we're
not
using
it
because
we're
using
the
excel
one
and
we
give
it
the
policy
regal.
So
we
can
just
start
this
and,
of
course,
I'm
in
the
wrong
folder.
So
it's
not
going
to
work,
but
now
that
I'm
in
the
right
folder
it
works
and
let's
open
another
terminal,
all
right.
A
A
With
the
config
file
that
I've
showed
you
and,
of
course
I
need
to
see
d
again
here
we
go
here,
we
go
here.
We
go
all
right,
let's
get
another
terminal
here,
get
this
environment
variables
and
let
me
pause.
One
second
explain
what
these
environment
variables
are.
So
service
is
just
the
port
that's
configured
in
envoy
for
listening.
A
A
You
can
see
that
bob
is
an
admin
and
these
jots
are
hmac
shot
256,
which
means
essentially
what
it
is
is
that
they
use
a
symmetric
key
and
in
this
demo
the
symmetric
key
is
secret,
so
we
can
actually
create
our
own
jots
if
we
just
type
in
the
the
secret
being,
you
know
secret
all
right,
given
all
this
setup,
we
can
see
that
hey.
Where
is
this
sorry?
I
meant
to
go
here
and
we'll
review
this
in
a
second.
We
can
see
how
it
works.
A
A
The
secret
is
always
secret,
so
you
can
use
it
to
edit
the
jot
and
you
can
see
that
if
I'll
go
back
to
the
vs
code,
part
that
when
the
jot
is
parsed,
the
secret
is
also
here
as
a
secret
and
obviously
it's
not
secure.
But
this
is
just
a
demo
but
yeah
all
right.
Usually
the
way
you
do
this
is
with
public
keys
and
the
jot
is
encrypted
with
a
private
key
and
then
it's
okay
to
publish
the
public
key.
A
A
You
can
see
that
alice.
That
has
that
so
alice
john
has
the
guest
role
and
you
can
see
she
can
get
things,
but
she
cannot
create
things
right.
So
if
we
do
a
post
request,
we
get
a
four
or
three
forbidden
right
and
let
me
restart
envoy
with
debug
logs,
so
you
can
see
exactly
what's
going
on
here.
We
go
let's
clear
this
stuff,
all
right.
We
hit
a
forbidden
service
and
you
can
see
in
the
android
logs.
A
A
And
you
can
see
that
blah
blah
blah,
and
this
is
the
exoth
response
and
it
responded
with
a
denial-
and
here
is
envoy
returning
403
back
to
the
user
right,
so
this
is
kind
of
a
full
circle
life
of
a
request
type
deal.
This
is
the
the
debug
logs
of
what
we
saw
in
the
presentation
right.
So
if
we'll
do
the
successful
requests
again-
and
let
me
just
clear
this
terminal.
A
A
A
So
yes,
this
is
as
far
as
the
demo
goes.
It's
and
you
can.
One
thing
I
want
to
show
here
additionally,
is
that
it
uses
one
thing
nice
about
oppa,
that
it
has
a
library
and
built
in
the
library
is
jwt
verification,
so
you
can
use
it
to
verify
jots
from
your
policy
without
any
additional
things
to
write.
So
that's
nice.
A
A
But
if
there's
any
questions
so
far,
please
feel
free
to
ask
now's
a
good
time
and
with
that
the
last
part
of
the
day
broadcast
is.
I
want
to
show
you
how
this
example
applies
to
ezio.
So,
as
you
know,
with
ezio
there's
a
envoy
bundle
with
every
pod
and
the
way
this
is
architected
to
work
with
itsu
is
that
it
also
bundles
another
site
called
the
opa
sidecar
right.
A
They
also
inject
an
opa
container
to
the
pod
right
that
contains
the
exactly
the
binary
we
just
run
manually,
but
just
as
a
container,
and
it
pretty
much
works
exactly
the
same.
They
configure
envoy
to
interact
with
the
pod
using
the
external
auth
mechanism
right.
So,
if
we
look
at
their
quick
start
example,
you
can
see
all
the
resources
they
install.
I
just
wanted
to
show
the
injector
blah
blah
blah
here
we
go
the
mutating
web
book
injector
and
you
can
see
all
the
configuration
files,
the
policy,
everything
that
we've
seen
before.
A
So
it
works
very
very
similarly
to
how
we
showed,
in
this
example,
only
adapted
to
ezio
and
because
ezio,
the
basis
of
which
is
envoy.
Then
it
essentially
just
works
right,
but
they
are
talking
about
a
little
bit
how
to
productionize
it
a
bit
more.
You
know
using
bundles
to
deliver
policies
all
that
so
feel
free
to
read
this
to
get
a
deeper
dive
into
the
into
the
it's
your
way
of
integrating
it.
If
you
feel
like
it.
A
A
And
this
is
this:
is
the
one
of
the
highlights
of
this
year?
Is
me
doing
animations?
So
so,
let's
summarize,
what
we've
seen
so
far?
We
have
the
user.
The
user
sends
a
request
to
envoy
envoy
external
auth.
Filter
has
an
api
that
runs
a
sends
a
check
request
to
an
external
server.
It
sends
it
gets
a
response:
okay,
not
okay
and
then
continues
to
the
upstream.
Oh,
we
have
a
question
running
off
services.
Side.
Questing
sound
is
this
recommended
was
coming
as
another
xoxo
yeah.
So
it's
really
all
about
trade-offs.
A
A
No,
oh
because
it's
over
underscore
angle,
I
think
it's
around
20
megs
yeah,
it's
24
megabytes.
It
is
counter
intuitive.
I
mean
running
on
one.
Every
pod
is
also
counter
intuitive.
So
it's
really
it's
one
of
those
things
that
you
only
want
to
pay
the
price.
If
you
have
to
it's
a
trade-off
right,
so
a
centralized
opa
the
disadvantage
could
be
organizational
right.
You
now
have
centrally
managed,
and
if
you
want
a
policy,
that's
specific
to
a
service
or
a
team,
it
might
be
harder
to
implement
and
you
might
have
additional
latency
right.
A
The
advantage
is
it's
easier
to
manage
oppa
itself
and
there's
less
moving
parts
and
there's
less
cost
per
pod,
and
so
it's
one
of
those
things
that
yeah
it's
it's
complex.
You
also
have
another
sidecar
injector,
whether
or
not
it's
worth
paying.
That
complexity
is
really
depending
on
your
specific
use
case.
I
agree
that
it's
not
trivial,
that
that's
the
architecture
you
want
to
go
with
right,
but
yeah.
That's
that's
a
very
good
point,
very
good
question,
so
yeah
yeah,
I
think
in
in
cloud
native.
It's
all
about
trade-offs,
right,
there's,
no,
there's!
No!
A
The
best
way
to
do
something
right
so,
for
example,
we
have
exot
with
glue
with
you
know:
solar
io
is
the
api
gateway
glue
and
because
different
tradeoffs
for
different
customers.
We
allow
you
in
the
helm
chart
you
can
decide
where
to
bundle
it
as
a
side
car,
and
then
we
use
unix
sockets
to
minimize
latency
or,
if
you
prefer,
running
centrally,
on
its
own
deployment.
Right
and
different
organizations
have
different
preferences,
so
yeah
yeah,
all
right,
so
yeah.
In
summary,
we
have
envoy
anvil,
defines
this
api
android
defines
the
the
contract
for
external.
A
A
Every
time
you
want
to
update
policy
right.
So
once
you
decide
on
the
architecture,
let's
see,
let's
say
you
weighed
all
the
options
and
decided
that
yeah
I
want
my
services
to
have
an
android
sidecar
and
an
opa
sidecar,
because
I
want
to
minimize
latency
oppa
has
a
way
of
delivering
those
policies
without
restarting
or
redeploying
right.
In
our
example,
it's
a
config
map
or
a
file
so
yeah
you
would
have
to
restart
it,
but
oppa
can
also
fetch
them
on
a
period
from
an
http
server
using
a
feature
called
opa
bundle.
A
A
Yeah,
so
yes,
so
I'll
just
summarize
envoy
is
the
component
that
gets
the
request.
A
performance
authorization
only
defines
the
api
for
authorization,
services
and
oppa
implements
that
api.
Now
I
know
that
it's
a
bit
weird
envoy
is
the
client,
but
it
defines
the
api
it's
kind
of
like
with
xds,
where
android
defines
the
the
api
for
to
configure
android
and
different
servers
implement
this
xds
right.
A
A
I
don't
see
a
quick
example,
but
yeah
you
can
you
can
look
for
bundles
in
the
opa
docs.
One
last
thing
I
wanted
to
review
before
signing
off
today
and
let
me
go
back
to
the
vs
code.
As
you
see
this
policy,
we
have
here
input,
attributes,
request,
http,
http
request
and
then
method.
You
know
roll.
How
do
you
know
where
this
come
from
right?
Where
are
these
names
coming
from?
A
Where
is
this
structure
coming
from
right
and
the
answer
is
it's
coming
from
that's
why
I
started
by
reviewing
the
envoy
check
request
right.
So
this
is
the
exact
structure
of
the
android
check
request.
So
you
can
get
this
structure
by
looking
at
the
android
docs
and
seeing
okay,
I
have
the
check
request.
What's
inside
it?
Oh
attributes
inside
attributes,
you,
if
you
remember
it,
was
a
request
so
request.
Http
http
has
a
method
path
headers.
A
A
A
I
will
push
the
notes
shortly
and
we
will
announce
the
topic
for
the
next
two
weeks
in
the
next
few
days
and
thank
you
everybody
for
joining.
I
will
see
you
in
two
weeks
at
1pm
on
the
solo
channel
and
thank
you
for
participating
and
asking
questions.
I
love
answering
those
questions
so
have
a
great
day,
everyone
and
goodbye.
I
will
see
you
in
two
weeks.