►
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
OPA helps you unify control and visibility of policy enforcement throughout your system. Today you can leverage OPA to enforce policies across the stack in modern projects like Kubernetes, Istio, and Terraform as well as with older (more established technologies) like Linux PAM. This session will introduce the OPA project, use cases, and integrations and include a short demo. The session will also include an overview of how you can get started contributing to OPA in the form of core development, integrations, and policy libraries. If you are interested in learning about how to use OPA or how you can get started contributing to the project, this session is for you.
To learn more: https://sched.co/Grbn
A
A
What
I'm
gonna
do
today
is
give
a
little
bit
of
a
background
on
the
project
and
then
our
quick
crash
course
into
how
opal
works
specifically
around
admission,
control
and
kubernetes,
and
then
I'm
gonna
hand
it
over
to
Zach
and
Todd
from
Capital,
One
and
Intuit
respectively,
who
are
gonna
talk
about
how
they're
using
OPA
to
do
admission,
control
in
kubernetes
in
production
and
then
at
the
end,
we'll
have
time
for
Q&A.
So
please
save
your
questions
to
the
end
for
all
of
us.
A
Okay,
so
the
open
policy,
agent
or
OPA
is
a
general
purpose
policy
engine
and
what
that
means
is
that
you
can
take
OPA
and
you
can
basically
use
it
in
any
system
at
any
layer
of
the
stack.
So
the
goal
of
the
project
is
to
provide
a
building
block
or
a
library
or
a
component
that
allows
you
to
unify
policy
enforcement
across
a
range
of
different
technology.
So
we
started
the
project
back
in
2016
early
2016
three
years
ago
at
steerer.
A
The
company,
where
I
work
and
over
the
last
year,
or
so
we've
seen
a
lot
of
growth
in
terms
of
the
number
of
people
that
are
actually
using
the
project
in
production.
So,
for
example,
companies
like
Netflix
are
using
OPA
to
enforce
authorization,
decisions
or
authorization
policies
across
all
kinds
of
internal
resources.
Companies
like
chef,
are
embedding
OPA
into
products
to
provide
end
user
authorization
to
their
customers.
A
Companies
like
Medallia
are
leveraging
OPA
to
manage
risk
in
their
infrastructure,
and
then
there
are
dozens
of
companies
that
are
running
open
a
day
in
kubernetes
for
admission
control,
so
it's
pretty
cool.
This
is
where
we're
at
today.
We
have,
you
know
dozens
of
companies
using
the
project
across
a
ride,
a
bunch
of
different
industries
for
different
use
cases,
we're
part
of
the
CNC
f.
Now
we
joined
earlier
this
year
in
April
and
we're
a
sandbox
tier
project,
so
it's
still
early
stages,
but
the
trends
are
pretty
encouraging.
A
A
Okay,
so
anytime,
you
want
to
enforce
a
policy
that
says
that
you
know
all
deployments.
Have
these
these
labels
on
them
like
cost
center
or
contact,
or
you
want
to
restrict
the
the
host
names
in
an
ingress
object
or
you
want
to
prevent
you
know
vulnerable
images
from
being
deployed.
You
need
to
use
an
admission
controller
now.
A
The
challenge
with
admission
control
is
that
the
inputs
to
the
to
the
emission
control
decision
are
very
complicated,
right
they're,
these
complex,
deeply
nested
data
structures
that
you
find
that
you
work
with
in
llamó
files
all
the
time,
and
so
you
know
the
question
becomes
how
do
I
codify
or
Express
rules
that
force
invariance
on
the
system.
Moreover,
a
lot
of
the
time
these
policies
are
very
organization,
specific
right.
Everybody
has
a
slightly
different
way
that
they
run
kubernetes,
and
so
the
policies
reflect
that
and
then,
on
top
of
that,
a
lot
of
the
time.
A
The
policies
that
people
on
to
enforce
it
depend
on
context.
They
depend
on
data
or
information
from
other
systems
in
the
organization
right,
and
so
you
know,
if
you
take
all
these
requirements
and
you
you
try
to
come
up
with
a
language
to
to
codify
these
kinds
of
rules.
You
end
up
with
something
very
similar
to
OPA
or
opus
policy
language,
so
the
language
that
OPA
gives
you
is
kind
of
purpose-built
for
dealing
with
these
deeply
nested
data
structures.
You
can
kind
of
dot
into
them
and
search
over
them
and
express
assertions
you
can.
A
You
know,
leverage
external
context
in
your
policies
and
one
of
the
neat
properties
of
OPA
and
all
the
policies
that
you
write
with
OPA
is
that
you
can
query
them
in
different
ways.
So
not
only
can
you
take
them
and
deploy
them
for
enforcement,
but
you
can
also,
you
know,
ask
different
questions.
You
can
say
you
know:
I
want
to
dry
run.
This
I
want
to
run
this.
A
A
So
the
way
that
oppa
works
with
kubernetes
is
similar
to
every
other
integration
we
have
for
with
OVA.
It
exists,
so
basically
decouple
or
off
load
policy
decisions
from
some
service.
In
this
case
the
service
is
the
API
server
right.
So
anytime
you
run
you
know,
coups
ETL,
apply
or
coups
ETL
create.
There's
a
request
that
goes
to
the
API
server
and
inside
of
that
request.
There's
a
you
know:
declarative
resource
spec
that
defines
the
pod
or
the
you
know,
the
ingress
or
whatever,
and
that's
where
the
policy
has
to
get
enforced
right.
A
And
so
what
happens
is
that
the
API
server
calls
out
to
oppa
and
it
supplies
the
entire
extent
of
the
resource
to
two
oppa
and
then
open
takes
that
that
that
that
JSON
object
effectively
and
it
evaluates
it
against
the
policies
that
it
has
access
to
to
produce
a
decision
like
allow
or
deny
now,
in
the
case
of
admission
control,
it
also
produces
additional
information
right.
So
it's
really
important
that
you
can.
A
You
know
trace
why
the
you
know
you
why
your
deployments
being
rejected
or
why
your
ingress
is
being
rejected
right
and
so
the
the
policies
that
you
write
with
oppa
can
generate
those
error
messages.
They
can
say
that
you
know
you
didn't
supply
these
labels,
like
you,
didn't
supply
cost
center,
but
you
need
to.
A
B
Thanks,
hey
everybody,
so
Abrahamson
I'm
with
Capital
One
cloud
engineering,
where
the
internal
engineering
org
that
manages
everything
from
AWS
and
we're
really
trying
to
spin
up
kubernetes
solving
all
those
repetitive
problems
that
everybody
does
in
the
enterprise
in
kind
of
one
single
place
so
that
we
can
make
them
usable.
You
know
everywhere
from
our
car
division
to
our
auto
finance
division.
So
a
little
bit
about
me
already
nailed
that
first
part,
but
so
our
tooling
Network
building
is
basically
a
one
canonical
way
to
do.
B
B
So
a
lot
of
controls,
a
lot
of
things
from
InfoSec
that
are,
you
know,
kind
of
declared
in
a
design
document
somewhere
that
it's
kind
of
up
to
us
to
make
sure
that
all
of
our
tooling
and
clusters
are
in
compliance
with
so
Tory
briefly
hit
on
it.
I
know
this
is
an
intro
session,
so
real
quick
for
admission,
those
of
you
that
aren't
familiar
with
the
mission
controllers,
they're
just
code
that
lets
you
collect
you,
police,
the
incoming
changes
to
your
cluster.
B
We
want
to
give
people
guardrails,
we
want
to
let
them
take
advantage
of
as
much
as
possible
of
kind
of
the
native
services
without
being
too
heavy-handed
and
like
really
hitting
them
over
the
head
saying.
This
is
the
exact
way
you
do
this
thing
and
and
opah.
Definitely,
let's
just
do
that
and
end
to
it
to
enable
them.
B
So
if
I
don't
necessarily
have
to
know
what
namespace
I'm
going
to
end
up
in
you're
gonna
rewrite
that
for
me
and
then
I'll
talk
more
about
the
first
one
should
put
those
in
the
absolute
validating
and
that's
just
going
to
be
the
simple
yes/no
based
on
based
on
policies
so
for
capital.
One
I
already
talked
about
security,
so
governance
for
us
is
pretty
big.
B
We
have
an
AWS
today
we
have
about
450
accounts,
kubernetes
is
growing
in
each
of
those
accounts
and
we
need
a
way
to
know
what
our
workloads
are
running,
who
owns
them,
who
we
can
contact
who's
responsible
for
them
and
a
double?
Yes,
we
use
tags
kubernetes.
We
use
labels
right
so
governance
with
labels.
Opa.
Definitely
lets
us
do
that
configuration
management
as
part
of
these
cluster
builds.
We
have
certain
admin
config
like
route
ingress
default
route
and
gross
and
stuff
that
we
don't
want
people
to
be
able
to
stomp
on.
B
So
it
lets
us
kind
of
keep
our
configuration
separate
from
the
configuration
people
are
trying
to
bring
and
scoping
as
well.
So
if
somebody
wants
to
write
a
policy,
that's
specific
to
a
certain
object
or
namespace,
they
can
do
that
and
not
run
into
everybody.
There's
need
to
be
one
canonical
policy
for
this
one
big
object
and,
at
the
end
of
the
day,
risk
is
our
business
being
a
financial
institution
so
anytime
that
we
can
have
an
extensible
way
to
codify
the
risk
that
comes
down
from
InfoSec
or
compliance.
B
It's
a
huge
win
right,
and
if
we
can
do
that
for
our
customers
and
users
for
free
internal
customers,
users
for
free,
even
better
win.
So
what
we
like
about
them
is
that
you
know
they're
just
a
set
of
rules
that
kind
of
govern
the
behavior
of
your
service.
It's
really
easy
logical
leap
to
go
from
that.
B
You
don't
have
to
say
this
is
how
I'm
going
to
handle
all
deployment,
creates
and
then
yeah
minimal
lines
of
code.
So
how
many
folks
are
running
in
an
enterprise
environment
with
kubernetes
today,
quick
show
of
hands
yeah.
So
this
is
a
real,
simple
yeast
case.
We
did
not
know.
Liz
was
gonna,
give
the
talk
this
morning,
so
she
already
hammered
this.
B
If
you
guys,
if
you
guys,
saw
that,
but
for
those
of
you
that
don't
want
shear
developers
or
engineers
pulling
images
sourcing
images
from
the
internet,
you
probably
have
an
internal
image
repository
and
you
want
to
kind
of
lead
them
towards
that.
So
this
is
the
actual
policy
we
use
in
our
clusters.
A
couple
helper
functions
are
emitted
here,
but
if
you
see
that
the
first
thing
here
we're
gonna
actually
declare
this
in
our
kubernetes
admission
package
and
we're
going
to
use
the
kubernetes
namespace
module
that
lets
us
kind
of
parse
out
everything.
B
It's
a
deny
policy.
That's
going
to
respond
with
the
message,
that's
kind
of
defined
below.
If
you're,
not
in
compliance,
we're
gonna,
listen
for
any
time,
somebody
tries
to
send
a
create
of
a
deployment
to
the
API
server
and
if
it
doesn't
match
anything
in
the
valid
deployment
registry
spec
there
we're
gonna
go
ahead
and
deny
right.
So
you
see
right
there,
I
removed
it
for
kind
of
internal
security
reasons,
but
instrument,
registry
or
URL,
replace
that
with
whatever
you're
using
artifactory,
something
else.
It
really
is
as
simple
as
that.
B
This
is
a
really
you
know
popular
use
case,
I'm
sure,
if
you
guys
aren't
doing
it
already.
You're
gonna
want
to
do
it.
It
is
really
as
simple
as
that,
and
that
covers
probably
the
most
popular
use
case,
I've
seen
for
admission
control
in
the
enterprise.
So,
in
addition
to
that,
we
can
enforce
annotations,
so
our
our
cloud
custodian
product
a
lot
of
what
it
does
in
AWS
OPA
lets
us
do
in
kubernetes,
right
off
the
bat
we
can
prevent
unwanted
changes.
B
So
if
we
have
a
certain
protected
resource
set,
we
can,
you
know,
deny
all
changes
that
are
incoming
to
that
and
and
lastly,
this
lets
us
have
a
framework
in
a
domain
agnostic,
nature
of
OPA.
We
can
kind
of
use
this.
You
know
to
take
all
those
incoming
new
security
holes,
new
use
cases,
new
risk
management
operations
and
put
them
into
policy
at
a
later
date.
B
We're
doing
all
of
this
today
in
capital,
one
very
straightforward,
very
common
use
cases
that
that
I'm
sure
the
other
private
enterprise
users
so
a
little
bit
about
how
we
deploy
this
oppa
has
just
deployed
as
a
REST
API
in
a
container,
and
then
we
put
a
service
in
front
of
that.
The
the
pod
has
a
service
account
cluster
role,
cluster
role,
binding
the
policies
live
in
config
maps
and
then
a
sidecar
container.
B
So
lessons
learned
in
future
direction.
I
don't
want
to
sound
too
much
like
a
shill
for
OPA,
but
this
was
probably
the
only
thing
we
ran
into
and
torm
was
nice
enough
to
help
out
my
colleague
Jimmy
to
fix
it.
We
were
having
issues
where
the
web
hooks
weren't,
making
it
to
open
server
and,
as
probably
our
stupid
issue,
all
we
had
to
do
was
add
SVC
to
our
no
proxy
rules
very
straightforward.
B
There
were
some
red
herrings
there
that
I
think
some
other
folks
had
run
into,
but
they're
not
immediately,
indicative
of
anything
and
then
future
integration.
We
do
have
our
cloud
custodian
product,
it's
more
of
an
after-the-fact
governance.
If
you
want
to
go,
do
scanning
and
you
want
to
go,
say:
hey
who's,
all
who's,
all
running
deployments
that
are
labeled
with
you
know:
X
Y,
&
Z.
B
Let's
take
some
action,
so
I
think
open
and
clucksten
can
really
complement
each
other
and
I
think
going
forward,
as
you
saw
in
the
previous
slide,
we're
doing
all
of
our
policy
management
at
cluster
provision
time.
So
it's
really
tightly
coupled
to
that
process,
I'd
like
to
see
them
split
out
right,
so
there's
no
need
that
policies
need
to
be
baked
in
it
cost
for
provision.
You
can
have
a
service
that
maybe
connects
the
multiple
kubernetes
clusters
that
takes
this
codified
policy
and
applies
as
needed.
B
Well,
I
only
had
my
hiring
pitch
slide
left
anyway,
uh-huh,
so
we're
at
booth,
P
11
we're
hiring
from
cool
we're
hiring
from
everything
from
go
developers
to
sres
on
our
kubernetes
platform
team.
Definitely
reach
out
and
there's
a
medium
article
for
this
talk
that
my
colleague
that
was
suppose
to
give
this
talk.
Was
that
wrote
really
good
it's
out
there.
That's
a
bitly
link
to
it.
So
thanks
and
we're
gonna
do
questions
at
the
end.
C
Thanks
yeah,
so
Todd
I
can
stand
from
Intuit
I'm
gonna
be
talking
about
how
we
use
open
to
build,
secure,
multi
tenant
clusters,
so
first
kind
of
give
a
high-level
view.
I
work
as
part
of
the
modern
SAS
team
head
into
it.
There's
a
lot
of
interesting
stuff
going
on
here,
but
really
what
we're
focusing
on
here
is
the
lower
level
kubernetes
secure,
multi
tenant
clusters
that
we
provide
to
our
developers
and
hope
as
a
key
part
of
that.
C
So
really
why
OPA
we
already
talked
about
it,
validating
and
mutating
weapons
right,
so
it
makes
it
easy
to
write
policies
that
you
can
use.
So
I
wanted
to
go
back
to
one
of
Torn's
earlier
slides
just
to
draw.
You
know,
drill
home
about
the
mutating
web
hooks,
so
the
input
can
be
any
JSON
value,
and
that's
that
would
be
your
pod
spec
or
any
any
spec.
That's
coming
into
the
API
server
and
the
output
can
also
be
any
JSON
value
and
what
you
do
in
the
middle.
C
So
it's
a
special
type
of
admission
controller
as
a
mutating
admission
web
book
and
you
can
have
multiple
web
hooks
that
match
that
request,
get
executed.
Oh
they'll
be
executed
serially,
and
so
you
can
make
multiple
changes
to
the
same
object
depending
on
how
you
want
to
to
layer
those
and
it
runs
in
the
mutating
phase
of
processing
the
API
web
server
calls.
C
So
how
do
we
use
this
for
multi-tenant?
So
at
Intuit
each
tenant
is
assigned
a
namespace
within
a
given
cluster
and
then
in
that
namespace
we
only
allow
that
tenant
to
run
their
pods
their
resources
on
certain
nodes,
and
so
what
we
could
do
is
we
could
tell
all
the
clients
hey
go,
make
sure
you
put
in
a
node
selector
into
all
your
requests
and
put
in
toleration
x'
all
your
requests,
but
we
don't.
We
want
to
offload
that
burden
for
them.
C
C
So
then,
this
next
slide,
like
I,
said
I
was
thinking
about
taking
it
out,
but,
as
our
CEO
says,
repetition
doesn't
spoil
the
prayer
he's
famous
for
saying
that,
so
this
goes
back
to
validating,
using
a
validation,
a
web
hook
to
make
sure
you're
only
pulling
from
your
own
approved
internal
repository.
So
if
you're
not
doing
that,
definitely
do
that
really,
the
basically
the
way
it
works
is
you
know
here
you're
trying
to
pull
something
from
docker
I/o.
C
The
admission
web
hook
denies
that
here
your
change
that
same
request,
you're
pulling
it
from
your
own
repository
and
it's
allowed
alright.
So
that's
the
basic
idea,
so
other
use
cases
we
might
we
also
like
to.
We
also
want
to
deny
request
to
create
a
load
balancer
without
the
load.
Balancer
source
ranges
to
avoid
opening
up
that
load
balancer
to
the
internet,
for
example,
we
might
have
other
policies
to
there
more
for
correctness
to
fail
fast,
so,
for
example,
preventing
ingress
objects
from
being
created
with
the
appropriate
security
group.
C
The
other
thing
I
wanted
to
mention
was
unit
testing,
so
oppa
can
be
run
standalone
outside
so
as
part
of
your
CI
system,
and
that
allows
us
to
do
unit
tests
of
policies,
and
you
know,
as
open
becomes
more
and
more
critical
to
our
infrastructure
testing
is
it's
very
important,
especially
as
the
policies
become
complex
so
on
the
the
right
side?
There's
just
an
example
of
you
know:
testing
that
use
case
of
an
allowed
image
versus
a
denied
image.
C
Some
challenges
and
future
direction
for
us
what
we'd
really
like
to
do
is
to
die
by
default.
All
API
requests,
if
hope,
is
not
available,
so
really
lock
down
the
server,
but
there's
sort
of
a
chicken
and
egg
problem
there.
If,
if
hope,
is
not
available,
then
you
want
to
fix
oppa
by
doing
something
through
the
API
server.
So
how
do
you
do
that
right?
So
that's
the
challenge
that
we
still
need
to
work
out,
but
really
we
need
to
have
oppa
running
and
an
H
a
you
know:
high
availability
and
environment.
C
The
other
thing
is
we'd
like
to
have
an
opus
erd,
so
we'd
like
to
apply
policies
using
normal
kubernetes,
constructs
and
I.
Think
there
is
a
project
someone's
working
on
for
that
also
include
vulnerability
scanning,
like
was
mentioned
in
the
keynote
and
more
fail-fast
checks,
so
now
I'm
going
to
escape
out
to
a
live,
pre-recorded
demo
and
glad
you
guys
got
the
joke
there.
C
So
this
node,
so
we're
going
to
take
a
look
at
that
node
233
described
node
and
really
what
it
is.
It
comes
down
to
having
the
right
labels
and
having
the
right
taints.
So
that's
preventing
other
users
for
utilizing
that
those
nodes
now
we're
going
to
apply
a
pod,
try
to
launch
a
pod,
but
you'll
notice.
We
get
a
deny
because
we're
not
allowed
to
pull
from
docker
do
right.
This
is
the
admission
web
hook.
So
let's
take
a
look
at
what's
going
on
we're
going
to
look
at
our
pod
spec
we
go
over.
C
Now
one
thing
on
to
point
out:
we
probably
could
have
used
a
mutating
web
book
right
to
correct
that
from
the
user,
but
just
because
we
could
doesn't
mean
we
should
right
so
I
think
when
you're
looking
at
versus
you
know
admission
web
book
versus
mutating
web
book
really
decide
what
you
want
to
do.
You
don't
want
to
give
your
developers
unexpected
behavior.
It's
I
think
it's
better
to
fail
in
this
case.
C
So
now
we're
applying
the
pod
the
pod
was
successfully
created.
Now,
let's
take
a
look
now
we
want
to
look
at
the
yeah
mol
of
the
running
pod
I'm.
Sorry,
then,
then
we
see
that
it
is
running
on
node
233,
as
we
expect
as
we
want
now
we're
going
to
look
at
the
the
yamo
of
the
running
pod
and
compare
that
to
the
yamo
that
we
we
specified
as
the
input.