►
Description
Enforcing Bespoke Policies in Kubernetes [I] - Torin Sandall, Styra
Kubernetes enables fully-automated, self-service management of large-scale, heterogenous deployments. These deployments are often managed by distributed engineering teams that have unique requirements for how the platform treats their workloads, but at the same time, they must conform to organization-wide constraints around cost, security, and performance. As Kubernetes matures, extensibility has become a critical feature that organizations can leverage to enforce their organization’s bespoke policies.
In this talk, Torin explains how to use extensibility features in Kubernetes (e.g., External Admission Control) to enforce custom policies over workloads. The talk shows how to build custom admission controllers using Initializers and Webhooks, and shows how the same features lay the groundwork for policy-based control through integration with third party policy engines like the Open Policy Agent project.
About Torin Sandall
Torin Sandall is the technical lead of the recent open source Open Policy Agent (OPA) project. He has spent 10 years as a software engineer working on large-scale distributed systems projects. Prior to working on the Open Policy Agent project, Torin was a senior software engineer at Cyan Inc. (acquired by Ciena Corp.) where he designed and developed core components of their SDN/NFV platform such as modelling languages as well services for resource orchestration and topology discovery. Torin has recently given talks on policy-related topics in Kubernetes at ContainerDaysPDX and LinuxCon Beijing as well as the Kubernetes Community Meeting and the Kubernetes SF meetup.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Okay,
so
my
name's
turin,
I
work
for
a
start-up
called
steerer
and
I'm
also
the
tech
lead
on
a
project
called
the
open
policy
agent
and
today,
I'm
gonna
be
talking
about
how
you
can
enforce
bespoke
policies
and
kubernetes,
and
so
the
focus
of
this
talk
is
gonna,
be
on
how
you
can
take
admission
controllers
in
kubernetes
and
use
them
to
enforce
all
kinds
of
custom
policies
in
their
organization
specific
in
the
matter
to
your
your
companies.
So
this
isn't
overview
of
what
I'm
going
to
talk
about.
A
First
I'm
gonna
get
a
little
bit
of
background
on
how
we
think
of
policy.
Then
I'm
gonna
introduce
like
an
example
scenario
where
you'd,
why
not
enforce
some
some
custom
policy
and
then
I'm
gonna
show
how
you
can
do
that
with
admission
control
and
then
I'm
going
to
introduce
the
open
policy
agent
project
at
the
end.
A
So
when
we're
talking
about
policy,
you
know
we're
talking
about
sets
of
rules
that
govern
how
the
system
should
behave.
So
these
could
be
authorization,
rules
or
admission
control
rules
or
network
policies
and
so
on,
and
the
interesting
thing
about
policies
is
that,
while
they
apply
to
every
single
organization,
pretty
much
on
the
planet,
they're
also
vital
to
their
long-term
success,
because
they
codify
important
requirements
around
things
like
cost
and
performance
and
security
and
internal
convention,
and
so
on.
A
Now
when
it
comes
to
actually
enforcing
policy,
the
the
approaches
that
are
out
there
kind
of
are
all
over
the
place.
So
you
find
a
lot
of
companies
that
just
rely
on
tribal
knowledge
and
wiki's
and
Docs
and
spreadsheets
to
actually
enforce
policy.
So
they
write
it
down
on
a
wiki
and
they
hope
it
gets
it
enforced.
A
Or
you
know,
when
you
have
a
policy
question,
you
have
to
go
and
ask
somebody
on
another
team
and
they
know
how
to
like,
set
the
configuration
just
right
to
secure
the
system
at
the
other
end
of
the
spectrum.
A
lot
of
companies
start
by
like
hard
coding
policies,
decisions
into
software
and
while
that
works
initially,
the
the
cost
of
that
overtime
goes
up
quite
a
bit.
A
Because
not
only
are
the
policies
harder
to
understand
because
they're
so
tightly,
coupled
with
the
rest
of
the
business
logic
in
the
system,
but
they're
also
very
expensive
to
change,
because
you
need
to
do
like
an
entire
software
release
in
order
to
get
it
changes
out
and-
and
so
this
isn't
necessarily
a
new
space.
There
are
lots
of
policy
solutions
out
there,
but
when
you
dig
into
them
a
lot
of
the
time,
what
you
find
is
that
they
don't
have
the
core
kind
of
expressiveness
that
you
need
to
say
what
you
want
and
you
policies.
A
So
you
can't
express
that
you
can
write
the
logic
that
you
want.
You
don't
have
access
to
the
data
or
the
context
that
you
need
to
make
policy
decisions.
You
can't
even
necessarily
generate
the
kinds
of
policy
decisions
that
matter
right.
So
a
lot
of
the
time
you
need
to
express
more
than
just
like.
Is
this
thing
allowed
or
denied?
A
You
want
to
say
what
fields
are
allowed
to
be
displayed,
or
you
know
what
are
the
one
of
the
annotations
that
have
to
be
enforced
or
applied
to
objects
when
they're
created
and
then,
moreover,
a
lot
of
the
time
the
languages
that
they
give?
You
are
not
particularly
sophisticated,
and
so
you
can't
take
policies
and
split
them
up
and
create
reusable
functions
and
rules,
and
so
on
that
you
can
share
it's
really
your
throughout
your
policy
codebase.
A
A
Kashchei
cannot
get
shell
access
to
containers
that
are,
you
know
privileged
security
context
in
a
certain
namespace
that
happens
to
be
running
all
their
production
workloads
right.
So
the
question
is
like
what
can
Alice
actually
do
to
enforce
this
policy
today
and
so
over
time?
Kubernetes
has
has
developed
a
bunch
of
features
as
this
matured
around
extensibility
and
so
they've
added
lots
of
web
hooks
for
things
like
authorization
and
authentication
and
image
policies
and
scheduling,
and
all
these
different
things.
A
But
then
in
1.7
they
added
a
great
feature
called
the
dynamic
admission
control
and
that's
what
we're
gonna
focus
on
here,
and
so
what
that
does
is
it
allows
you
to
decouple
policy
decisions
and
policy
enforcement
from
from
kubernetes
itself
going
forward.
There's
there's
a
bunch
of
other
great
features
that
are
coming
like
you're
going
to
have
mutating
web
hooks.
These
features
are
going
to
bethe
and
so
that
that's
that's
really
exciting.
So
for
people
that
don't
know
about
admission
control
already
it's
this
it's
this
stage
that
runs
whenever
requests
received
by
the
API
server.
A
So
after
a
request
is
authenticated.
So
whenever,
for
example,
Bob
runs
coop
CTL
exec
that
request
that
sends
a
request
to
the
API
server
and
that
request
has
to
be
authenticated
and
it
has
to
be
authorized
using
like
role
based
access
control
and
then
it
has
to
pass
through
a
series
of
admission
controllers
that
decide
what
to
do
with
it
and
so
before
any
request
affects
SC,
D
or
any
clients
get
notified
about
a
state
change
in
the
system.
A
These
admission
controllers
run
and
the
goal
of
these
admission
controllers
is
to
enforce
various
kinds
of
policies
around
resource
management
and
security
and
defaulting
and
semantic
validation
and
so
on,
and
so
each
each
resource
are
started.
Each
admission
controller
gets
a
chance
to
either
just
allow
the
request
or
the
change,
modify
the
change
and
pass
it
on
or
deny
it,
and
so
the
difference
between
authorization
and
admission
control.
What
an
important
difference
is
that
in
in
the
authorization
or
authorizer
framework,
if
a
single
authorizer
allows
the
request,
then
it'll
be
allowed.
A
A
Moreover,
in
order
to
configure
these
things
because
they're
not
always
just
like
static
logic,
you
need
to
provide
configuration
to
them
for
certain
things
you
had
to
do
that
by
reconfiguring
kubernetes,
you
had
to
go
and
change
the
command
line.
Arguments
that
you
use
to
start
the
API
server
with,
and
then
you
have
to
like,
provide
static.
A
The
good
news
is
that
in
1.7,
now
we
have
these
external
admission
web
hooks
that
you
can
use
to
running
admission
controllers
on
top
of
kubernetes
itself,
and
so
the
web
hooks
act
just
like
regular
admission
controllers.
They
get
a
chance
to
allow
or
deny
incoming
write
requests
before.
Edd
is
updated,
and
before
you
know,
any
clients
are
notified
and
so
you're
able
to
externalize
or
decouple
policy
enforcement
from
the
core
of
kubernetes.
A
Now
the
really
nice
thing
or
one
really
nice
thing
about
these
web
hooks-
is
that
you
can
actually
configure
them
dynamically
through
the
kubernetes
api.
So
you
can
you
can
you
can
deploy
your
web
hook
and
then
have
the
configuration
change
as
the
requirements
for
the
web
hook
change
now
the
way
that
you
actually
configure
them
you
base.
A
A
So
if
you're
working
with
author
authorization
or
authorizers,
you
don't
get
this
this
full
representation
of
the
object,
you
only
get
the
name
of
the
object,
the
type
of
the
object
and
so
on
now.
So
in
this
case,
though,
Alice
has
all
the
information
she
needs
in
order
to
actually
implement
this
policy
to
protect
the
system
against
Bob,
and
so
she
would
write
a
web
hook.
A
Basically,
she
could
write
a
web
hook
now
that
makes
a
decision
about
whether
or
not
to
allow
these
connect
requests
and,
and
then
that
decision
would
result
in
a
response
being
sent
back
from
the
web
hook
to
the
API
server.
That
says
that
you
know
this
request
should
be
denied
and
then
she
can
include
a
message
that
tells
Bob.
Why
he's
being?
Why
he's
being
denied
when
he
runs
coop,
cuddle,
exec?
A
And
so
the
test
says
it's
important
to
know
that
if
any
of
the
web
hooks
return
a
denial,
then
the
request
gets
rejected
right.
So
it's
not
doesn't
behave
like
an
authorizer,
okay,
so
I
figured.
We
would
actually
look
at
how
you
would
go
about
implementing
one
of
these
web
hooks.
So
I
was
said,
I
was
doing
a
dry
run
of
this
demo
right
before
the
talk
and
then
my
laptop
crashed,
and
so
hopefully
this
goes
well.
A
Okay,
so
the
first
thing
you
need
to
do
is
create
a
service
that
the
API
server
can
use
to
look
up.
Your
web
hook
that's
running
on
top
of
kubernetes,
so
we're
gonna
go
ahead
and
create
that
and
then
we're
gonna
basically
create
a
deployment
that
runs
our
web
hook,
and
so
this
is
pretty
standard.
It
just
identifies
the
the
container
image,
that's
run,
it
that's
got
the
web
hook
and
then
it
also
has
to
specify
the
the
TLS
certificates
that
the
API
server
will
use
to
authenticate
the
the
remote
the
endpoint.
A
So
we're
gonna
go
ahead
and
ploy
the
admission
controller
now
on
top
of
kubernetes,
and
then
we
can
see
that
it's
brought
up
immediately,
so
that's
great,
and
then
we
can
see
that
the
web
hook.
It
has
actually
registered
itself
as
an
external
admission
controller
in
the
API
server.
So
this
is
that
configuration
that
controls
whether
or
not
the
web
hook
gets
called.
So
you
can
ignore
this
big
certificate
bundle
at
the
top.
A
A
Okay,
so
let's
take
a
look
at
how
this
is
actually
implemented,
so
this
is
the
go
code
that
actually
implements
a
web
hook.
So
you
first,
you
have
just
a
main
function
where
you
you
do
the
standard
boilerplate
of
loading,
the
kubernetes
config,
to
talk
to
the
API
server,
and
then
you
just
start
a
web
server
that
serves
the
web
hook
endpoint
during
startup.
You
need
to
register
the
web
hook
somehow,
so
you
can
either
do
this
in
code
or
you
can
do
this
with
configuration
I've
chosen
to
do
with
code
just
cuz.
A
A
So
that's
about
150
lines
ago
or
so.
Okay!
So
now
now
we're
gonna
test
this
policy
out,
so
we're
gonna
create
a
privilege
container.
That's
just
gonna
run
an
Alpine
image
and
what
we'll
do
is
we'll
first,
create
it
in
the
default
namespace
and
then
we'll
create
another
one
in
the
in
the
production.
Namespace,
alright,
and
so
then,
if
we
try
to
SSR
exec
into
the
default
namespace,
it
works
as
we'd
expect,
but
hopefully
this
works.
This
is
what
broke
right
before
the
talk.
A
A
Okay,
all
right!
So
if
you
start
implementing
these
web
hooks,
there's
a
few
things.
You
probably
want
to
keep
in
mind.
So
the
number
one
thing
is
that
you
really
need
to
be
careful
with
the
dependencies
that
you
introduce
in
the
web
hooks,
because
every
single
call
coming
into
the
API
server
is
gonna,
be
subject
to
whatever
latency
or
availability
consider
constraints
you
put
on
the
on
the
on
the
web
hook,
and
so
you
really
want
to
be
careful
about
that.
A
The
other
thing
you
want
to
pay
attention
to
is
that
you
don't
want
to
be
performing
side
effects
if
possible
at
all
costs
inside
of
these
admission
controllers,
because
just
because,
if
your
admission
controller
decides
to
allow
the
request,
it
doesn't
necessarily
mean
that
an
admission
girl
or
later
in
the
chain
is
going
to
allow
it,
and
so
you
don't
necessarily
know
whether
or
not
the
quests
are
being
allowed
or
denied.
So
you
want
to
you
want
to
be
careful
about
that.
A
The
second
thing,
sort
of
big
thing
that
you
want
to
pay
attention
to
or
be
aware
of,
is
that
right
now
the
API
server
sends
the
internal
representation
of
kubernetes
objects
over
the
wire,
and
so
this
means
that
it's
a
little
bit
trickier
to
get
the
objects
to
deserialize.
If
you're
using
the
client
go
framework
and-
and
they
just
won't,
look
exactly
like
the
objects
that
you
see
when
you,
when
you
do
API
requests
against
kubernetes.
So
you
all
the
date
same
data.
A
Is
there
it's
just
that
the
format
of
the
data
is
slightly
different,
a
sort
of
thing,
that's
sort
of
better
or
getting
better.
Is
that
right
now
the
API
server
fails
open
if
the
web
hook
call
fails
right.
So
if
there's
a
network
partition
or
whatever
and
and
the
web
or
the
web
book
crashes,
or
something
like
that,
then
that
failures
going
to
that
errors,
gonna
go
back
to
the
API
server
and
the
APS
are
just
going
to
allow
the
request.
A
Another
thing
to
watch
out
for
is
that
you
need
to
actually
serve,
or
today
you
need
to
serve
the
webhook
endpoint
from
the
from
the
root
path.
So
you
can't
like
embed
this
in
another
in
another
API
in
another
web
server.
You
need
to
have
your
own,
you
need
to
own
the
IP
port,
but
that's
also
becoming
configurable
in
1.9.
So
that's
getting
better.
These
things
are
improving.
The
last
thing
I'll
point
out
is
that
actually
I
think
there's
been
a
couple.
A
A
Yeah,
so
the
question
is
whether
or
not
you
need
to
use
the
kubernetes
code
in
order
to
make
these
admission
control
decisions,
and
you
don't
like
you-
can
just
receive
these
webhook
calls
as
JSON
and
then
do
whatever
you
need
to
do
with
them.
But
this
but
yeah
you're,
getting
you're,
not
getting
the
the
versioned
API
objects
over
the
wire
okay
yeah,
so
that
I
just
want
to
point
out
that
the
client
go.
Experiences
has
gotten
a
lot
better.
I
had
a
lot
of
trouble,
getting
it
to
work
a
few
months
ago.
A
The
last
time
I
did
this
last
week.
It
was
like
super
smooth.
So
that's
that's
excellent!
Okay,
so
you
know
these
web
hooks
and
other
features
that
are
part
of
dynamic
admission.
Control
like
initializers,
have
sort
of
laid
the
groundwork
for
extensible
policy
enforcement,
which
is
which
is
great
because
you
don't
want
to
have
to
go
and
modify
kubernetes
itself
whenever
you
want
to
enforce
some
new
policy
inside
of
your
organization.
The
reason
for
that
is
that
these
policy
decisions
have
been
decoupled
from
the
enforcement
point
right.
So
you
take
the
you.
A
A
No,
they
don't
so
they're
they're,
just
it's
just
a
it's
just
an
API
that
you
have
to
implement
inside
of
your
process.
The
question
is
whether
or
not
you
need
to
implement
these
and
go
and
the
answer
is
you
don't?
But
that's
a
great
question,
because
you
know
I
I
think
that
we
can
probably
actually
do
a
little
bit
better
than
this
right
in
the
same
way
that
when
you
like
configure
a
firewall
or
something
like
you,
don't
write
a
bunch
of
C
code
to
do
that.
A
Maybe
we
don't
want
to
write
a
bunch
of
go
code
every
single
time,
there's
this
new
policy
that
we
want.
So
what
I
think
we
really
want,
and
what
everybody
should
want
is
a
declarative
way
of
specifying
these,
these
kinds
of
access
controls
in
their
in
their
clusters,
but
obviously
that
this
hasn't
really
been
done
so
far
and
there's
a
few
reasons
for
that.
But
one
of
the
reasons
is
because
this
is
the
type
of
thing
you
have
to
write
policy
over
right.
It's
this
deeply.
A
Nested
data
strike
these
deeply
nested
data
structures
that
have
all
this
embedding
and
these
collections
and
and
they
have
these
domain
models
that
are
incredibly
complex,
sophisticated
and
complex.
So,
for
example,
you
know
a
pod
has
like
35
attributes
or
something
like
that
that
are
deeply
nested,
and
then
the
metadata
adds
another
10
attributes
right,
and
so,
if
you
try
to
imagine
how
you
would
apply
like
a
firewall
rule
to
this,
it
doesn't
definitely
make
sense
when
you
work
with
firewall
rules,
you're
thinking
about
like
five
or
seven
tuples.
A
You
know
this
is
like
a
500
tuple,
or
something
like
that.
So
it's
really
it's
really
kind
of
tricky
to
think
about
how
you
would
do
this
declaratively,
but
this
is
where
what
I'm
interested
in
and
what
a
lot
of
people
are
interested
in,
and
so,
if
you
had
it
as
a
solution
for
this,
that
was
declarative.
This
is
what
it
could
look
like,
for
example,
so,
first
of
all,
you're
gonna
need
some
way
to
reference.
A
These
deeply
nested
data
structures
that
are
inside
of
the
JSON
right,
so
you
want
some
way
to
dot
into
that
JSON
and
refer
to
deeply
nested
values.
The
next
thing
you're
gonna
probably
want,
is
some
sort
of
variable
some
way
to
have
intermediate
variables.
So
you
don't
have
to
like
repeat
these
deeply
nested
paths
all
over
the
place
and
then
you're
also
going
to
need
some
way
to
iterate
right
you're,
gonna
need
somewhere
to
walk
over.
A
You're
not
gonna,
have
to
repeat
that
all
over
the
place,
and
so
you
just
need
some
way
to
wrap
that
up
and
share
it
and
reuse
it,
and
then
you.
Finally,
you
need
some
way
to
kind
of
take.
All
of
that,
together
and
and
build
policies
out
of
it,
and
so,
for
example,
we
could
say
that,
given
the
incoming
review,
you
know
if
the
user
is
Bob
and
the
operation
is
connect
and
the
namespace
is
production
and
they
can
there's
a
container
in
that
pod.
That's
privileged
and
deny
it
right.
A
A
So
if
the
core
of
OPA
is
this
high-level
declarative
language
that
we
call
Rago
and
what
Rago
gives
you
is
the
ability
to
write
policies
to
codify
policy?
To
answer
questions
like?
Is
this
user
allowed
to
perform
this
operation
on
this
resource?
Or
you
know
what
cluster
should
this
workload
be
deployed,
do
or
what
clusters?
Rather,
should
this
workload
be
deployed
to
or
what
annotations
need
to
be
set
on
the
objects
when
they're
created,
and
so
the
neat
thing
about
Rago?
A
Is
that
you're
not
limited
to
just
boolean
policy
decisions
like
yes
or
no
allowed
and
I?
You
can
actually
express
decisions
that
are
like
collections
of
values,
they're,
actually,
just
arbitrary
JSON
data,
open
itself
is
written
in
go
and
you
can
take
it.
You
can
use
it
as
a
library
or
a
daemon,
and
so
the
idea
is
that
it's
meant
to
be
as
lightweight
as
possible.
So
it
stores
all
the
policies
and
data
in
memory
that
it
uses
to
do
policy
evaluation,
and
then
it
doesn't
introduce
any
kind
of
runtime
dependencies.
A
So
there's
no
external
database
that
it
has
to
connect
to
or
any
external
service
that
it
has
to
reach
out
to
when
it
when
you've
got
it
deployed.
So
it's
very
easy
to
deploy
when
you're
using
it
on
top
of
kubernetes.
You
can
actually
just
load
all
your
policies
and
it's
config
maps
and
I'll
show
that
in
a
minute,
in
addition
to
the
sort
of
core
evaluation
engine
that
gives
you
the
the
policy
parser
and
compiler
and
interpreter,
we
also
provide
a
bunch
of
tooling
around
to
help
you
build
test
and
debug
your
policies.
A
So,
for
example,
there's
an
interactive
shell
that
you
can
use
to
develop
and
experiment
with
policies
and
write,
queries,
there's
a
test
framework
and
a
test
runner
that
you
can
use.
So
you
can
actually
unit
test
your
policies
and
verify
that
they're
doing
what
you
think
they
should
be
doing
and
then
there's
a
bunch
of
debugging
functionality.
So
you
can
trace
the
evaluation
of
policy
and
understand
like
why
it's
returning
a
denial
for
this
particular
user
or
this
particular
pod,
or
this
particular
deployment.
A
And
then,
lastly,
you
know
we
have
a
growing
community
of
people
that
are
using
it,
so
the
project
itself
is
sponsored
by
steerer
the
company
that
I
work
for
as
well
as
Google
firebase.
We
have
a
bunch
of
users.
We
talked
on
Wednesday
with
Netflix
about
how
they're,
using
it
to
do
authorization
across
stock
in
HTTP,
API,
Zanjeer,
RPC
and
ssh
and
Kafka.
A
We've
also
got
other
users
they're
using
it
for
kubernetes
and
terraform
and
more
and
then
we've
got
a
bunch
of
integrations
that
you
can
use
across
projects
like
sto
and
kubernetes
and
terraform
and
Pam
and
AWS,
and
so
on.
So
you
don't
have
to
actually
start
from
scratch.
If
you
want
to
use
open
to
enforce
policies,
you
can
use
some
of
these
integrations
out-of-the-box
to
enforce
all
kinds
of
custom
policies
inside
of
your
organization's.
A
Okay.
So
let's,
let's
have
a
look
at
how
this
actually
works.
Okay,
this
is
the
part.
I
really
want
to
go.
What
go
go?
Well,
ok,
so
first
I'm
gonna
create
a
namespace
to
deploy
open
into
and
then
I'm
gonna
create
a
similar
service
like
we
did
before.
For
the.
For
the
other
admission
controller
and
then
I'm
gonna
create
a
deployment
for
open
itself
and
I'm
gonna
wait
for
open
to
start
up,
and
so
it's
there.
A
It's
already
running,
that's
great,
and
so
the
next
thing
I
can
do
is
check
to
see
if
opens
registered,
and
so
you
can
see
here
that
it's
registered
and
it's
actually
saying
give
me
all
requests
across
all
API
groups,
versions,
operations
and
resources,
and
you
can
see
that,
like
the
failure
policy
is
actually
ignore.
So
this
is
what's
changing
in
1.9,
so
this
will
be
configurable,
so
you
can
say,
don't
ignore
failures
if
the
endpoint
crashes
or
something
in
a
bad
treat
that
is
as
a
denial,
which
is
what
you
want.
A
You
want
to
fall
back
to
to
deny
in
this
case,
ok.
So
what
I'm
gonna
do
is
go
ahead
and
create
that
that
pod,
again,
that
privilege
pod
in
both
namespaces
and
then
I'm
going
to
load
in
a
policy
now
as
a
config
map
to
OPA.
So
the
policies
that
can
all
be
stored
in
kubernetes
is
config
Maps.
You
don't
have
to
duplicate,
you,
don't
have
to
add
it
another
storage
layer
or
something
for
OPA.
A
It
can
all
just
integrate
with
kubernetes
very
nicely
and
then,
when
you,
when
you
load
the
config
Maps
in
you,
can
see
that
OPA
has
actually
annotated
them
with
a
with
a
status
of
that
policy.
And
so
in
this
case
the
status
is
ok,
which
means
the
policy
has
been
installed
into
OPA
and
it's
being
enforced.
So
you
can
actually
tell
whether
or
not
there's
been
an
error
in
the
policy
or
something
like
that.
A
So
you
know
that
it's
actually
working,
ok
and
so
I'm
gonna
try
to
executive
the
alpine
container,
that's
in
the
default
namespace,
and
that's
that's
working,
fine
and
now
fingers
crossed
if
we
try
to
exact
into
the
alpine
container
in
the
production
namespace
that
gets
rejected.
Okay.
So
that's
the
same
behavior
we
saw
before,
but
the
implementation
is
a
little
bit
different
this
time.
A
So
this
is
an
example
of
a
policy
that
we've
written
that
implements
this
this,
this
sort
of
access,
control
in
kubernetes
and
so
at
the
bottom,
there's
a
bit
of
boilerplate,
but
at
the
top
is
sort
of
the
business
logic
of
the
policy.
So
what
we've
done
is
we've
defined
a
rule
that
generates
an
error
message
that
says
you
know
you
can't
executive
privilege,
containers
in
production,
namespace
and
then
errors
gonna
be
generated.
A
If
the
body
of
the
rule
is
true,
and
so
you
can
read
the
body
basically
as
input
spec,
operation
matches
get
and
spec
namespace
matches,
production
and
and
the
the
pod
itself
is
rather
is
the
containment.
Pod
refers
to
a
privileged
container
and
we
have
a
little
function
that
defines
whether
or
not
a
pod
is
pratas
privileged,
and
so
we
we
look
up
the
the
pods
back
from
kubernetes
and
we
search
over
the
containers
in
that
pod
spec
and
then
we
check
if
any
of
them
have
that
privileged
bit
set,
and
then
this
this
policy.
A
So
Bob
the
policy
says
the
Bob
is
alive.
So
the
question
was:
what
happens
if
Bob
changes
the
spec,
and
so
you
can
write
a
policy
that
prevents
Bob
from
actually
modifying
the
spec
if
you
want
to,
but
in
this
case
he
should
be
able
to.
Maybe
he
should
be
able
to
do
that.
Maybe
he
should
be
able
to
exact
into
those
containers,
but
it's
okay
so
now
like
so
that
policy
worked
that's
great,
but
what
I
want
to
highlight
is
how
open
lets
you
write,
policies
that
are
very
dynamic
and
so
everything's
on
fire.
A
Now
something
happened
in
the
infrastructure,
and
so
we
want
to
actually
give
Bob
access
now
to
that
container,
and
so
what
I've
done
is
I've
defined
its
little
simple
policy
here
that
just
says:
break
glass
is
true,
and
so
I'm
gonna
load
that
policy
into
OPA
as
it
config
map
again
and
now.
If
I
try
to
executive,
the
container
I
can
right.
So
that's
cool.
So
this
just
shows
how
you
can
actually
like
change
the
behavior
at
runtime
very
easily,
okay,
and
so
now
that
the
calm
has
been
restored.
A
The
issues
been
fixed
and
if
I
try
to
connect
into
the
container
again
I
get
I
get
the
original
error
message
back
right.
So
these
policies
can
be
very
dynamic
that
I,
actually
I
specified
break
glass
as
a
policy,
but
it
could
also
just
be
data
that
you
load
into
the
policy
engine.
So
you
don't
have
here
you
could
you
could
hook
it
up
in
different
ways?
A
A
So
we
have
a
bunch
of
integrations
for
OPA
that
let
you
hook
it
up
to
projects
like
kubernetes
in
sto,
but
we
didn't
until
recently
have
a
live
standard
library
of
policies
that
you
could
take
off
the
shelf
and
use
to
enforce
all
kinds
of
different
things
like
admission
control
and
authorization
and
placement
and
auditing,
and
so
on
across
a
wide
range
of
different
projects.
So,
for
example,
we
have
risk
management
policies
for
terraform.
We
have
security
group
auditing
policies
for
Amazon.
We
have
admission
control
policies
for
kubernetes.
A
We
have
auditing
policies
for
kubernetes,
we've
got
similar
things
for
docker,
and
we've
also
got
some
auditing
policies
for
sto
to
make
sure
that
your
ISTE
of
cluster
is
set
up
correctly,
and
so
this
is
a
great
if
you're
interested
in
this
kind
of
stuff,
it's
a
great
way
to
get
get
involved,
because
these
policies
are
very
high-level,
they're,
pretty
easy
to
write
it's
kind
of
fun
because
you
just
have
to
work
with
data.
It's
very
predictable
and
enjoyable,
so
yeah,
so
I
recommend
that
everybody
check
out
the
extensibility
features
in
kubernetes.
A
1.9
I
think
that
they're
gonna
really
enable
a
bunch
of
new,
interesting
use.
Cases.
Projects
like
the
meta
controller
or
quite
exciting
OPA
is
a
really
cool
project
that
we're
really
excited
about,
because
it
provides
this
reusable
building
block
that
you
can
use
to
enforce
all
kinds
of
different
policies
across
all
these
different
projects,
and
you
can
get
started
without
having
to
write
any
code
right.
You
can
take
an
off-the-shelf
integration
and
a
bunch
of
off-the-shelf
policies
and
apply
them
to
your
infrastructure.
A
To
do
all
kinds
of
things
like
apply,
security
controls
and
the
resource
management
controls
and
so
on.
It's
the
last
thing
I'll
point
out
is
that
it's
just
like
what
enables
all
of
this
is
the
extensibility.
That's
been
added
into
kubernetes,
so
when
you're
thinking
about
designing
these
kinds
of
systems,
think
about
extensibility
and
think
about
decoupling
policy
decisions
from
policy
enforcement.
A
A
So
this
policy
is
referring
to
kubernetes
paw
data
kubernetes
pods,
and
the
question
is
whether
the
question
is
whether
or
not
that's
being
queried
synchronously
or
whether
it's
been
cashed
in
Opa,
and
the
answer
is
that
it's
being
actually
being
cashed.
So
when
we
deploy
open
on
top
of
kubernetes,
you
can
configure
it
to
actually
replicate
all
the
pods
and
deployments
and
config
maps
and
services
and
so
on
into
OPA.
So
then
you
can
write
policy
over
them.
A
Okay,
so
you
can
take
the
same
idea
and
you
can
use
it
to
write
auditing
policies,
for
example.
So
if
you
want
to
like
find
whether
or
not
you
know
all
pods
are
specifying
you
know,
resource
limits
and
resource
requests
and
so
on,
you
can
do
that
or
if
you
want
to
find
pods
that
are
not
dropping,
you
know
privileges
or
something
like
that.
Our
capability,
security
capabilities
and
so
on
you
can.
You
can
do
that,
so
you
can
get
all
this
data
into
open
and
then
interact
with
it
very
very
easily.
A
That's
that's
a
good
question,
so
we
so
the
question
is
whether
or
not
the
logging,
the
audit
logging
you
mean,
is
being
handled
by
Etsy
D.
We
haven't
hooked
up
the
audit
logging
to
anything
yet
so
right
now
you
can
just
query
OPA
and
get
back
these.
These
events,
basically,
are
these
warnings,
errors
and
info
messages
right,
but
you
could
certainly
take
that
and
pump
them
as
events
into
kubernetes
and
then
use
use
the
kubernetes
event
system
to
take
get
access
to
them.
Yeah.
A
Yes,
so
I
haven't
shown
this
here,
but
you
can
write
basically
built-in
functions
for
the
policy
engine
and
those
built-in
functions
can
call
out
to
external
think
you
can
do
whatever
you
want
in
a
built-in
function,
so
you
can
execute
a
request
against
an
external
service
to
get
some
data
or
whatever
you
need
that
obviously
like.
If
you
do
that,
then
you
kind
of
couple,
your
policies
to
that
external
system,
and
so
it
makes
them
a
little
bit
harder
to
test
in
your
development
environments
locally
with
like
unit
tests.
A
A
So
the
question
is:
what
happens
if
you
delete
a
config
map
that
contains
the
policies,
and
the
answer
is
that
so
the
the
COPE
is
basically
watching
the
API
server
free
config
maps
that
have
a
label
on
them.
That
say
they
contain
policy,
and
if
that
config
Maps
gets
it
gets
deleted,
then
Oakland
gets
that
notification
that
it's
been
deleted
and
it
uninstalls
the
policy
from
the
engine.
So
just
like
it's
adding
them
when
it
sees
them
created
or
modified
or
up
sorting
them
when
it
sees
them
created
or
or
modified.
A
To
date,
so
today
you
would
get
an
error
back
from
the
it
would
try
to
try
to
push
an
error
back
up,
but
then
I
guess
yeah.
That's
not
well
supported
today.
So
one
of
the
improvements
that
we
have
probably
we'd
like
to
do
is
make
this
instead
of
using
config
Maps
to
use
CRTs
because
some
resource
definitions
and
then
you
can
do
synchronous,
validation
of
the
of
the
changes
that
are
made
against
those
those
CRTs
and
prevent
that
from
happening.
I
guess
you
could
also
yeah.
A
So
what
I?
So
in
this
case,
you
can
see
that
the
packages
are.
The
policies
are
actually
namespaced
with
a
package
directive,
so
you
can
prevent.
The
question
is
like
what
whether
it
would
happen
if
you
defined
the
same
function
in
multiple
files
yeah.
So
if
there
I
guess,
if
they're
in
the
same
package,
then
we
would
the
policies
get
compiled.
So
we
would
either
return
an
error
back
to
because
there's
a
conflict
or
something
like
that
or
if
there
are
different
packages
that
that's
sort
of
a
fine
yeah.
Next
behind.
A
Yeah
sure
so
so,
role
based
access
control
is
great.
It
provides
a
nice
high
level,
configurable
way
of
controlling
who
can
do
what,
but
it's
very
limited
in
terms
of
the
expressiveness
that
it
gives
you
over.
Who
can
do
what,
because
it
limits
you
to
say
like
okay,
Torin
can
do
pod
creation
in
an
in
a
namespace,
but
it
doesn't
let
you
say:
Tauron
can
cannot
create
pods
that
have
that
refer
to
an
image,
that's
outside
of
our
internal
registry
right
or
any
kind
of
combination
like
that
right.
A
A
So
the
question
is:
how
do
you
use
this
in
in
in
other
environments,
effectively?
Okay,
so
yeah?
So
you
can
take
open
and
you
can
run
it
as
a
library
like
so
if
you're
building
around
services,
you
can
use
it
as
a
library
by
embedded
in
getting
to
into
those
services,
or
you
can
run
it
next
to
them,
either
as
a
sidecar
or
on
top
or
either
on
the
host.
And
then
your
services
can
query
open
and
ask
for
policy
decisions.
A
Now,
if
you
want
to
use
it
for
something
like
terraform,
for
example,
you
can
like
generate
a
terraform
plan
and
then
run
run
that
plan
through
alpha
to
get
an
authorization
decision,
for
example
in
your
CI
CD
pipeline.
If
you
want
to
use
it
in
in
a
in
a
cloud
provider,
then
we
need
to
have
extensibility
or
hooks
in
those
in
those
providers
to
call
out
to
an
external
endpoint,
so
kubernetes
is.
It
does
a
very
good
job
of
that.
Hopefully
we
see
more
of
that
from
other
other
platforms.
A
So
the
question
is
whether
or
not
you
can
apply
policies
based
on
what
the
container
is
actually
doing
so
right,
so
the
policies
I
showed
are
just
operating
over
kubernetes
configuration
right.
If
you
can
get
data
that
describes
what's
happening
inside
of
those
containers
into
OPA,
then
you
can
write
policy
over
it
so
opens
not
coupled
to
any
of
these
projects
or
any
these
providers
anyway,
it's
all
just
dated,
oh,
but
it
doesn't
we're
not
running
a
couple
two
kubernetes
or
anything
like
that.
Okay,
all
right!