►
From YouTube: Intro: Open Policy Agent - Torin Sandall, Styra
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Open Policy Agent - Torin Sandall, Styra
The Open Policy Agent (OPA) is a general-purpose policy engine that enables fine-grained, context-aware policy enforcement across the stack. OPA is used in production by companies like Netflix, Intuit, and Chef for a variety of use cases like microservice authorization, Kubernetes admission control, and end-user API authorization. This session provides an introduction to the OPA project. You will learn how OPA works and how it can be applied to a range of technology. Come to this talk if you are responsible for securing Kubernetes within your organization, building an internal security platform for custom microservices, or just interested in policy and security.
https://sched.co/NrrB
A
So
this
is
the
open
policy
agent,
introduction
session,
so
I
hope
everybody's
here
for
the
open
intro
session.
If
you're
not
here
for
this,
it's
a
good
time
to
time
to
leave
so
before
I
get
started.
How
many
people
here
have
heard
about
OPA
before
okay,
a
few
of
you
and
is
anybody
using
OPA
today
or
have
you
actually
tried
it
for
POC
or
an
experiment?
Okay,
one
person,
okay,.
A
Think
everybody
here
is
in
the
right
place.
Hopefully
we
can
help
you
audible,
so
my
name
is
Tauron
I'm,
an
engineer
at
styro
and
I'm,
one
of
the
co-creators
of
the
open
policy
agent.
Styro
is
the
company
that
created
open
policy
agent
I'm
an
engineer
there.
I
work
primarily
on
OPA.
If
you've
been
on
the
OPA
slack,
then
you'll
know
me
as
T
sandal
on
there
and
on
Twitter.
My
name
is
Sam
Turin.
A
A
When
we
started
it
was
to
basically
provide
a
building
block
that
would
help
unify
policy
enforcement
across
a
range
of
different
technology
and
over
the
last
year
and
a
half
or
two
years,
we've
had
a
lot
of
growth
in
terms
of
the
number
of
end
users
that
are
using
the
pop
of
the
project
to
solve
all
kinds
of
different
policy
use
cases
in
their
organizations.
So
today,
companies
like
Netflix
use
OPA
to
enforce
access
control
over
internal
resources
over
internal
micro-service.
Api's
companies
like
chef,
are
using
OPA
to
deliver.
A
So
as
of
April,
it
was
promoted
up
from
the
sandbox
which
we
joined
last
year
to
incubating,
and
we
have
about
60
different
people
that
have
contributed
to
the
project
we
have
over
900
people
on
our
slack
organization.
We've
got
over
2,000
stars.
We
have
over
20
integrations
with
other
projects
in
that
in
a
cloud
native
ecosystem.
A
So
just
to
kind
of
motivate
the
problem
and
kind
of
explain
why
OVA
exists.
Imagine
you
know,
imagine
you
have
a
large
application
right.
You
have
a
micro
service,
based
architecture,
and
you
know
you
have
some
portal
which
your
customers
connect
to
right
and
they,
maybe
they
connect
to
that
portal
to
to
buy
things
for
their
pets
or
to
do
all
kinds
of
you
know
online
shopping
or
something
like
that,
and
that
application
is
implemented
by
a
set
of
micro
services
right.
So
you
have
a
service
that
does
payments
right.
A
It
processes
all
the
payments
that
the
customers
are
making.
You
have
a
service
that
handles
account
data.
You
have
a
service
that
deals
with
promotions,
a
service
that
does
notifications
that
talks
to
partner
api's.
Some
of
these
services
talk
to
you
know
internal
databases
that
you're
running,
like
like
my
sequel,
others
talk
to
external
services
like
s3
right.
So
this
is
a
very
typical
kind
of
architecture
from
in
modern
organizations.
C
A
Now
the
problem
is,
is
that
today
somebody
like
Alice
a
developer
often
has
complete
access
to
all
of
the
services
that
make
up
that
application.
Right.
Alice's
is
a
developer
of
the
company,
and
so
she
often
has
to
troubleshoot
the
services
that
make
up
the
application,
and
so
she
has
complete.
You
know,
access
to
the
portal
and
all
of
the
payment
services
and
account
services
and
so
on,
right,
and
so
this
this
is.
A
This
is
important,
because
Alice
often
needs
to
debug
these
services
and
access
them
and
do
things
with
them,
but
at
the
same
time
it's
it's
risky
right,
because
if
she
decides
that
she
wants
to
look
up,
Bob's
credit
card
number
or
she
wants
to
look
up,
Bob's
private
information.
She
can
do
that
right.
She
has
a
lot
of
permissions
in
the
system
so
to
address
that.
A
What
we
want
to
do
is
put
you
know:
authorization
or
access
control
checks
in
each
one
of
these
locations
right,
so
we
we
would
want
to
go
into
the
payment
service
and
add
API
authorization.
We
want
to
go
into
the
account
service
and
do
the
same,
and
so
on
and
so
forth
right
and
in
some
cases
we
might
have
to
deal
with
external
authorization
systems
like
s3,
right
or
AWS.
A
I
am
the
problem,
though,
with
having
to
go
in
and
do
authorization
or
access
control
in
every
single
one
of
these
services
is
that
it
raises
a
number
of
questions
right.
It
might
be
easy
to
do
it
in
one
service
on
its
own,
but
when
you
look
at
a
large
application,
you
know
in
a
large
organization,
there
are
all
kinds
of
questions
that
come
up
when
you're
thinking
about
access,
control
and
authorization.
A
So,
for
example,
you
know
what
do
you
do
when
the
Information
Security
Department
comes
along
and
they
have
near
new
policies
for
you
to
enforce?
What
are
you
doing?
Legal
or
compliance
have
the
same
right.
How
do
you?
How
do
you
address
this
across
a
large
range
of
services?
Moreover,
how
do
you
delegate
control
to
your
end-users
right?
How
do
you
give
end-users
the
ability
to
specify
the
policies
that
govern
access
to
their
to
their
data?
How
do
you
roll
out
changes
for
the
policy
right?
The
policy
is
going
to
change
at
some
point.
A
That's
just
a
fact:
how
do
you,
how
do
you
do
that?
You
have,
to
you
know,
release
a
new
version
of
the
of
the
service?
Well,
that
might
be
that
might
be
complicated
or
painful
right.
You
want
to
just
make
a
change
to
the
policy.
Moreover,
how
do
you
access
you
know?
How
do
you
write
policies
that
leverage
external
context
right
a
lot
of
the
time?
A
The
policies
that
make
sense
in
large
organizations
depend
on
you,
know
external
databases
or
external
context
within
the
organization
things
like
you
know,
HR
database
or
an
application
database,
and
so
on
right.
So
how
do
you
how
you
get
that
kind
of
data
down
to
the
policy
engine?
How
do
you
get
it
into
the
policy
engine?
How
do
you
make
use
of
it
inside
of
the
policies
you
know
and
also
like
how
you
render
UI
is
based
on
policy?
How
do
you
test
your
policies
for
correctness?
A
How
do
you
know
that
the
policies
you've
got
in
place
are
actually
doing
what
you
expect
them
to
do?
Right
and-
and
how
do
you
do
this-
you
know
when
you
have
hundreds
of
services
or
in
dozens
of
different
languages
that
have
all
kinds
of
different.
You
know:
identity
protocols
that
they
use
to
authenticate
users
that
run
in
different
kinds
of
execution,
environments
like
containers
and
bare
metal
and
so
on
and
so
forth
right,
but
the
problem
doesn't
really
stop
at
the
application
layer.
It
also
exists
at
the
platform
layer
right.
A
So
this
this
application
happens
to
run
on
kubernetes
and
again,
Alice
has
kind
of
full
access
to
kubernetes
right.
She
is
responsible
for
providing
configurations
to
kubernetes
that
define
you
know
ingresses
and
pods,
and
she
controls
network
policy
for
her
application
and
she
is
responsible
for
creating
persistent
volume
claims
and
all
that
kind
of
stuff
right.
A
Well,
the
problem
with
giving
alice
direct
access
to
compute
storage
network
resources
is
that
a
lot
of
things
can
go
wrong.
Right.
Alice
can
create
an
ingress
that
conflicts
with
another
ingress
in
another
namespace,
and
so
suddenly,
when
she
creates
that
conflicting
ingress
traffic
is
no
longer
being
routed
to
the
right
place.
Right.
It's
going
to
her
development,
her
development
instance.
She
can
easily
run
you
know
vulnerable
container
images
with
no,
not
vulnerable
ities
right,
there's
nothing!
A
Stopping
Alice
from
just
saying,
deploy
this
image
from
from
docker
hub
and
run
it
right,
there's
nothing
stopping
Alice
from
instantiating,
a
network
policy
that
allows
outgoing
you
know,
egress
traffic
to
any
IP
address
in
the
world
right,
there's
nothing
stopping
that
again
and
again,
you
know:
yeah
Alice
isn't
stopped
from.
She
can
instantiate
pods
that
don't
put
any
but
limits
on
CPU
and
memory
right,
so
you
can
have
runaway
resource
usage
right.
A
So
there
are
all
kinds
of
different
policy
concerns
across
the
stack
right,
and
so
this
is
why
we
why
we
created
the
OPA
policy
agent
at
styro
was
because
we
wanted
to
provide
a
building
block
that
would
help
a
unify
policy
enforcement
across
a
wide
range
of
services.
So
you
know,
if
you
look
at
different
services
or
technology
today
they
typically
have
their
own.
A
You
know
access
control
or
policy
or
authorization
systems,
and
the
problem
is
that,
if
you're
in
a
large
organization,
you
have
every
single
one
of
these
components
in
your
in
your
system
and
so
to
manage
the
access
control
rules
becomes
very
difficult
because
you
have
to
go
into
each
one
of
those
systems
and
and
modify
the
policy
right.
Well,
wouldn't
it
be
better
if
we
had
one
kind
of
building
block
one
policy
system
that
could
plug
into
all
these
different
components,
and
that
would
give
you
basically
a
single
way,
a
centralized
way
of
managing
policy.
A
So
this
is
why
you
create
created
open.
We
wanted
to
basically
unify
policy
enforcement
across
the
stack,
and
so
this
is.
This
is
just
a
picture
that
we
that
we
often
show.
This
is
an
example
of
you
know
all
the
different
kinds
of
integrations
we
have
with
OPA.
Now
we
have
integrations
with
kubernetes,
obviously,
for
admission
control.
We
have
integrations
with
various
micro
service
frameworks
and
service
projects.
A
So
what
is
what
is
open
exactly
well,
OPA
is
what
we
say:
we
call
it
a
general-purpose
policy
engine
and
what
that
means
is
that
it's
domain
agnostic,
but
to
understand
it
simply.
We
can
look
at
a
single
service,
so
say
you
know
you
were
responsible
for
implementing
the
salary
service
within
your
within
your
company
right.
So
this
service
is
responsible
for
serving
salary
data
for
employees
right,
so
the
service
exposes
is
an
API
that
allows
you
to
look
up
the
salary
for
any
given
employee
right.
A
So
you
can
send
a
get
to
the
service
for
a
slash,
salary,
slash
Bob
and
you
provide
your
credentials
in
the
authorization
header
and
the
salary
service
will
return
the
salary
for
that
an
employee.
But
obviously
when,
when
you
look
up
an
employee's
salary,
you
know
that
needs
to
be
authorized
right.
You
don't
want
anybody
to
be
able
to
see
your
salary
and
so
that
that
that
authorization
process
is
a
policy
decision
and
so
with
OPA.
A
It
supplies
a
bunch
of
attributes,
and
so
in
this
case
it
would
supply
things
like
the
HTTP
method,
from
the
incoming
request,
the
path
from
the
incoming
request,
the
user,
that's
making
the
request
and
so
on
all
right,
and
so
then
OPA
will
take
those
attributes
and
it
will
evaluate
them
against
policies
and
data
that
you've
given
to
OPA
to
produce
a
decision
like
allow
or
deny
which
it'll
send
back
to
the
service
to
be
enforced.
So
the
important
thing
to
keep
in
mind
with
OPA
is
that
policy.
A
A
Now
when
we
say
that
OPA
is
general
purpose,
we
really
mean
it.
When
we
say
it's
dome
an
agnostic,
we
really
mean
it.
So
I
was
talking
about
the
salary
service
a
second
ago,
but
you
could
substitute
salary
service
for
all
kinds
of
different
components.
You
could
it
could
be
a
you
know,
it
could
be
an
API
gateway.
It
could
be
a
service
proxy
like
envoy.
It
could
be
a
custom
internal
micro
service.
It
could
be,
you
know
an
SSH
daemon.
It
could
be.
You
know
an
object
store
like
SEF
right.
A
This
is
why
we
call
open
domain
agnostic
because
it
can
plug
into
all
these
different
kinds
of
services.
Now,
in
order
to
make
that
work,
we
made
certain
design
decisions
when
we
started
open
and
one
of
them
was
that
OPA
itself
wasn't
going
to
be
coupled
to
any
project
or
domain-specific
data
model.
So
the
attributes
that
you
supply
to
OPA
in
the
policy
query
can
be
arbitrary,
JSON
values.
You
can
supply
any
JSON
data.
You
want
in
the
policy,
query,
method
and
path
and
user
are
not
special
in
any
way.
A
They're
just
JSON
data
that
gets
supplied
as
input
to
the
policy
engine
and
then,
similarly,
the
output
from
the
policy
can
be
any
JSON
values.
So
a
second
ago
I
showed
true
or
false
being
sent
back,
but
you
can
generate
numbers.
You
can
generate
strings.
You
could
generate
large,
complex
objects
that
represent
your
policy
decision,
so
OPA
itself
basically
helps
you
decouple
policy
enforcement
from
policy
decision
making,
and
it
does
that
by
remaining,
you
know,
domain
agnostic.
A
A
At
expressing
policies
or
answers
to
questions
like
can
user
X
perform
operation
Y
on
lease
or
Z
right
or
you
know
which
rules
which
invariants
would
this
workload
violate
if
it
were
to
be
deployed
or
which
records
should
Bob
be
allowed
to
see
so
I'm
going
to
show
an
example
of
Ray
go
in
a
few
minutes,
but
the
thing
to
keep
in
mind
is
that
it's
a
high-level
declarative
language
and
it's
really
good
at
basically
letting
you
write
strengths
over.
You
know
large
sets
of
JSON
data
large
unstructured
sets
of
JSON
data.
A
Now,
when
you
actually
use
OPA,
you
have
different
options
so
conceptually
they're
all
the
same,
but
depending
on
your
use
case,
some
options
make
more
sense
than
others.
So
if
you're
building
services
in
go,
you
can
actually
embed
OPA
directly
as
a
library
inside
of
your
service,
just
as
a
go
library.
But
if
you're
not
building
services
and
go,
then
you
can
run
it
as
a
daemon
and
we
typically
recommend
that
what
you
do
is
you
run
it
as
a
sidecar
container
or
sidecar
daemon
or
a
host
level
daemon.
A
If
every
single
time
your
service
has
to
make
a
policy
decision,
it
has
to
call
out
over
the
network,
then
there's
gonna
be
a
lot
of
latency
introduced
into
the
request
path
right
and
if
you're,
building
like
micro
services,
for
example,
you
know
there
might
be
several
micro
services
involved
in
the
handling
of
a
particular
application
request,
and
if
at
every
single
hop
in
that
chain,
you
have
to
call
out
over
the
network,
then
it's
gonna
blow
your
SLA
you're,
not
gonna.
Believe
me,
your
your
your
SLA.
A
Similarly,
if
oppa
has
to
color
it,
rather,
if
your
service
has
to
call
it
over
the
network
every
time
it
has
to
make
a
decision,
then
the
network
might
get
slow.
It
might
go
down,
the
host
that
opens
running
on
might
die
and
then
your
service
will
be
able
to
get
policy
decisions
back,
and
so
it's
gonna
basically
fail
close
and
you're.
Not
me
serving
traffic
right,
so
you're
gonna
have
downtime,
so
oppa
from
the
very
beginning
was
designed
with
this
model
of
acting
as
a
host
local
cache
for
policy
decisions.
A
What
it
does
is
it
enables
distributed
policy
enforcement,
you
take
oppa
and
you
run
it
next
to
your
service.
In
order
to
make
that
happen,
we
made
certain
design
decisions
again,
so
the
first
of
which
was
that
all
the
policy
and
data
that
oppa
uses
to
make
decisions.
All
of
that
is
kept
in
memory.
When
you
ask
Oprah
for
a
policy
decision,
it
has
all
the
data
and
the
rules.
It
needs
to
resolve
that
that
query
and
send
back
an
answer.
A
So
it's
not
going
to
call
out
when
you
ask
it
for
a
decision
to
another
service.
It's
not
gonna.
Ask
another
service
for
more
data
on
its
own.
You
can
extend
oppa,
you
can
you
can
in
your
policy.
You
can
do
an
HTTP
call
out
to
get
more
data
and
you
can
extend
oppa
by
plugging
into
by
adding
a
plug-in
to
it,
to
call
out
to
get
more
data,
but
on
its
own,
it's
not
going
to
do
that
on
its
own.
It
has
all
the
policy
data
it
needs
to
make
decisions
in
memory.
A
Now
that
obviously
begs
certain
questions
which
are
you
know?
Where
do
the
policies
and
data
come
from
right?
You
can't
just
have
the
policies
and
data
sitting
in
memory.
I'd
hope
that
it
never
never
goes
down.
So
in
order
to
get
policy
and
data
down
to
oppa
and
in
order
to
control
and
observe
oppa,
we
have
a
set
of
management
api's.
So,
for
example,
we
have
the
bundle
service
API,
which
you
use
to
send
policy
and
data
down
to
oppa.
A
Basically,
oppa
will
periodically
call
out
to
the
bundle
service
and
ask
for
the
latest
version
of
policy
and
data,
and
if
there's
a
new
version,
then
it
gets
downloaded.
We
have
the
status
service
API,
which
you
can
implement
to
receive
status,
updates
from
oppa.
Those
status
updates.
Tell
you
whether
the
version
of
policy
and
data
that
oppa
has
activated
that
it's
currently
running
with
right,
so
you
can
use
this
to
detect,
you
know,
is
it
up-to-date?
A
Are
the
Europe
is
up-to-date
or
have
they
encountered
errors
in
trying
to
activate
the
most
recent
bundle
of
policy
and
data?
And
we
also
have
a
what
we
call
the
decision
log
service
API,
which
you
can
implement
to
receive
audit
logs
from
oppa?
So
every
time
oppa
makes
a
policy
decision.
It
keeps
a
record
of
that
policy
decision
and
then
it
periodically
uploads
batches
of
those
those
decisions
to
to
the
decision,
log
service
and
so
that
decision
log
service
is
useful
from
an
audit
perspective.
A
Now,
because
now
you
have
a
record
of
all
the
policy
decisions
that
have
been
made
by
all
the
oppa's
in
your
system,
but
it's
also
useful
for
capturing
data
for
things
like
debugging
and
test
purposes
and
then,
in
addition
to
all
the
the
management
api's,
we
have
tooling
that
help
you
basically
build
test
and
debug
your
policies.
So
we
have
an
interactive
shell
that
you
can
use
on
the
command
line,
to
experiment
with
policies.
A
We
have
a
test
framework,
so
you
can
actually
write
unit
tests
for
your
custom
policies,
which
is
really
useful,
for
you
know,
making
sure
that
your
policies
are
correct
right.
Part
of
the
idea
behind
OPA
is
that
policies
should
be
treated
as
code.
You
know,
just
like
you
want
to
treat
infrastructure
as
code
OPA
basically
delivers
policy
as
code,
and
so
we
give
you
a
framework
that
you
can
use
to
write.
You
know
unit
tests
for
your
policies.
A
Then
we
have
a
bunch
of
other
tools,
command
line
tools
that
you
know
format
your
policies
do
all
kinds
of
semantic
checks
as
well
as
IDE
integrations.
So
if
you
start
writing
policy
for
for
real
I
recommend
that
you
check
out
the
vs
code,
Visual
Studio
code,
plugin,
it's
it's
very
powerful.
It
helps
you
kind
of
interact
with
the
policies
inside
of
yeah.
A
This
is
a
new
service
that
we
that
we
created
earlier
this
year
and
the
service
has
some
nice
features
that
I'm
gonna
kind
of
run
through
and
explain,
explain
to
you
as
I
go.
So
this
is
the
policy
that
you
see
when
you
start
off
and
I
was
going
to
delete
that
and
so
to
implement
this
policy.
Remember
we
want
the
first
rule
basically
needs
to
say
that
employees
can
access
their
own
salary
and
the
second
policy
says
that
employees
can
access
the
salary
of
people
they
manage
so
to
implement
the
first
rule.
A
What
I'm,
gonna
do
is
create
a
rule
called
allow
and
I'm
gonna
say
that
allow
is
true
if
the
input
actually
wait.
Let's
back
up
a
second
in
order
to
test
this
out,
I'm
gonna
have
to
define
some
input
data
and
so
the
the
playground
lets
you
do
that
it
lets.
You
put
input
data
in
the
browser
here
and
so
I'm
gonna
say
that,
for
example,
the
input
method
is
get
again.
This
is
just
from
the
slides
before
and
the
path
say
is
salary
Bob.
A
So
this
is
a
lookup
for
Bob's,
salary
and
I'm
gonna,
say
the
user
making
the
request
is
Bob
so
to
write
the
rule.
For
the
first
case,
what
I'm
going
to
do
is
say:
I'm
gonna,
say
the
rule
is
called
allow
and
allow
is
true.
If
input
method
is
get
an
input
path
is
salary,
employee,
ID
and
input
user
is
employee,
ID.
A
So
this
rule
says
allow
is
true:
if
input
method
matches
get
an
input,
path,
matches
salary,
employee,
ID
and
input
user
matches,
employee
ID,
so
the
expressions
and
the
body
of
the
rule
are
ANDed
together.
The
interesting
thing
about
this
rule
is
this:
this
employee
ID
here
so
this
employee
ID,
is
a
variable
and
what
happens
when
oppa
evaluates
rules?
Is
it
looks
for
bindings
for
those
variables
values
for
the
variables
that
make
all
of
the
statements
in
the
body
of
the
rule?
A
A
But
if
I
change
this
change,
this
and
I
say
Alice
is
looking
at
Bob's
salary
oops,
then
it's
undefined.
The
reason
it's
undefined
is
because
none
of
the
statements
in
the
body
of
the
rule
match
so
typically,
what
you'll
see
in
Opa
policy
is
is
something
like
this
they'll
say
default.
Allow
is
false,
so
this
means
that
if
allow
doesn't
match,
then
it'll
take
this
default
value
on
and
now,
if
I
go
and
I
evaluate
this,
and
we
wait
for
the
network.
A
A
Allow
is
false,
so
what's
happening
here
is
that
hope
is
basically
telling
you
the
values
of
all
the
rules
in
the
body
and
right
now
we
only
have
one
rule,
it's
called
allow,
but
you
can
actually
go
further
than
that,
so
you
can
actually
select
parts
of
the
rule
and
hit
evaluate
and
it'll
print.
The
answer:
what
do
you
think
is
gonna
happen
when
I
do
this?
It's
now
we've
got
a
variable
inside
the
inside.
The
query.
B
A
It's
gonna
tell
us
the
value
of
that
variable
when
the
rule
got
evaluated,
and
in
this
case
it
got
down
to
Bob
all
right.
So
if
I
go
and
I
select
the
last
one,
it's
gonna
be
undefined
because,
obviously
input
user
does
not
equal
Bob,
it
doesn't
equal
employee,
ID,
okay,
so
that's
that's
the
first
part
of
the
policy
to
implement
the
second
part
of
the
policy.
A
We're
gonna
need
to
do
a
little
bit
more,
so
we're
gonna
need
some
data
in
this
case
to
decide
whether
or
not
one
employee
is
a
manager
of
the
other,
and
so
what
I'm
going
to
do
is
just
define
that
data
here
in
the
policy
I'm
only
gonna
do
this,
because
it
makes
it
easier
to
kind
of
show
and
to
interact
with
in
the
playground.
Typically,
this
kind
of
data
would
be
loaded
into
open
just
as
raw
JSON.
A
A
Allow
is
true:
if
input
method
is
get
and
input
path
is
salary,
employee
idea,
but
this
time
instead
of
checking
whether
the
input
user
is
the
employee,
ID
I'm
gonna
check
whether
the
input
user
is
a
manager
of
the
employee
and
so
to
do
that.
We're
gonna
do
a
look-up
on
the
managers,
so
we're
gonna
say
give
us
the
manager,
or
rather
the
managers
for
the
employee,
and
then
we're
gonna
ask
whether
the
input
user
is
inside
of
that
set.
So
one
of
the
things
that
you'll
find
in
Rago.
That's
very
frequent.
A
Are
these
these
references?
We
call
them.
These
are
basically
performing
lookups
on
these
JSON
documents,
and
so
now,
if
I
go
back
and
I
refresh
the
policy
decision
now,
it's
true
because
alice
is
a
is
a
rather
the
manager
of
Bob.
If
I
change
this
to
Bob
and
I
tried
to
get
Bob
to
look
up,
say,
Fred's
salary
that
would
be
rather
that'll
be
denied,
so
the
allow
will
be
false
now,
typically,
if
I
was
doing
this
for
real
I,
wouldn't
just
test
everything
with
with
the
input
data
here.
A
A
When
you
go
to
start
using
OPA
for
the
first
time,
you
might
be
looking
for
integrations
with
existing
projects
in
the
ecosystem,
and
so
we
have
a
number
of
them
and
I
think
they're
over
28
or
25.
Now
we
have
a
number
of
integrations
with
different
projects
for
doing
admission
control.
That's
one
of
the
main
use
cases
that
people
have
for
open
today.
They
want
to
enforce
different
kinds
of
policies
over
their
platforms,
and
so
for
that
we
have
integrations
with
kubernetes
people
use
OPA
with
terraform.
A
We
have
another
integration
with
docker,
that's
very
similar
and
the
idea
there
is
you
just
want
to
enforce
certain
policies
over
configurations
that
developers
are
supplying.
You
know
when
they
deploy
their
applications
right.
So
you
want
to
say
things
like
only
you
know.
Container
images
must
come
from
the
corporate
image
registry
or
you
want
to
say
that
all
workloads
need
to
have.
You
know
CPU
and
memory
limits
supplied
when
they're
when
they're
deployed
or
you
want
to.
You
know,
prevent
conflicting
aggresses
from
being
created.
A
For
example,
the
other
main
category
of
use
cases
we
have
is
around
API
authorization,
typically
in
micro
service
environments,
and
so
we
have
a
bunch
of
different
integrations
with
projects
like
sto
and
envoy
and
Kong
and
linker,
D
and
spraying
and
more
and
the
idea
there
is
that
you
want
to,
you,
know,
provide
you
know.
Obviously,
I
am,
or
you
know,
access
control
policies
for
you
for
your
internal,
you
know,
environments,
and
so
you
want
to
you
know.
You
know,
for
example,
deny
test
scripts
from
accessing
production
services.
You
want
to.
A
You
know,
prevent
analysts
from
accessing.
You
know
sensitive
data
and
so
on
and
so
forth,
but
we
have
a
long
list
of
other
integrations.
So,
for
example,
we
have
a
Pam
plugin
for
four
oppa,
where,
basically,
you
can
enforce.
You
can
use
open
to
enforce
access
control
policies
over
SSH
and
sudo.
We
have
one
user
of
oppa
where
basically
they
they
have
a
policy
in
place.
A
That
says
that
developers
are
only
allowed
to
ssh
into
machines
that
are
running
applications
that
that
developer
work
works
on
right
and
there
has
to
be
actually
an
open
ticket
for
that.
For
that
application
at
that
time,
otherwise
they
can't
get
on
the
machines
and
that
that
just
resolves
like
a
long-standing
problem
and
system
administration
of
people
getting
added
to
connect
groups
and
things
like
that
and
then
never
getting
taken
out
right.
A
So
this
way
you
know
you
have
a
flexible,
context-aware
method
of
enforcing
policy
over
SSH
and
sudo,
and
then
we
have
a
bunch
of
other
integrations
with
projects
like
safe
and
Kafka
and
Mineo
for
doing
different
kinds
of
data
protection
use
cases.
You
know
a
lot
of
large
organizations
are
building
out
data
lakes
internally
and
there's
definitely
a
need
for
you
know.
Fine-Grained
attribute
based
access
control
there
and
OPA
really
enables
that.
A
So
what
I
thought
I'd
do
is
just
highlight
a
couple
of
the
you
know:
users
that
are
that
are
running
with
open
today
in
production.
We
talked
about
some
of
this
a
couple
months
ago
at
the
CN
CF
TOC
meeting,
but
I'm
just
gonna
kind
of
highlight
them
again
here.
So
one
of
the
users
of
okhla
today
is
Netflix.
They
were
one
of
the
earliest
adopters
of
the
project
and
today
they're,
basically
using
OPA
to
enforce
a
variety
of
different
access
control
policies
across
there.
A
You
know
internal
environments
right,
so
they
have
a
large
micro
service
based
environment
and
they,
you
know
they
developers.
There
use
a
variety
of
different
languages
and
frameworks
and
they
have
different
kinds
of
execution
environments
where
these
services
run
and
so
that
the
challenge
there
was
to
find.
You
know
a
way
of
expressing
policies
over
this
very
heterogeneous
and
ephemeral
kind
of
you
know,
environment,
and
so
they
they
looked
at
OPA
and
they
decided
to
adopt
it
and
build
it
into
their
internal
security
platform.
A
And
what
they
found
was
that
the
ability
to
you
know,
leverage,
contextual
information
to
load
arbitrary
context
into
the
policy
engine
then
use
that
to
inform
policy
decisions.
They
found
that
very,
very
valuable
and
they
found
it
very
valuable
to
use
a
single
language
essentially
to
express
policies
across
a
wide
range
of
different
languages
and
frameworks,
and
so
we
have
actually
have
taught
from
coop
con
Austin
2017.
A
If
your
entrance
is
interested
to
see
how
they're
using
it
check
that
out,
another
company-
that's
using
open
today
for
a
similar
of
a
different
use
case
is
chef.
So
it's
again
it's
an
API
authorization
use
case,
but
it's
a
little
bit
different,
because
chef
is
obviously
software
vendor
they
ship.
You
know,
software
to
enterprises
and
anytime
you
ship,
a
software
product
to
an
enterprise.
You
have
to
deliver.
A
A
They
can
basically
take
oppa
and
with
a
bit
of
policy
in
place,
they're
able
to
deliver
an
AWS
I,
am
style
policy
to
their
customers
inside
of
their
products
and
actually,
today,
they're
also
using
some
more
advanced
features
in
Opa,
like
partial
evaluation,
and
so,
if
you're
interested
in
this
I
would
check
out,
it's
actually
open
source.
If
you
go
to
chef
automate
on
github,
you
can
find
examples
of
that
and
how
they've
architected
it
and
then
finally,
an
example
of
a
company.
That's
using
oppa
for
kubernetes
is
Intuit
so
into
it.
A
You
know,
uses
oppa
as
a
validating
and
mutating
admission
controller
in
kubernetes
and
they
use
it
to
enforce
a
variety
of
different
security
and
multi-tenancy
and
risk
management
policies
across
a
large
set
of
clusters
and
a
large
set
of
namespaces
for
them.
They
run.
You
know
large
multi.
They
have
large
multi
tenant
workloads
deployed
on
kubernetes,
and
it's
very
important
that
they're
able
to
put
kind
of
safeguards
in
place
to
prevent
different.
You
know
applications
from
interacting
with
each
other
in
bad
ways
and
again
we
did.
A
We
did
a
talk
with
them
at
coop,
con
seattle
in
2018,
so
if
you're
interested
in
admission
control
in
kubernetes
and
how
companies
like
Intuit
and
Capital
One
are
using
using
opa
bert
for
that
check
out
that
talk,
so
that's
it.
We've
got
about
four
minutes
left
for
questions,
I'll
point
out
that
there
are
two
talks
later
today
that
are
related
to
policy.
So
one
is
the
talk
on
gatekeeper
by
Craig
Peters
at
Microsoft.
That's
it's
6:15!
A
There's
also
the
the
kubernetes
policy
working
group
deep
dive
session
from
Howard
at
Huawei
happening
at
the
same
time,
so
you'll
have
to
pick
which
one
you
want
to
go
to,
but
both
of
those
should
be
great
sessions
if
you're
interested
in
the
code
behind
the
project
check
out
open
policy
agent,
slash
OPA
on
github
and
if
you
have
questions
or
anything
like
that,
feel
free
to
join
the
slack
organization
and
post
your
questions
on
there.
So
with
that
I'm
happy
to
do
some
Q&A
right
now,
if
anybody
has
questions
otherwise.
A
There
are,
there
are
people
looking
at
using
OPA
to
generate
the
claims
that
go
into
it
into
a
token.
You
can
definitely
do
that
because
those
are
that's
just
JSON,
so
it's
just
a
different
kind
of
policy
decision.
We
don't
have
specific
examples
of
that
on
the
website.
What
we
do
have,
though,
in
OPA,
is
a
set
of
built-in
functions
for
doing
things
like
string,
manipulation
and
math
and
all
that
kind
of
stuff,
but
we
also
have
built-in
functions
for
interacting
with
JSON
web
tokens.
A
B
D
A
Both
similar,
they
both
aim
to
you,
know,
allow
you
to
express
policy
as
code
I
guess.
The
main
difference
at
a
very
high
level
is
that
sentinel
is
you
know
it's
a
closed
source
proprietary
feature
of
their
enterprise,
hashey
core
products
right,
so
it's
not
open
source
and
it's
really
I
think
focused
those
kinds
of
policies
that
you
apply
to.
You
know
the
platform
right
to
hash.
Your
projects,
right,
like
vault
and
terraform,
and
so
on.
A
So
OPA
is
a
little
bit
more
general
purpose
and
that
you
can
kind
of
use
it
as
a
like
a
building
block,
a
library
for
all
kinds
of
different
policies
at
different
levels
of
the
stack
at
the
language
level.
There
are
some
differences
opens
a
little
bit
more
declarative,
whereas
the
sentinel
language
is
a
little
bit
more
imperative,
it's
more
like
JavaScript,
which
has
pros
and
cons
associated
with
it.
So
I
can
I'm
happy
to
chat
about
that
more
offline.
If
you're
interested
it's
a
pretty
long
answer.
B
E
A
The
binary
is
about
20
megabytes
in
size,
so
the
memory
usage
is
fairly
low
about
20
megabytes
if
you're
just
running
it
without
anything
inside
of
it.
Obviously,
the
amount
of
memory
that
it's
gonna
consume
at
runtime
depends
on
how
much
policy
and
data
you
load
into
it.
So
it
kind
of
depends
on
the
types
of
policies
you
need
to
express,
but
it
is,
it
is
fairly
lightweight.
We
don't
have
very
many
dependencies
in
the
project
itself.
A
It's
written
in,
go
so
I,
don't
know
how
how
that
would
work
for
your
environment,
but
that's
one
thing
to
keep
in
mind.
I
will
mention
that
one
of
the
things
that
we're
working
on
that's
more
speculative
learn
more
long
term
is
support
for
taking
the
OPA
policies
and
compiling
them
into
web
assembly,
and
so
with
that
I
think
we
might
be
able
to
deliver
like
an
even
smaller
memory
footprint
for
the
policy
innovation
yeah.
A
F
A
F
A
It
should
be,
it
can
be
hitless,
so
there
are
two
ways
of
loading
policy
and
data
into
OPA.
One
is
through
the
bundled
service
API
that
I
mentioned
basically
open,
will
periodically
download
policy
data
from
a
remote
service
and
reload
it
on
the
fly
without
affecting
policy
queries.
The
other
is
that
you
can
push
policy
and
data
into
OPA.
It
has
an
API
allows.
You
just
push
policy
and
data
in
through
HTTP
API.
That
works.
It's
a
little
bit
more
complicated
I.
A
F
A
A
good
question
so
so
open
itself
is
just
the
decision
engine
all
it
does.
Is
it
just
says,
given
the
policies
that
you
give
it,
you
know,
answer
answer
questions
right:
it
doesn't
decide
which
policies
go
down
to
OVA
right.
So
that's
sort
of
up
to
you
as
the
implementer
of
the
control
plane
around
OPA.
That's
sort
of
that's
sort
of
the
challenge
that
we
don't
tackle
within
OPA
itself.
Thank.
B
A
So
we
sort
of
have
two
profiles
for
OPA
policies:
one
profile
is
kind
of,
or
we
call
it
the
linear
time
profile
or
linear
time,
fragment
of
lopa
and
that's
sort
of
targeted
at
API
authorization
policies.
If
you
do
write
your
policies
in
a
way
that
is
that
falls
into
that
fragment,
then
OPA
will
index
the
the
rules
for
you
and
it
can
answer
policy
queries
in
like
under
100
microseconds
in
a
lot
of
cases
or
under
a
millisecond
is
usually
our
budget.
That's
the
number
that
we
got
from
Netflix.
The
other
category
of
use.
A
Cases
is
like
more
around
platform
kind
of
policies
over,
say
a
kubernetes
cluster,
and
in
that
case
you
often
have
to
do
a
large
search
over
like
the
state
of
the
cluster
in
order
to
make
the
decision,
and
so
there
the
the
budget
for
latency
is
a
little
bit
higher
because
of
that
search
operation
right.
So
it
depends
on
the
on
the
use
case,
but
typically
under
a
millisecond
for
API
opposition.
Okay,.