►
From YouTube: Policing Your Kubernetes Clusters with Open Policy Agent (OPA) - Mark Puddick & Amith Nambiar
Description
Join us for Kubernetes Forums 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
Policing Your Kubernetes Clusters with Open Policy Agent (OPA) - Mark Puddick & Amith Nambiar, Pivotal
Open Policy Agent (CNCF project) is a full-featured policy engine that offloads policy decisions from your Kubernetes cluster to an external service.
Policies are essential to the long-term success of an organization, because they encode important knowledge about how to comply with legal requirements, avoid repeating mistakes, and so on.
For example, a custom policy could be that developers are ONLY allowed to reference container images in their Deployments from your own Private registry. Other could be , Developers must have certain labels be present in all deployment definitions identifying the business unit to chargeback to.
Join us as we take you through configuring and deploying custom policies using the Open Policy Agent. We will cover some common policies used in enterprises and walk you through how to implement them in OPA using Rego. Rego is OPA’s native query language.
A
A
You
open
policy
agent
is
a
general
purpose
policy
engine
and,
as
part
of
our
job
mark
and
I,
get
to
speak
to
a
lot
of
customers
and
prospects
who
are
planning
to
adopt
kubernetes.
So
there
is
this
one
question
that
comes
up
always
is:
how
do
we
implement
policies,
custom
policies
on
kubernetes
policies
which
they
were
used
to
implementing
within
their
organization,
probably
for
running
their
apps
other
apps?
How
do
we
do
that
on
kubernetes
right
before
I
get
into
the
crux
of
the
talk?
How
many
of
you
are
quick
show
of
hands?
A
So
the
agenda
for
today
is
it's.
An
introduction
to
open
policy.
Agent
mark
will
be
introducing
open
policy
agent.
It's
also
called
as
OPA
and
he'll
be
talking
about
the
architecture
of
OPA,
and
how
does
it
fit
in
with
kubernetes
right
and
after
that?
I
will
be
talking
about
Rhaego,
which
is
a
policy
language
which
is
used
to
order
your
policies
and
then
do
a
demo
on
how
it
all
works
together,
and
hopefully
the
demo
works.
What
do
you
Mike?
Okay,.
B
Thanks
I
mean
so
I'm
gonna
talk
a
little
bit
about
what
opera
is
I'm
gonna
talk
a
little
bit
about
what
policies
are
and
I'm
gonna
talk
a
little
bit
about
the
architecture
of
oak
there's,
a
few
different
versions
of
it.
So
I'm
going
to
sort
of
outline
the
difference
between
those
versions.
So
I'll
start
with
OPA.
It's
a
what
it
is.
B
It's
a
unified
policy
toolset
across
the
cloud
native
stack,
which
is
a
bit
of
a
mouthful
and
so
we're
going
to
kind
of
break
that
down
a
little
bit
into
a
little
bit
or
easier
to
understand
what
it
is.
So
it's
a
general
purpose
policy
engine.
So
what
a
policy
engine
kind
of
does
so
guess
is.
It
takes
some
information
from
anna
kubernetes
point
of
view.
It
takes
it
from
a
resource
and
we'll
pass
that
through
a
policy
engine
and
can
either
mutate
that
resource
or
it
can
reject
that
resource.
B
So,
if
you
think
about
the
way
that
kubernetes
works,
it's
obviously
it's
a
declarative
system.
We
have
resources,
they're
all
defined
generally
in
nominal
files,
and
then
we
have
controllers
that
kind
of
watch
those
resources
and
they
keep
your
cuban
eddie's
system
running.
Ask
your
resources,
so
one
of
the
things
to
update
this.
You
go
through.
Obviously
the
Cuban
Eddy's
API
and
one
of
the
things
that
kubernetes
api
has
Admission
controllers
and
we'll
talk
about.
B
I'll
talk
a
little
bit
about
that
as
we
go
through,
and
those
emission
controllers
will
allow
you
to
basically
mutate
and
validate
your
your
resource
updates,
and
this
is
really
where
all
perfect
saying
it
will
come
in
and
it
will,
it
will
hook
out
from
those
web
hooks
effectively
and
it
will
validate
what
you're
doing
so.
You
can
use
this
to
kind
of
enforce
governance
rules
and
you
can
use
it
for
things
for
kind
of
all
sorts
of
stuff.
B
So
if
you
think
of
any
that
need
to
find
a
resource,
you
can
kind
of
pretty
much.
You
can
kind
of
pretty
much
validate
that
so
things
like
which
registries
to
pull
from
network
policies,
that
kind
of
stuff
anything
you
would
define
and
container
capability.
So
you
know
what
kind
of
the
size
of
CPU
that
kind
of
stuff
you
have
in
it.
B
So
that's
all
that
kind
of
stuff
you
can
easily
validate
and
you
can
mutate
up
to
a
point
and
I'll
talk
a
little
bit
about
that
as
we
go
through,
so
the
policies
are
defined
in
DSL
called
regal,
which
I
think
I
mentioned
in
his
introduction.
So
he's
going
to
talk
a
little
bit
more
about
that
later
in
the
talk,
but
it's
effectively
a
DSL
that
processes
effectively
a
resource,
I
guess
to
check
various
things
on
it
and
provide
whether
you
can,
whether
it's
you
know
invalid
or
on
my
guest.
B
You
store
the
Regal
and
config
maps,
so
pretty
easy
to
set
up
just
goes
and
takes
inky
like
everything
else,
except
and
in
version
3
there's
also
custom
resources
around
that
as
well.
We'll
talk
a
little
bit
about
as
we
go
through
the
difference
and
their
architectures
between
the
various
versions
of
of
OPA.
B
So
a
couple
of
concrete
examples
of
a
ser
policy.
It
might
be
that
we
come
up
to
holiday
period
at
the
moment.
So
it
might
be
something
like
you
know:
you
might
have
a
production
black-eye
period
you
could
use
a
you
could
actually
set
up
a
policy
for
that
to
say
that
no
one
completion
or
no
one
can
run
deployments
in
production.
You
might
have
some
GPU
nodes
in
your
cluster
that
you
want
to
stop
anyone
using
apart
from
seeing
your
data
science
team,
so
that
would
be
kind
of
another
type
of
thing.
B
So
this
is
kind
of
things
you
can
do
and
I
think.
Finally,
there
I've
got,
you
might
have
a
check
to
see
the
whole
internet-facing
services
are
using
HTTP.
So
I
think
the
example
that
emits
gonna
go
through
later
in
the
talk
is
actually
around
restricting
which
container
registry.
So
you
can
pull
from
right,
yeah,
yeah,
ok,
so
I'm
going
to
go
through
so
kind
of
quick
overview
of
what
it
is,
we'll
quickly
go
through
the
sort
of
architecture
and
we'll
start
at
v1,
or
actually
we'll
talk
about
mission
controllers.
B
First,
so
I
mentioned
mission
controllers
earlier
and
just
to
give
you
a
quick
overview
of
what
they
are
and
from
the
kubernetes
documentation
here
which
I'll
read
out,
for
you
is
an
administrator
and
admission
control
is
a
piece
of
code
that
intercepts
Quest
the
Cuban,
Eddy's
API
server
prior
to
persistence,
the
object,
but
after
the
requesters
authenticate
and
authorize.
So
that's
quite
key.
So
a
she
request
comes
into
the
API
server
it's
going
to
get
then
ok,
that's
going
to
get
authorized.
Then
it's
going
to
go
to
what
we
call
it's
a
mutating
web
hook.
B
That's
going
to
pass
out
to
OPA,
so
you
might
have
something
on
there.
Like
you
have
labels,
for
instance,
then
you
need
to
have
a
required
labels
on
your
deployments
and
you
can
make
her
all
Park
effectively
mutate
that
and
add
that
for
you
and
after
it's
gone
through
the
mutating
one
and
then
goes
through
the
validation
once
which
effectively
is
going
to
return,
it's
a
web
pick
is
going
to
return
a
yes
and
your
response
on
whether
or
not
that's
valid,
and
if
it's
invalid.
B
Okay,
so
if
we
talk
look
at
the
different
architectures
I've
made
these
really
simple
these
diagrams.
So
you
know,
then
we
can
follow.
The
knees
is
probably
a
bit
more
complexity
in
reality,
and
so,
if
you
think
about
this
is
v1,
so
v1
is
probably
what
most
people
are
using
today
from
an
OPA
point
of
view
and
there's
actually
a
couple.
B
Two
more
versions
and
I'll
quickly
go
through
those
as
well,
but
I'll
quickly
talk
through
the
floor
through
this,
so
obviously
you've
got
you
a
coop
cuddle
here
or
you
might
have
a
control
pipeline,
something
that's
using
the
API,
a
given
Eddie's
API,
that's
going
to
send
it
to
the
API
server.
The
API
server
is
then
going
to
go
off
to
all
perfective
lee
through
the
web
hooks,
and
we
talked
about
a
minute
ago.
B
It's
going
to
either
mutate
or
potentially
mutate
and
validate
that
that
resource
and
I
think
will
demonstrate
that
when
he
comes
demo
and
the
policy
data,
so
that
is
effectively
the
array
goal
that
stores
affecting
this
cube
management
site
on
here.
So
what
that
actually
has
in
there
it's
it's
basically
watching
that
policy
data
config
and
will
update
it,
so
it's
all
cash
than
there.
So
if
there's
any
kind
of
changes
it
will
update,
but
it
doesn't
go
out
every
time
you
get
an
or
progress,
then
to
check
to
reread
that
data.
B
V2
has
come
along
I
think,
a
year
or
two
ago
it's
moved
out
some
of
the
web
hooks
into
there's
policy
controller.
That's
added
some
extra
things
in
there,
so
it's
added
order
and
a
few
other
bits
and
pieces
in
there.
So
it's
also
kind
of
made
I
guess
a
little
bit
more
kubernetes
like
cabinet
separated
acts,
probably
and
slightly
a
better
model,
and
from
that
sense
and
I
think
that
came
actually
at
Microsoft
and
then
finally,
we've
got
now.
There
is
gatekeeper,
which
is
version
three.
So
this.
A
B
An
alpha
at
the
moment
and
so
I,
don't
think,
there's
anyone
really
using
it
in
any
anger,
but
there's
a
couple
of
key
changes
on
this
they've
kind
of
collapsed.
The
Okajima
kind
of
collapse
that
enter
into
one
thing
on
the
actual
OPA
server,
rather
than
having
the
three
different
things
they
had
previously
they've.
Also,
the
other
key
thing
that
they've
done
is
they've
added
custom
resources.
So
now,
when
you
do
your
regel,
you
can
have
that
templated
and
won't
because
your
template
of
it.
A
B
Can
get
reuse
of
it
so
if
you've
got
something,
for
instance,
like
a
label
check,
you
can
have
a
template
for
that
in
your
Rago
and
then
you
can
have
a
custom
resource
to
define
what
label
it's
chicken
so
that
kind
of
stops.
You
have
to
basically
cut
and
paste
your
way
go
through
multiple,
multiple
versions
and
multiple
different
slightly.
You
know
similar
use
cases,
but
with
maybe
slightly
different
syntax
and
it's
looking
for
so
that's
kind
of
the
three
different
versions
of
OPA
I'm,
going
to
just
quickly
talk.
B
If
you
want
to
get
it
installed,
it's
very
easy
to
get
up
and
running
out,
recommend,
probably
just
using
wanted
to
version
one
or
two
and
I
bet
keepers
say
kind
of
early
days.
At
the
moment
it's
gonna
be
pretty
easy.
If
you
install,
though
it's
just
set
up
a
namespace,
then
you
effectively,
you
need
to
create
a
certificate
for
the
internal
SSL
and
Union
point
deploy
the
admission
controllers
for
the
web
hooks
effectively
in
the
sidecars.
For
that,
and
that's
your
kind
of
pretty
much
done
right.
So
it's
just
that
effectively.
B
It's
very
well
documented
if
you
do
want
to
go,
there's
a
really
good
story
actually
on
open
policy
agent
org,
which
is
where
you
can
find
all
the
stuff
about
OPA
and
if
you
work
through
that
you'll
get
it
up
and
running
in
no
time
so.
I
think
with
that
I'm.
It's
gonna
now
go
through
and
he's
gonna
demo
Abrego.
A
Thanks
mark
that
was
a
good
introduction
to
the
evolving
architecture
of
OPA.
So
OPA
comes
with
policy.
Language
called
Lego,
where
you
can,
which
you
can
use
to
describe
your
policies.
Sorry,
other
your
policies
right,
so
I'll
walk
through
a
policy
return.
Griego.
What
this
policy
is
doing
is
it's,
restricting
all
image
pulls
from
Myron
sphere.
A
So
what
this
policy
is
doing
here
is
it
is
going
to
restrict
all
image
pulls
from
my
registry
at
I/o
to
understand
this
policy
written
in
Drago.
It
starts
with
a
deny
rule
which
says
that
all
these
requests
I
mean
the
first
validation.
Is
this
apart
being
deployed
right
to
understand
this
better?
You
need
to
look
at
this
admission
review
request,
which
comes
from
the
kubernetes
api
server
to
OPA
and
OPA
goes
through
this
admission
review
request
to
validate
the
policy
whether
whether
this
deployment
or
this
resource
can
be
created,
updated
or
deleted
right.
A
So
this
is
the
admission
review
request.
As
mark
explained,
this
is
architecture
v1
and
there
is
an
admission
controller
webhook
configure
on
kubernetes
api
server
for
it
to
fire
off
that
web
hook
to
OPA
right.
That's
how
the
admission
review
request
hits
OPA.
So
this
is
an
admission
review
request
and
this
is
kind
of
self-explanatory.
The
deny
rule
is
saying
that
if
it
first
checks
whether
it's
a
pod
being
created,
imagine
we
are
just
after
pods
here
then
it
checks.
It
basically
does
builds
an
iterator
over
all
the
images
here.
A
A
So
as
we
go
through
this
all
the
images
you
get
a
list
of
images
here
and,
as
I
said,
it
rates
over
it
and
checks
whether
both
the
images
are
coming
from
our
trusted
registry,
since
bad
registry
dot,
I
or
doesn't
match
it,
it
fails
it
and
the
deployment
doesn't
go
forward
right.
So
we
will
look
at
this
example
in
action
in
a
couple
of
minutes,
so
I
want
to
introduce
to
you
record
the
playground,
which
is
really
handy
if
you
want
to
try
out
your
policies.
So
let's
have
a
look.
B
A
It's
a
it's
the
same
policy
which
I
showed
you
before,
and
this
is
the
admission
review
request
here
and
you
can
evaluate
these
policies
and,
as
you
can
see
here,
the
result
is
that
the
bad
registry
dot
IO
is
not
allowed
to
be
pulled
from
this
registry.
So,
if
I,
if
I,
were
to
go
in
here
and
change
it
to
my
registry
and
run
the
evaluation
again,
you
can
see
that
it
passes
this
check.
A
So
this
is
really
handy
because
you
can
go
and
check.
Evaluate
parts
of
this
policy
was
just
saying,
evaluate
selection,
as
you
can
see
it's
a
pod
and,
and
it
returns
true,
you
can
also
see
what
gets
actually
created
in
this
section
here.
You
can
see,
as
I
said,
you'll
get
both
the
images
and
an
iterator
is
created
which
will
be
traded
over
in
the
next
statement.
So
that's
an
example
of
this
in
action.
This
is
a
really
handy
tool
which
I
thought
is
really
easy
to.
You
know
understand
the
policy
language
better
as
well.
A
Okay,
I
thought,
I'll
show
you
another
policy.
This
policy
is
is
not
going
to
allow
any
containers
which
do
not
have
the
CPU
limits
defined
to
be
deployed
into
a
production
namespace.
Alright,
let's
have
a
look
at
how
this
policy
would
look
in
drag.
Oh,
so
this
is
the
policy,
and
this
is
the
resource
limits.
The
first
container,
the
engine
X
container,
has
a
CPU
limit
and
the
second
one
the
radius
container,
doesn't
have
a
CPU
limit.
A
So
if
we
were
to
evaluate
this
policy,
it's
very
similar
to
the
previous
one,
but
it
includes
a
check
on
the
namespace
checks,
whether
the
namespaces
production
gets
all
the
containers
checks
whether
the
CPU
has
been
defined
for
each
of
those
containers
right.
So,
if
I
were
to
evaluate
this
one,
okay,
sorry,
you
can
see
the
content
of
radius
does
not
define
CPU
limits.
Hence
this
policy
will
be
denied,
I
mean
the
request
will
be
denied
and
the
part
wouldn't
be
created.
A
Hopefully
that
gives
you
an
understanding
of
how
to
write
policies
in
Drago
now
implementing
a
policy
using
Opa
Opa.
The
team
behind
opa
the
community
behind,
has
created
this
nice
unit
testing
framework
for
you
to
actually
test
this
policy
write
a
policy
in
a
tentative
and
fashion,
probably
used
it
in
agate,
tops
freshmen
as
well.
Have
a
CSE
D
pipeline.
Have
this
policies
unit
tested
before
you
can
actually
deploy
it
into
any
environment?
So
I'll
quickly
show
you
what
these
look
like.
A
A
A
Thanks,
so,
as
you
can
see,
I've
just
have
that
mock
request.
The
admission
review
request
I
have
shipped
out
all
those
fields
which
are
not
necessarily
for
this
test.
All
it's
doing
is
calling
calling
this
okay
first
I
will
show
you
how
this
test
is
run
so
that
you
understand
what
we
are
doing
here.
So
the
way
to
run
this
test
is
you
need
to
first
pass
in
your
policy
which
is
written
in
rego,
and
then
you
pass
in
the
test
case
for
that
policy.
A
So,
as
you
can
see,
you
can
run
it
in
verbose
mode
and
see
that
it
has
passed
right.
This
is
a
really
nice
way
of
iterating
over
your
policy
and
then,
finally,
you
know
committing
it
into
your
repository
rather
than
trying
to
troubleshoot
it
in
an
environment
right.
So
once
this
is
done,
I'll
bring
up
the
test
case
quickly.
A
So
all
that
is
it's
doing.
Is
it's
asserting
here
that
the
expected
message
that
needs
to
come
back
from
when
the
policy
is
evaluated
is
going
to
be
bad
registry
or
IO
sidecar
for
container
sidecar
does
not
come
from
a
trusted.
Entrust
comes
from
comes
from
an
untrusted
registry
right,
that's
basically
what
the
last
statement
is
doing
with
input
as
unsafe
image
requests.
That's
basically,
this
marked
out
request
here,
and
it's
very
well
documented,
as
well
on
the
up
our
website.
A
We
just
had
our
Christmas
party
yesterday
night,
so
please
don't
be
disappointed
if
the
demo
doesn't
work
and
if
I
type
something
wrong.
I
can't
remember
anything.
So
that's
created
the
policy.
The
next
step
is
to
check
whether
the
policy
has
been
deployed
correctly.
So
what
happens
now
is.
As
Mark
mentioned,
the
config
map
has
been
created
in
the
open
and
namespace
and
OPA
is
constantly.
A
You
know
watching
for
config
Mac
being
created
in
the
namespace.
It's
going
to
get
a
callback
and
then
it's
going
to
validate
that
policy.
So
the
way
you
can
figure
out
that
your
syntax
was
right
and
the
policy
was
all
good
is
you
can
describe
that
policy
which
has
been
just
created.
So
all
I'm
going
to
do
here
is
described
that
config
map,
which
we
just
created.
A
Yep,
so
you
can
see
here,
I,
never
I,
didn't
add
an
annotation
on
that
config
map.
What
OPA
has
you
know
ingested
this
policy
and
put
a
status
message
of
okay,
saying
that?
Okay,
the
policy
syntax
looks
good
everything's,
alright
with
this
policy,
and
it
will
start
evaluating
any
resource
updates
against
this
policy.
A
So
once
that's
done,
the
last
test
you
want
to
do
is
actually
deploy
a
resource
and
check
whether
the
policy
is
being
really
evaluated.
So
in
this
case,
what
we
are
going
to
try
out
now
is
create
a
pod
from
Bad
Rogers
referencing,
an
image
from
bad
registry
dot
IO
and
see
that
what
happens
when
you
try
to
do
that.
A
All
right
to
make
sense
of
this
I'm,
showing
you
the
policy
as
well,
so
a
developer
or
your
system
trying
to
deploy
this
pod
will
get
this
message
saying
image
not
from
your
trusted
registry,
a
bad
registry
at
I/o,
slash,
Engine
X,
so
that's
coming
from
here
right,
the
policy
has
been
evaluated
and
the
requester
has
been
denied.
So,
as
you
can
see
you
can
you
can
think
of
all
your
custom
policies
within
your
organization.
You
can
try
and
think
of.
How
can
you
do
this
in
drag?
A
Oh,
this
is
just
an
example,
but
you
know
it's
really
handy.
You
can
have
really
fine
grained
control
on
what
and
how
you
can
write
your
policies
right
all
right,
so
I
just
wanted
to
summarize.
Okay,
what
what
did?
What
did
I
actually
do
in
this
demo?
So
as
kubernetes
administrator
I
will
create
a
config
map
within
a
particular
namespace
now
mark
showed
this
architecture,
that's
version
1,
where
we
have
cube
management,
cube
management,
picks
up
this
config
map
and
evaluates
the
policy
and
adds
the
annotation
with
the
value
policy
status.
Ok
right
it
queue.
A
A
The
admission
review
response
is
sent
back
to
the
API
server,
and
the
developer
gets
this
sad
message
that
you
know
the
request
has
been
denied
and
it
also
gets
a
message
saying
that
image
from
not
from
your
trusted
registry
all
right
hope.
This
puts
everything
in
perspective
and
it's
clear
enough
for
everyone
to
see.
Finally,
I'd
like
to
talk
about
getting
context
in
policies
right,
sometimes
just
having
an
admission
review
request,
is
not
enough
to
make
a
decision
to
whether
to
allow
or
deny
this
request
coming
in.
A
For
example,
imagine
there
is
a
request
to
create
an
ingress
object
and
you
don't
want
to
ingresses
to
have
this
to
reference.
The
same
host
field,
so
what
is
happening
here
is
till
now.
The
examples
which
we
saw
were
using
just
the
admission
review
request
to
make
a
decision
on
whether
to
allow
or
deny.
But
what
this
is
doing
here
is
it's
referencing,
the
ingresses
in
all
namespaces.
Basically,
it's
getting
data
which
has
been
created
within
kubernetes
to
make
that
decision.
A
It's
iterating
over
all
the
ingresses
which
are
available
in
the
cluster
and
then
comparing
it
with
the
incoming
ingress,
request,
ingress
creatress
resource
and
making
a
decision
that
okay.
If
the
host
matches
any
previously
created
ingresses,
then
we
are
going
to
deny
this
request
right.
So
this
is
very
well
documented
in
those
in
that
URL
open
policy
agent.