►
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 - Rita Zhang, Microsoft & Max Smythe, Google
Come to this session to learn about the OPA Gatekeeper project! Gatekeeper integrates OPA with Kubernetes to provide new features like parameterized CRD-based policies, auditing, policy library, and more. Gatekeeper is being jointly developed by Microsoft, Google, and Styra (the creators of OPA). During the session Rita Zhang (Microsoft) and Max Smythe (Google) will explain what Gatekeeper is, how it works, how to get involved, and where the project is going.
https://sched.co/MPiM
A
A
B
Now,
if
you
operate
many
clusters
for
your
company,
you
probably
looking
for
ways
to
to
control
what
end-users
can
do
on
the
cluster
and
then
also
ways
to
enforce
policies
for
the
policies
in
your
company
and
you'll.
Probably
wonder
well
with
all
the
policies
that
my
companies
has
to
enforce.
Maybe
therefore,
you
know
regulatory
purpose,
or
maybe
you
just
have
some
best
practice
or
company
best
practice
that
you
want
to
enforce.
How
would
I
be
able
to
do
that
within
kubernetes,
but
still
give
users
the
flexibility
and
agility
they
love
in
kubernetes?
A
This
notion
of
policy
in
kubernetes-
it's
been
around
for
a
while
kubernetes
has
been
around
for
a
while,
and
so
it's
gone
through
a
bit
of
an
evolution
over
time.
You
could
see
here
just
overview
of
the
general
timeline.
There's
a
few
major
milestones.
We
call
them
v1,
v2,
v3
and
over
the
next
couple
minutes
we're
kind
of
sort
of
go
into
detail
of
how
things
have
progressed.
So
in
v1,
which
is
pretty
much
vanilla,
OPA
how
they
decided
to
integrate
with
kubernetes
was
they
created
a
site
process
called
cube.
A
Management's
and
cube
management
would
essentially
follow
the
API
server
and
replicates
data
into
OPA,
which
was
running
as
a
server
itself,
and
then
you
would
register
an
admission
web
hook.
That
would
query
open
directly
and
you
would
write
your
Rago
such
that
it
would
return
a
correct
response
either
admit
deny
whatever
your
use
case
may
be,
and
it
was
originally
written
by
styro
and
is
currently
used
by
dozens
of
companies
and.
B
Then
came
v2
and
at
the
time
it
was
called
kubernetes
policy
controller
Nikhil
when
he
was
at
Microsoft.
He
and
a
few
other
folks
worked
on
creating
creating
the
kubernetes
policy
controller,
which
basically
decoupled
the
admission
webhook
from
OPA,
and
with
this
he
also
added
a
mutating
authorization
and
audit
functionality
that
we
much
enjoy
today.
A
All
right
so
now
gatekeeper
is
what
we're
calling
v3
and
what's
different
about
gatekeeper.
Well,
it's
essentially
taking
this
whole
notion
of
policy
of
Rago
and
trying
to
bring
krm
to
it.
So
we
are
taking
what
you
would
be
writing
and
essentially
production
izing
it
and
commoditizing
it
into
little
snippets
of
what
we're
calling
constraints
which
you
can
declare
on
the
API
server
and
will
then
be
enforced
and
sort
of
how
that
works
we'll
get
into
a
little
later
in
the
presentation.
But
we
do
want
to
point
out
a
couple
of
thank-yous.
A
B
Piece
of
Ray
goes
yes,
so
we
mentioned
like
policies
that
companies
want
to
enforce,
and
here
are
just
four
that
we
took
as
examples
that
we
will
also
show
what
the
gatekeeper
v3.
So
here
are
some
common
policies
that
we
are.
We
we
see
that
companies
will
want
to
have.
One
is:
have
you
ever
had
a
question
of
their
this
resource?
I
wish
I,
can
contact
them
and
and
see
how
I
can
fix
that
issue
with
the
owner
of
this.
B
This
light
at
this
resource,
so
with
this
policy
that
the
admin
can
then
enforce,
ensure
that
all
namespaces
have
a
label
that
essentially
has
the
point
of
contact
so
that
they
can
talk
to
the
person.
If,
if
we
need
to
do
any
maintenance
and
then
next
have
you
ever
had
an
issue
where
you
have
pots
running
in
your
cluster,
but
they
don't
have
resource
limits.
I
bet,
some
of
you
have
run
into
that
issue,
and
so,
with
this
policy
you
can
ensure.
B
When
the
developer
deploys
the
their
pot,
you
can
make
sure
that
there's
resource
limits
so
one
it
doesn't
break
the
application,
but
two
it
also
doesn't
break
the
cluster
and
and
affect
their
neighbors.
The
third
policy
that
we
will
demonstrate
is
in
a
lot
of
users,
tend
to
pull
images
from
docker
and
just
basically
anywhere
right,
because
why
not
so
one
thing
that
companies
can
actually
enforce
is
I
only
want
my
users
to
pull
images
from
approved
repositories
or
images
that
have
been
scanned
or
whatever
right.
B
A
Let's
take
a
little
bit
of
a
step
back
here,
we
have
some
examples
of
common
policies
that
a
business
might
want
to
implement,
but
we
need
some
way
of
translating
that
into
a
declarative
form
right,
and
we
have
some
need
for
figuring
out
how
to
translate
that
into
kubernetes.
So
I
mean
kubernetes.
That
problem
is
some
it's
solved
right,
because
kubernetes
is
declarative.
The
act
of
restricting
kubernetes
is
our
usage
of
kubernetes
is
simply
restricting
valid
inputs
to
that
declarative
configuration.
A
You
basically
limit
what
you
can
declare
in
a
llamo
as
far
as
making
the
policy
itself
declarative.
What's
interesting,
there
is
that
all
of
these
sort
of
limits
that
you
may
want
to
place
on
a
llamo,
they
accumulate
I
want
this
field.
To
only
have
these
certain
values
I
want
that
field.
To
only
have
these
other
certain
values,
like
only
valid
image
repos,
only
certain
labels
can
be
applied
so
on
so
forth.
A
So
if
you
take
all
of
those
individual
units
of
intents
and
call
them
something
like
constraints
and
you
string
them
together,
you
and
them,
and
and
and
such
that,
if
any
constraint
is
violated,
the
whole
constraint
is
rejected
or
sorry
the
whole
request
is
rejected.
Then
you
have
a
platform
for
describing
and
implementing
policy
in
krm.
A
So
what
do
we
need
to
do
that?
We
need
declarative,
ended
constraints.
We
need
some
sort
of
schema
right,
because
we
have
different
styles
of
constraints:
either
were
constraining
different
objects,
different
resources,
different
fields
within
the
resource
and
in
different
ways.
Maybe
there's
a
numeric
range,
maybe
there's
some
string
matching
regex
so
on
and
so
forth.
So
you
need
different
kinds
of
constraints
that
achieve
these
different
results
and
you
need
some
way
of
configuring
them.
A
So
that's
you
know
you
can
only
constrain
resources
in
a
certain
namespace
and
if
it's
a
regex
constraint,
what
regex
am
I
matching
against?
You
probably
don't
want
to
be
diving
all
the
way
into
your
source
code,
just
to
make
a
simple
change
as
an
administrator
and
finally,
because
this
is
kubernetes
and
because
there
are
conventions
around
ownership
rights,
certain
objects
belong
in
certain
namespaces
and
you
have
label
selectors
names,
other
ways
of
sort
of
scoping
down
what
you're
interested
in
there's
common
selection
semantics.
A
So
it
would
be
nice
if
our
system
could
take
care
of
that
for
us
and
we
didn't
have
to
re-implement
the
wheel
every
time
we
had
a
new
constraint
so
how
that
looks
as
far
as
gatekeeper
is
we
develop
this
constraint
resource
and
the
there's
a
couple
of
things.
I
want
to
point
out
to
you.
The
first
is
the
kind
so
here
I'm
calling
it
Kate's
required
labels,
meaning
this
constraint
makes
sure
that
certain
labels
are
always
declared.
A
The
next
most
important
field
is
this
match
field
now
match
is
provided
by
the
system,
and
it
understands
a
few
selection
semantics
right
now.
Currently,
what
you're
seeing
is
I
am
matching
against
the
namespace
group
version
kind
and
other
options
might
be
only
objects
in
specific
namespaces
and
label
selector
and
finally,
in
the
red
box.
Here
we
have
the
admins
and
tent.
This
is
essentially
the
arguments
to
the
constraint,
if
you
think
of
them
as
functions
right
and
for
this
particular
constraint.
We
have
the
user
friendly
message.
A
Essentially,
if
you
do
not
have
a
owner
label,
we're
gonna
tell
you
hey,
you're,
creating
a
namespace,
all
namespaces
need
an
owner
label,
something
that
a
user
can
understand
and
follow,
and
hopefully
change
the
request
to
be
compliance.
And
then
we
have
the
actual
parameters
to
enforce.
In
this
case,
a
list
of
labels
there's
only
one
owner
and
the
regex.
We
expect
it
to
match.
B
And
as
we
look
at
many
forms
of
policies,
one
of
the
policies
that
you
could
potentially
have
is
comparing
information
about
what
you're,
creating
with
other
resources
that
are
already
in
the
cluster
right.
So
when
you
compare
uniqueness
of
service
or
uniqueness
of
ingress
controller
hostname,
that's
where
you
the.
When
you
execute
the
logic,
the
the
Rago
object,
the
the
actual
rule
inside
of
Opa
Opa
needs
have
needs
to
have
knowledge
of
the
data,
that's
already
in
the
cluster
and
that's
where
data
replication
comes
in,
so
for
those
type
of
policies
we
also.
B
You
can
also
replicate
the
data
that
that
is
required
to
ensure
that
this
type
of
policies
actually
work.
Yes,
and
we
just
talked
about
enforcing
policies.
So
the
next
feature
is
also
audit,
so
we
believe
that
is
really
really
important
to
give
admins
or
basically
people
that
really
care
about
compliance.
A
way
to
see
the
current
state
of
the
cluster.
An
audit
feature
really
provides
that.
B
The
objects
that
are
audit
needs
to
be
replicated
once
again
into
OPA
and
the
actual
results
of
the
actual
reorder
results
are
actually
exposed
in
the
status
field.
So,
as
you
can
see,
as
Max
mentioned
earlier,
this
is
an
example
of
a
constraint.
That's
already
exists
in
the
cluster
and
when
we
run
the
audit
every
periodically
every
you
know
a
few
minutes
or
seconds
depends
how
you
want
it.
A
So
so
far
so
good,
we
know
what
we
want
to
do.
We
know
how
we
want
to
enforce
things.
Is
you
know,
admission
webhooks
and
there's
audit,
but
we're
still
missing
some
key
pieces
here
right.
How
do
we
tell
this
the
source
of
things
we
want
to
enable
and
admin
to
do
right?
How
do
we
code
that
behavior?
How
do
we
inject
it
into
reg?
Oh,
the
Gator,
sorry
into
OPA
the
gatekeeper
system.
What
have
you
and
this
spoils
down
to
two
critical
components?
A
Right,
there's
the
input
schema
that
you're
expecting
the
admin
to
provide
that
parameters,
field
and
there's
the
actual
source
code.
That
does
the
checking
the
reg.
Oh
right,
so
there's
some
way
we
need
to
bundle
them
together,
and
so
what
we're
going
to
do
essentially
is
we're
going
to
come
up
with
a
concept
of
a
constraint,
template
and
we're
gonna
provide
exactly
those
two
things.
A
One
thing
that
we
don't
need
to
provide
thanks
to
how
everything
is
wired
together,
are
the
matching
semantics,
so,
as
kubernetes
evolves
as
new
ways
of
selecting
resources
come
into
being,
we
don't
need
to
go
back
and
update
or
validation.
We
just
get
that
extra
scope
for
free,
so
here's
what
a
constraint
template
looks
like
it's
a
lot,
but
essentially
at
the
top
in
the
spec.
You
have
a
skeleton
of
a
CR
D
and
the
biggest
two
things
you
have
are
the
names
for
the
CR
D.
A
That
then
become
the
name
of
the
constraint
resource
as
well
as
this
validation
field
and
the
validation
field
is
an
open,
API
v3
schema
and
it
gets
ported
directly
into
the
parameters
field
of
the
constraint.
So
you
can
control
what
admins
can
put
into
your
constraint
and
make
sure
that
it's
type
safe.
Now
at
the
bottom.
Here
we
have
the
targets
field
targets.
All
it
does
is
package
Rago
for
you
I.
You
can
see
here.
I
have
Kate's
required
labels
package
and
there's
a
deny
rule.
A
How
this
all
works
is
the
deny
role
is
the
entry
points
and
you
can
have
as
many
of
those
as
you
like
in
this
rule,
you
can
have
other
helper
functions,
other
helper
rules
to
do
your
evaluation,
but
gatekeeper
when
it
performs
a
request.
If
there
is
a
matching
constraints,
it's
going
to
check
the
deny
rule
for
the
constraint
templates
and
if
it
matches,
if
message
is
returned,
that
message
is
going
to
be
perpetuated
down
to
the
end
user
and
the
request
is
rejected.
B
So
this
is
actually
really
really
cool,
because
in
the
past
you
would
have
had
to
write
your
own
admission
webhooks,
but
also,
even
with
previous
version
of
gatekeeper,
you
would
have
had
to
write
your
own
Ray
goes
and
your
own
config
maps.
So
with
v3
now,
gate
keeper
provides
a
mission
system
that
allows
you
to
just
configure,
rather
than
writing
code,
but
also
to
write
policies
and
rules
as
constraints
and
the
constraints
can
also
be
parameters.
B
So
you
only
have
to
write
the
Ray,
go
the
template
ones
and
then
give
to
other
folks
to
actually
parameters,
and
this
is
really
scalable,
but
also
extendable
and
easy
to
share
easy
to
test,
and
you
can
actually
share
internally
or
with
all
your
friends
in
the
community,
but
last,
not
least,
it's
not
just
for
kubernetes.
You
can
also
integrate
this
with
you.
Our
CI
CD
pipeline.
A
Right
so
this
is
all
very
abstract:
I
thought
it'd
be
fun
to,
or
we
thought
it'd
be
fun
to
bring
it
into
a
little
bit
more
concrete
of
an
example.
We
have
organization
called
agile
bank
or
a
fictitious
organization,
and
they
have
a
few
issues
and
we're
gonna
see
how
gatekeeper
helps
solve
their
problems.
So,
in
the
beginning,
all.
B
A
Five
weeks
go
by
the
developer.
Moves
on
to
another
project.
Advanced
transaction
system
is
long
forgotten
until
our
intrepid
men
finds
it.
What
is
advanced
transaction
system?
Do
we
use
it?
They
go
on
a
3-day
quest
across
many
departments.
Only
to
find
the
project
with
scraps
never
again
says
the
admin
as
they
delete
the
namespace,
so
they
delete
the
namespace
they
search
for
a
solution.
They
find
gatekeeper,
install
it
in
their
cluster
and
they
look
around.
A
Just
in
case
so
I,
don't
point
say:
production
at
dev,
all
right,
so
I'm
going
to
load
those
into
the
system
by
running,
cube,
cuddle,
apply,
templates
and
then
I'm
going
to
write
out
some
constraints
for
each
of
these
templates.
I'm
just
gonna
quickly.
Look
at
one
of
them.
This
is
that
label
constraint
that
I
showed
you
before
all
the
rest
look
kind
of
similar,
there's
selectors
that
are
appropriate
and
there
are
parameters
so
I'm
just
going
to
apply
all
of
my
constraints,
get
them
enforced
and
hand
it
back
off
to
the
developer.
Now.
B
B
So
then
I
update
my
deployment
yamo
and
at
my
my
name
there
and
I
apply,
and
then
everything
works.
Next
I'm
gonna
deploy
some
pod
and
like
a
good
developer.
I
did
not
specify
any
resource
limits,
and
here
prior
to
this
I
would
I
would
have
had
no
idea,
and
then
it
would
take
days
maybe
even
longer,
to
get
that
fixed.
So
now,
I'm
gonna
apply
some
limits
and
of
course,
I
was
very
ambitious
and
add
too
much,
and
this
lovely
helpful
message
actually
tells
me
what
the
admin
would
like
to
do.
B
So
next
I
update
that
and-
and
it
looks
like,
like
many
developers-
I
used
my
own
image
and
when
I
should
have
used
a
production
one
and
let
me
go
ahead
and
update
that
and
WHAM
that
works.
Oh
sorry,
another
service
for
my
application,
so
I
can
actually
give
this
endpoint
to
the
front-end
developer
and,
as
you
can
see,
I
mistakenly
pointed
to
the
gatekeeper
system
namespace,
when
it's
only
for
tests
now.
Prior
to
this
I
would
have
had
I
would
probably
break
the
whole
thing
and
then
call
the
admin
to
help
me
fix
it.
B
B
A
Good
not
to
be
a
bottleneck,
all
right
so
halls
well
and
tell
the
big
outage
the
bank
is
down
for
hours
now.
I
had
no
idea.
There
were
resources
in
the
cluster
that
had
no
container
limits.
I
thought
I
took
care
of
that
with
my
policy
before,
but
that
was
why
right
something
got
hungry,
ate
up
all
my
clusters
resources.
So
we
need
to
fix
that
we
did,
but
what
else
is
lurking
waiting
to
attack
in
terms
of
resource
limits?
Oh
we
can
look
at
audit.
So
let
us
look
at
the
container
limits
constraints.
A
B
So
the
gatekeeper
project
is
currently
at
alpha,
but
our
plan
is
to
release
the
beta
version
of
it
at
end
of
June,
and
we
we're
here
to
talk
to
you
about
it
and
to
get
more
feedback
from
you
after
you
start
using
it.
We
will
love
for
more
contribution,
but
please
tell
us
your
use
cases
and,
as
you
use,
this
doesn't
make
sense
and
tell
us
the
user
experience.
So
we
would
definitely
love
to
hear
your
feedback
yeah.
A
We're
looking
for
beta
yeah
all
right
so,
and
we
have
all
of
what
we
have
here.
It's
currently
working,
but
where
are
we
looking
to
go
next?
One
of
the
big
use
cases
we're
looking
to
provide
is
mutation.
We
want
to
do
the
same
kind
of
thing:
we've
done
with
validation,
constraints
in
terms
of
packaging
them
up
making
them
reusable
declarative,
all
that
nice
stuff.
A
We
would
also
like
to
be
able
to
more
easily
incorporate
external
data
into
the
system,
so
think
about
validating
that
that
owner
constraint
against
the
actual
users
of
your
system
right,
actually
look
up
real
user
names.
Instead
of
relying
on
a
regex
authorization
is
possible,
it
would
likely
go
into
a
different
project
because
it
shouldn't
be
running
on
on
the
cluster
directly
and
it
will
have
slightly
different
takes,
but
the
same
general
idea
constraint,
template
constraints,
more
audit
features.
We
would
like
audits
right
now.
A
It's
very
useful
as
a
debugging
tool,
very
useful
for
keeping
an
eye
on
sort
of
what's
happening
in
the
cluster
right.
Now.
It's
not
writing
out
to
say,
signed
logs.
It's
not
writing
out
very
granular
lis
such
that
you
can
view
a
historical
state,
a
historical
timeline
of
what
has
been
in
and
out
of
compliance
in
your
cluster
overtime,
metrics
metrics
metrics
for
Prometheus.
So
you
can
instrument
and
alerts
against
the
project
view
things
like
up.
There's
a
lot
of
rejections
happening.
A
What's
that
about
or
just
this
thing
is
behaving
in
a
weird
way,
developer,
tooling,
to
help
people
right
constraints,
we
want
to
make
it
easy
for
people
to
build
things
and
shares,
so
the
system
can
continue
to
evolve
as
Cooper
nutty
to
Burnett
evolves
and
finally,
dry
run.
So
that's
when
you're
developing
new
constraints
are
testing
them
out
on
your
system.
A
We
really
appreciate
it
and
please
join
us.
We
would
love
to
have
you
here
is
our
github
repo.
We
are
on
slack.
So
please
join
our
channel.
Ask
us
questions
and
you
know
if
you
want
to
help
participate.
We
have
a
meeting
every
to
pee
every
Tuesday
at
2:00
p.m.
Pacific
time,
where
we're
open
to
changing
that.
I
realize
that
something
like
10:00
p.m.
in
the
current
time
zone,
so
11:00,
maybe
even
and
sometime
so
yeah.
Definitely
we
can
make
that
earlier.
B
A
A
B
Also,
one
of
the
configure
one
of
the
knobs
that
you
can
tweak
is
list
how
many
violations
per
constrain
so
with
that.
It
will
basically
only
give
you
like
the
the
ones
that
the
the
number
the
the
limit
that
you've
set
right
so
like
top
20
or
top
10,
whatever
so
eight
in
theory,
it
shouldn't
give
you
a
really
really
long
list.
B
B
A
So
you
want
to
in
have
the
templates
outside
of
kubernetes
but
enforce
them
in
kubernetes
interesting,
so
that
we
definitely
thought
about
for
for,
like
a
CI
CD
pipeline
reading,
the
templates
in
not
from
the
API
server,
so
you
could
validate
the
state
of
your
cluster
with
that
I
think
it
could
be
possible.
It's
not
currently
something
we're
supporting,
but
you'd
need
to
make
it
available
via
web
hood.
Nothing.
A
A
So
it's
a
lifecycle,
question
of
what
happens
in
constraint:
templates,
if
you,
if
you
so
there's
constraint,
templates,
create
constraints,
er
DS,
which
then
people
can
create
constraint,
custom
resources,
what
happens
if
a
constraint
changes
and
then
a
pre-existing
constraint
say,
has
an
invalid
schema
after
the
fact
so
functionally?
What
happens
right
now
in
kubernetes
is
the
constraint
continues
to
exist
in
its
previous
form
and
effectively?
What
is
going
to
happen
for
evaluation
at
that
point?
Is
that
likely
that
constraint
will
no
longer
match
like
it
will
get?
A
The
rule
will
set
an
undefined
state
in
reg,
oh
so
so
that
violation
will
kind
of
go
away.
So
the
kind
of
convention
that
we're
suggesting
around
that
is
you,
conversion
constraint,
templates
within
the
name
of
the
template
and
go
V
1
V
2
and
keep
the
same
kind
of
kubernetes
version
implications
so
that
that
that
exists
for
like
alpha
beta
so
on,
where
you
make
sure
that
you
keep
your
interface
consistent
if
you're,
just
up
doing
like
transparent
upgrades
of
the
Rago.
A
Yes,
yes,
so
this
is
part
of
the
matching
semantics,
so
the
question
was
I.
Can
you
have
different
rules
for
different
namespaces
for
constraints
and
one
of
the
things
you
could
do
with
constraints
is
you
could
have
namespace
name
as
the
matcher
so
that
only
resources
within
a
given
namespace
will
be
matched
against
that
constraint?
It's
potential.
We
don't
have
it
right
now,
but
essentially
a
namespace
selector.
So
a
label
selector
that
selects
against
namespace
labels
would
be
a
more
general
way
of
doing
it.
B
A
A
A
A
Think
it's
I
think
it's
yes,
so
the
the
select
is
so
the
selector
is
on
the
sorry,
I'm
blanking
on
so
its
deployment
and
service
right,
the
selectors
on
the
service.
So
if
you're
cashing
services,
you
can
then
run
the
selector
logic
against
all
cache
services,
or
so
you
could
take
all
cache
services
get
their
selectors
run
the
selectors
logic
against
the
currently
proposed
deployment,
and
if
it
doesn't
match
any
existing
ingress
or
sorry
service,
then
it's
dental
fail
right,
right,
right
right.
So.
A
I
would
like
it
I
would
like
to
get
it
to
that
state.
The
question,
then,
would
be
the
are
back
permissions
around
that
right.
So
if
you
are
in
a
state
where
you
can
find
a
trusted
group
across
all
those
departments
that
that
you
feel
are
should
be
allowed
to
hit
all
policy
everywhere,
then
it
would
be
fine
for
now
really.
The
the
next
step
would
be
to
create
a
set
of
resources
that,
for
instance,
limit
the
set
of
labels.