►
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
Enforcing Service Mesh Structure using OPA Gatekeeper - Sandeep Parikh, Google
Organizations need the ability to apply rules to their workloads and services, at scale and distinct from the development of those services. Policies and policy enablement provide those governance capabilities with declarative approaches. OPA Gatekeeper integrates with Kubernetes and is able to provide the right guardrails to enforce structure and keep your deployments running smoothly. In this session we'll talk about policy management and how OPA Gatekeeper can help manage policies at scale. We'll walkthrough the high-level architecture of Gatekeeper along with applied examples and demonstrate how it can be used to manage security and traffic management mechanisms found in service mesh deployments.
https://sched.co/Uac5
A
B
B
So
I'll
try
to
keep
it
lively,
but
this
is
probably
not
a
terribly
exciting
topic
right,
who's
really
psyched
about
IT
governance
and
applying
controls
to
kubernetes
right
yeah,
good.
All
right,
my
name
is
sun
dip
I
work
at
Google
cloud.
You
can
find
me
on
github
or
Twitter
at
circus
monkey.
The
vowels
feel
free
to
tweet
awesome
things
about
this.
Talk
throughout
it'll
be
great
all
right.
So,
let's
start
with
policies.
What
are
policies?
Well,
policies
are
rules
right.
B
We
are
attempting
to
sort
of
define
a
set
of
rules
that
tell
us
whether
we
can
make
changes
to
a
resource.
That's
really
it
when
you
boil
it
all
down.
Well,
then,
what's
policy
management
right?
It's
really
the
act
of
authoring,
developing
deploying-
and
you
know,
using
those
policies
in
a
you
know,
in
a
cluster
environment
or
in
in
kind
of
a
deployment
of
some
type.
B
So
when
I
talk
about
policy
management,
there's
often
this
kind
of
mental
overlap
with
something
like
config
management
and
the
two
are
pretty
closely
related,
but
they're
definitely
distinct
right.
Ultimately,
config
management
is
about
how
you
store,
control,
govern
resources
or
objects
right,
there's,
typically,
a
process
around
who
can
do
config
management
right
and
usually
we
would
do
that
with
like
kubernetes,
are
back
controls
and
there's
a
process
around.
Who
can
do
it?
I'm?
B
Sorry,
a
process
around
how
to
do
it,
so
something
like
get-ups
right,
that's
typically,
the
approach
with
config
management
policy
management
again
is
about
the
rules,
that's
about
what
you
can
change
and
whether
or
let
them
make
that
change.
In
some
cases
it
could
be
something
where
you
say:
I'll
allow
a
change
but
I'm
gonna
audit,
any
potential
violation
outside
of
the
balance.
I've
kind
of
set
up
there's
a
little
bit
of
again
mental
overlap
as
well
between
policy
management
and
some
of
what
kubernetes
Arabic
offers.
B
B
What
we
found
and
I
think
everybody
in
the
room
probably
agree.
Kubernetes
is
an
incredibly
powerful
and
complex
distributed
system,
which
means
it
does
need
some
level
of
guardrails
and
level
of
controls
right.
You
need
to
be
able
to
exert
some
kind
of
manageability
around
it,
because
you
want
to
watch
out
for
things
like
overexposed
services
that
are
open
to
the
world
or
open
to
every
other
service
within
the
cluster
right.
You're
gonna
worry
about
things
like
data
exfiltration
right.
You
don't
want
your
data,
where
your
customers
data,
leaving
your
cluster
right.
B
Those
are
things
that
can
happen
with
an
improperly
configured
and
and
maybe
even
get
configured
it
correctly
at
the
starting
point.
But
over
time
the
configuration
is
drifted
in
some
meaningful
way
and
you've
got
to
watch
out
for
that
sort
of
thing,
but
the
controls
that
we
put
on
to
sort
of
lock
things
down
and
exert
some
some
sort
of
manageability
really
do
need
to
be
agile
and
flexible.
They've
got
to
be
easy
to
work
with,
otherwise
no
one's
gonna
adopt
them
right.
B
So
you
want
to
make
sure
that
you've
got
the
right
people
who
are
writing
somebody's
policies.
You
want
the
people
who
have
the
visibility.
The
services
know
the
api's
understand
the
software
that's
running
on
there
right
these
sorts
of
policies.
They
should
be
the
ones
that
are
driving
the
rules
right,
that's
a
really
important
component.
You
want
to
be
able
to
scope
those
policies
very
narrowly.
You
want
them
to
only
apply
to
the
stuff
you
care
about.
B
You
don't
want
them
broadly
applicable
unless
that's
the
way
you
designed
it,
but
in
most
cases
you're
trying
to
say
I
just
want
to
focus
on
one
object
and
make
sure
that
object
doesn't
change
all
right.
I
want
to
make
sure
that
the
metadata
of
a
particular
object
doesn't
change
or
I
only
want
to
restrict
any
changes.
You
know
airing
violations
to
this
one
particular
namespace.
B
So
scoping
is
also
really
important
because
at
the
end
of
the
day,
you're
trying
to
make
sure
things
in
production
stay
safe,
you're,
trying
to
avoid
breakage
once
it's
out
of
your
hands.
Mm-Hmm,
excuse
me
all
right,
so
how
do
you
enforce
structure
in
a
kubernetes
deployment?
So
you
start
with
open
policy.
Agent.
Opa
is
part
of
the
CCF.
It
is
a
general-purpose
sort
of
rules,
evaluation,
rules,
engine,
it's
got
all
the
typical
things.
You'd
expect
to
be
part
of
the
CN.
You
know
the
cloud
native
ecosystem,
one,
it's
obviously
declarative.
B
You
know
it
sort
of
unifies
and
distinguishes
to
a
degree
right,
the
development
of
applications
and
the
guardrails
that
you
need
to
put
on
those
applications
right.
It
distinguishes
between
the
configuration
of
the
cluster
and,
again
the
guard
rows.
We
want
to
put
around
the
configuration
of
the
cluster
and
it's
aware
of
everything
that's
going
on
within
that
environment
as
well
right.
It's
context
aware
what's
happening,
so
this
is
a
good
powerful
place
to
start
and
and
OPA
is
again
like
I,
said
very
general
purpose
right.
B
It's
it's
not
actually
a
part
of
kubernetes
as
a
standalone.
It's
just
a
mechanism
for
evaluating,
so
you
can
layer
this
into
a
number
of
different
ways.
Right,
there's
even
actually
ways
to
make
OPA
an
admission
controller
just
by
itself,
but
we'll
get
to
how
that
kind
of
fits
in
the
broader
term.
But
but
ultimately,
any
service
can
talk
to
open
policy
agent
and
query
against
it,
and
open
policy
agent
is,
is
kind
of
satisfy
cruel
xand
configuration
objects
that
it
has
access
to,
and
then
it
can
answer
that
query
back
based
on
the
rules.
B
You've
given
it
so
we're
just
gatekeeper,
Fitness,
so
gate
keeper
takes
OPA,
takes
open
policy
agent
and
essentially
wraps
it
into
a
cooperage
controller
and
specifically
a
kubernetes
admission
controller.
So
it
puts
itself
right
in
the
critical
path
of
when
objects
are
entering
into
the
cluster.
So
it
gives
you
the
opportunity
to
potentially
evaluate
anything,
that's
coming
in
anything
that
the
API
is
going
to
accept
and
make
a
decision
about.
B
What's
going
to
happen
to
that,
and
so
because
gatekeeper
makes
OPA
part
of
kubernetes
at
that
point,
all
of
the
standard
kubernetes
tooling
that
you
would
typically
use
to
talk
to
your
environment
stays
the
same
Coop's
ETL,
CI,
CD,
get-ups
generic
API
clients,
whatever
the
case
may
be,
what
gatekeeper
does
right
again?
It
kind
of
extends
the
approach
that
that
open
policy
agent
gives
you
so
with
OPA.
You
write
your
rules
in
rego
and
then
you
just
give
that
to
OPI
now
and
it
executes
those
rules
based
on
inbound
queries,
mm-hmm
with
gatekeeper.
B
You
have
to
do
a
little
bit
more
work.
You
take
that
rule
object
that
rego
code
and
you
embed
it
inside
a
custom
resource,
and
then
you
give
that
to
gatekeeper.
So
now
gatekeeper
knows
about
a
new
CR
in
the
cluster,
and
then
it
can
build
constraints.
Based
on
that
rule,
you
just
gave
it
and
we'll
go
into
more
depth
as
we
kind
of
make
our
way
through
here.
B
So
what
does
a
policy
object?
Look
like
and
before
I
go
too
far
into
this
the
way
policies
work
the
way
they're
managed
the
way
they're
enforced.
There's
two
parts
to
this:
one
is
the
set
of
rules
that
you're
that
you're
writing
and
the
second
part
is
the
enforcement.
So
the
first
part,
the
rules
section
is
called
a
constraint
template
and
that's
an
example.
I've
got
up
here
oops.
B
B
When
I
apply
this
to
gatekeeper,
what's
going
to
happen
is
out,
there
is
a
new
top-level
type
right.
If
you
do
coop
CTL
and
get
crts
you'll
see
that
there's
a
new
one
called
destination
rule
TLS
enabled,
and
so
the
reason
that
you
separate
this
idea
between
the
policy
and
the
enforcement
of
that
policy
is
because,
depending
on
the
type
of
policy
you
have,
it
may
be
parameterised
right.
You
may
be
able
to
say
things
like
for
a
particular
namespace.
I
need
to
have
these
three
labels
on
every
incoming
deployment
object.
B
Well,
depending
on
the
namespace
you
want,
you
may
want
to
change
what
that
looks
like.
So
in
that
case,
you
may
have
a
single
constraint
plate
right,
a
single
set
of
rules
that
does
the
actual
checking,
but
then
in
each
namespace
you
care
about
scoped
to
each
namespace.
You
care
about.
You
may
have
a
new
individual
constraint,
object
that
lets
you
again
operate
and
scope
it
to
those
parameters
in
particular.
B
So
the
second
half
as
I
mentioned,
is
a
constraint
object.
A
constraint
just
takes
that
CR
you
created.
It
creates
that
same
top-level
type,
and
this
is
where
you
get
to
define
the
enforcement
and
the
scoping
of
that
rule
you
just
created.
So
in
this
example,
we
have
an
enforcement
action
of
deny.
So
that's
going
to
tell
the
admission
controller
that
if
any
object
comes
in
that
violates
the
rule
in
the
previous
slide.
Just
kick
it
right
back
out,
give
it
a
nice
error
message
and
then
send
it
on
its
way.
B
But
you
also
have
the
opportunity
to
audit
incoming
objects
and
say
look.
This
is
a
soft
guardrail.
It's
not
something!
That's
gonna
break
production,
but
it's
something
we
might
want
to
know
about
later
on.
So
you
can
change
this
and
change
it
to
auto
mode.
So
it'll
accept
those
objects,
and
then
you
have
the
ability
to
go
and
check
audit
violations
or
status
violations
later
on
the
bottom
half
down
here
or
the
bottom
section
is
where
we
scope
it.
So
we
say
we
know
we're
telling
it
now.
B
This
is
where
you
apply
this
constraint
to,
or
this
crits
right
in
this
set
of
rules,
so
in
this
case
I'm
scoping
it
to
a
destination
rule
which
is
one
of
the
api's
that
are
part
of
SEO
and
I'm
gonna,
say
it's
only
gonna
focus
on
the
default
namespace,
but
just
like
a
lot
of
the
great
tools
we
have
in
the
ecosystem,
you
can
get
a
lot
more
fine-grained
here.
We
can
actually
specify
a
specific
namespace
selector
based
on
things
like
labels,
so
I
can't
actually
say
something
to
the
effect
of
hey.
B
I
only
want
to
focus
on
namespaces,
where
this
particular
metadata
set,
or
in
this
example
that's
commented
out.
Only
namespaces
where
is
to
injection
is
enabled.
So
you
have
that
ability
to
really
focus
down
where
you
want
to
apply
that
enforcement,
which
is
good.
You
don't
want
to
have
too
many
objects
that
are
applying
to
every
single
thing
coming
through,
because
they're,
probably
not
fine-grained
enough,
they're,
probably
not
really
going
to
give
you
the
constraint
you're.
Looking
for.
B
So,
there's
one
more
piece
to
this
puzzle
when
you're
talking
about
gatekeepers
that
you've
got
to
actually
tell
gatekeeper
how
to
capture
some
of
these
objects
and
so
to
use
the
namespace
selector.
That
I
just
showed
in
the
previous
slide.
You've
got
to
make
sure
that
you're
synchronizing
your
synching,
the
data
about
namespaces
into
the
gatekeeper
system
namespace.
So
the
gatekeeper
controller
is
basically
caching
the
metadata
about
any
of
these
objects,
and
the
reason
you
do
this
is
because
you
may
have
one
for
the
namespace
selector
as
I
mentioned.
B
So
it's
got
to
know
about
all
the
namespaces
and
all
those
metadata,
but
for
any
objects
that
may
have
multi
object
policies
or
for
any
situations
where
you
may
want
to
audit
something
after
it's
a
bit
admitted
to
the
cluster
gatekeeper
system
needs
to
know
about
it
or
the
gatekeeper
configuration
needs
to
know
about
it.
So
this
this
file
is
pretty
pretty
typical.
B
B
B
B
So,
typically,
a
service
mesh
right
has
a
sidecar.
It's
it's.
You
know
right
next
to
your
services
and
it
helps
create
kind
of
this
approach
where
you
can
independent
of
those
services
independent
of
the
code.
That's
running
in
your
applications.
You
know
automate
network
functionality
right,
that's
essentially
it
lets.
You
apply
sort
of
network
automation
across
the
board
to
a
large
to
a
large
kind
of
pool
of
applications
and
services.
B
Specifically
with
Sto
right
out
of
the
box,
you
get
a
pretty
decent
amount
of
observer
ability,
so
telemetry
logs
tracing
you
get
traffic
controls
which
I
think
I've
called
operational
agility,
because
that
sounded
really
cool.
And
then
you
also
get
like
a
policy
driven
security
approach
and
I
apologize
that
there
is
an
it's
Oh
object
called
policy
in
here
that
I
will
be
referencing
several
times
so
you're
confused
between
which
policy
thing
I'm
talking
about,
feel
free
to
find
me
after
and
I,
will
help
try
and
disambiguate
ever
so
slightly.
B
So
if
you
kind
of
dig
in
a
little
bit
in
depth
with
this,
do
observability
I
mentioned
logs
tracing,
you
know
telemetry
and
monitoring
data
for
traffic.
You
get
to
do
anything
to
those
services
as
it
relates
to
the
flow
of
traffic
coming
in
or
out
of
your
services.
That's
what
that
sidecar
does,
and
it
also
includes
things
like
the
ability
to
do
rate,
limiting
circuit,
breaking
Canaries,
all
that
sort
of
good
stuff
traffic
steering
and
then
with
security.
B
There's
a
pretty
solid
authentication
and
authorization
model,
and
the
authentication
component
includes
the
ability
to
encrypt
all
the
traffic
between
services
as
well.
So
it
ends
up
being
a
pretty
powerful
mechanism,
as
I
mentioned
earlier,
I
often
like
to
think
of
service
mesh
and
specifically
sto
as
ultimately
network
automation
at
scale,
but
for
any
again
complex,
powerful
distributed
system
and
I.
Think
sto
quad
opening
service
mission,
general
sort
of
qualifies
people
typically
have
really
good
intentions
right,
you're
trying
to
do
something
compelling,
but
you
have
to
watch
out
for
problems
right
things
happen.
B
You
can't
always
control.
What's
gonna
happen
right,
you
may
have
pushed
a
good
config
in
to
get
that.
Maybe
the
config
that
got
synced
to
the
cluster,
but
somebody
in
the
room
may
have
cluster
admin
access
and
may
have
patched
that
configure
maybe
have
changed
something
or
maybe
they
pushed
an
object,
and
maybe
they
broke
something
right.
Breakage
can
happen
anywhere.
B
It's
not
just
gonna
happen
with
one
team
at
the
you
know
all
the
way
shifted
left
it
could
happen
anywhere
along
that
pipeline,
because,
ultimately,
teams
have
you
know
a
mix
of
declarative
and
paired
of
access
to
kubernetes.
So
you've
got
to
watch
out
for
that
sort
of
thing
and
that's
really
what
we're
trying
to
enforce.
It's,
not
just
you
know,
potential
breakage
on
the
far
right,
but
it's
also
shifting
left
over
time
all
right.
So
I'm
gonna
talk
through
a
few
examples
of
sort
of
structural
problems
you
could
run
into
with
this.
B
Do
some
of
these
are
sort
of
self-inflicted
and
some
are
guardrails
you
might
want
to
set
up
in
advance
of
you
know
again
deploying
to
production.
So
one
of
the
first
ones
is
there's
a
requirement
in
SEO
today
and
I'll
talk
about
that
a
little
later,
but
today
there's
a
requirement
isseo
that
if
you
want
your
pods
and
services
to
be
picked
up
by
the
service
mesh,
you
have
to
follow
a
very
specific
port
naming
convention
right
in
your
service
port.
So
you
can
see
down
here.
I
didn't
follow
that
convention
right.
B
You
have
to
actually
labeled
with
the
protocol
as
the
prefix,
you
have
to
tell
it
HTTP
G
RPC
TCP
what-have-you.
So
in
this
case,
if
I
were
to
deploy
this
service,
it
actually
would
not
be
able
to
route
traffic
to
it.
It
would
route
traffic
to
it,
but
it
wouldn't
use
any
sto
routing
rules.
I
should
say
so.
This
is
something
that
we
want
to
catch.
B
All
right.
So
the
next
one
is
enforcing
M
TLS.
So
you
can
write
a
top-level
sort
of
sto
policy
object.
That
says:
hey
for
everything
in
the
namespace
that
I
apply.
This
policy
object
to
all
the
services.
They
must
only
accept
M
TLS
connections,
but
there
is
actually
an
ability
to
override
this
at
the
host
level.
You
can
say
again
within
that
same
namespace,
where
I've
said
all
services
must
accept.
M
TLS
I
can
write
another
policy
that
says:
hey,
listen,
I'm
special,
my
service
is
special
I.
Don't
want
to
accept
M
TLS
connections.
B
I
want
to
go
permissive
right,
so
you
can
actually
do
this,
and
now
that
service
at
back-end
will
actually
accept
unencrypted
connections
or
are
not
the
indicated
connections.
I
should
say
so.
This
is
another
thing
you
want
to
build
to
catch
right,
and
this
isn't
really
a
structural
problem.
It's
more
of
something
where
you
may
have
a
corporate
policy
that
says:
hey,
listen,
we're
only
do
an
M
TLS
right,
its
compliance,
its
regulatory.
What
have
you
right?
It's
about
safety?
B
Someone
can
still
override
that
another
one
is
a
mismatched
M,
TLS
situation.
We've
seen
this
before
in
the
field
as
well,
where
you
may
have
something
in
again:
a
situation
where,
in
a
host,
you've,
told
you're,
told
services
only
accept
em,
TLS
connections,
but
then
a
destination
rule
which
controls
what
clients
do
in
sto
a
destination
rule
comes
in
and
says:
I'm
gonna,
disable
I'm,
TLS
right
I'm,
telling
clients
that
they
don't
have
to
use
em,
TLS
and
now
the
problem
is
that
service
is
expecting
an
authenticated
connection.
B
Clients
aren't
supplying
one.
So
then
what
happens?
You
end
up
with
five
or
threes
right.
This
is
the
situation
where
and
even
like
the
previous
one.
You
probably
want
to
deny
admission
to
objects
that
do
this
sort
of
thing
right,
not
even
just
because
it's
about
security,
but
this
is
gonna,
be
something
that's
end
user
facing
right.
If
you
break
some
of
these
empty
LS
settings
in
your
deployment,
its
impacted
by
your
end,
users.
B
It's
another
one
is
authorization
controls,
so
it's
got
a
pretty
rich
authorization
model
and
in
fact
this
is
now
a
deprecated
approach
as
of
this
week.
So
thanks
sto
team,
we
switched
from
using
the
service
role
service
role,
binding
to
a
much
cleaner
and
sort
of
tighter
authorization
policy
object.
But
that's
okay,
I
left
the
example
in
there.
The
point
is
that,
with
the
authorization
model
you
can
do
interesting
things
like
service.
A
can
talk
to
service
B,
a
can
talk
to
see,
but
B
can't
talk
to
C
right.
B
You
can
write
that
easy
config
in
your
deployment,
and
you
may
have
a
situation
where
you
say:
hey,
there's
a
front-end
and
it's
got
to
talk
to
its
back-end,
but
no
one
else
should
talk
to
that
back-end
right.
You
may
want
to
lock
that
access
down-
and
maybe
you
did
your
rope
that
config
the
right
way
and
then
someone
was
debugging
or
trying
to
open
up
service
and
they
changed
something
and
they
took
out
that
source
principle
and
they
said
hey.
We
don't
care
about
that
service,
account
we'll.
B
B
So
I
think
this
is
the
last
one
virtual
services,
so
virtual
services
are
what
control
some
of
the
east-west
traffic
within
a
deployment.
This
is
actually
telling
traffic
essentially
how
to
go
from.
You
know
sort
of
point
A
to
point
B
in
a
cluster.
Well,
virtual
services
are
really
powerful,
except
we
don't
check
them
for
you
on
the
way
in.
So
what
might
happen
is
someone
may
actually
have
a?
You
are
eyes
that
are
clobbering
all
over
each
other.
B
So
if
you
were
to
push
both
of
these
objects
into
the
cluster
you're
only
going
to
technically
wrap
traffic
to
one
host,
because
these
files
look
very
similar.
These
objects
look
very
similar
right,
I'm,
saying
for
all
hosts,
you
know,
and
if
the
URI
matches
/hello
send
it
to
version
1
or
version
2
well,
which
one
of
these
is
actually
gonna
work
sort
of
fundin.
It's
not
gonna
unknown
right,
depending
on
the
day,
it
might
be
the
first
one
to
the
second
one.
B
So
that's
not
a
really
great
use
case,
because
now
different
teams
may
be
wondering
why
their
traffic
is
getting.
You
know
picked
up
by
some
other
service.
So
that's
another
thing
you
want
to
watch
out
for
all
of
these
examples
are
things
that
we
can
catch
in
advance.
We
can
either
reject
admission
to
the
cluster
if
they
violate
again
a
corporate
policy
regulatory
compliance
security
or
they
could
just
be
good
things
for
us
to
audit
and
capture
and
be
able
to
check
up
on
and
fix
later
on.
B
So
some
other
interesting
I
think
policies,
and
this
gets
into
more
of
the
the
sort
of
guardrails
and
governance
stuff.
But
I
talked
about
requiring
strict
m
TLS
between
clients
and
services
in
a
specific
namespace,
locking
down
that
fine-grained
authorization
control
to
make
sure
that
you're
not
allowing
anyone
to
talk
to
your
services,
but
only
a
very
specific
sort
of
source
or
destination.
You
may
have
policies
that
are
specific
about
telemetry
settings
because
you
don't
want
to
lose
telemetry.
It
may
be
very
important
for
your
own
businesses.
Audit
controls
right.
B
It
may
be
really
important
for
you
to
make
sure
that
logging
is
always
turned
on
or
that
you're
getting
certain
metrics
so
that
you
know
when
things
are
going
down
or
when
you
need
to
you
know,
adjust
resources.
So
there's
a
whole
bunch
of
these
and
we're
not
going
to
talk
through
all
of
them
right
now,
but
there's
a
lot
you
can
do
with
gatekeeper.
I
can't
stress
that
enough.
It
is
an
incredibly
powerful
mechanism
right
and
it's
a
really
powerful
tool
to
me
sure
things
don't
break
and
that's
really
what
you're
trying
to
avoid.
B
So,
if
we
add
gatekeeper,
do
we
get
that
strong
structural
approach?
So
now
I'm
gonna
try
to
do
a
couple
of
demos
for
you.
I've
got
five
demonstrations
anybody's
seen
a
demo
of
an
admission
controller
before
yeah.
It's
not
terribly
exciting,
because
you
push
something
and
then
it
doesn't
get
a
minute
in
a
cluster.
That's
pretty
much
the
end
of
it.
So
you
know
hopefully
I
don't
lose
any
of
you
while
I'm
doing
this,
but
we'll
see
how
it
looks
so.
B
Let's
see
the
first
thing
we're
gonna
do
here
is
I'm
just
gonna
run
me
a
little
demo
script
all
right.
So
the
first
thing
we'll
do
is
we're
gonna
check
and
see
what's
in
the
cluster.
Just
so
I
can
show
y'all
in
advance
and
I.
Just
now
realized
that
I
left
a
bunch
of
stuff
running
in
the
cluster.
That's
alright,
we'll
figure
it
out.
Let's
check
some
pod,
so
there's
just
a
couple
of
there's
a
couple.
Little
services
running
here:
nothing,
nothing
important
I'll
show
some
of
the
services
that
are
running
right.
B
This
is
just
basic
stuff,
but
now,
let's
look
at
what's
in
the
entire
thing,
so
this
is
actually
what's
deployed
in
the
cluster,
so
I've
got
sto
deployed
in
the
sto
system,
namespace.
Obviously
there's
a
bunch
of
GK
and
kubernetes
stuff
in
there
and
at
the
very
top.
The
second
line
is
gatekeeper,
so
gatekeepers
installed
just
by
using
the
normal
instructions
that
are
on
github
and
it
installs
in
its
own
namespace
gatekeeper
system.
B
And
so,
if
you
remember
earlier,
when
I
talked
about,
there
are
two
parts
to
a
policy
right,
there's
the
rule
and
then
there's
the
enforcement
of
that
rule.
So
what
I've
done
in
advance
is
I've
actually
pushed
all
my
rules
into
the
cluster,
so
I'm,
actually
showing
all
that
constraint.
Templates
I've
already
pushed
those
into
the
cluster
because
in
production
in
the
real
world,
what
you
may
be
doing
is
you
may
already
have
those
templates
living
in
the
cluster
right.
B
Alright,
so
the
first
one
will
do
is:
can
we
check
for
bad
port
naming
conventions
right?
That
was
an
example
I
mentioned
earlier.
So
let
me
take
a
look
at
what
that
template
looks
like.
So
this
is
a
bad
port
naming
template
and
if
I
page
down
here,
you'll
see
the
rego
code
at
the
bottom
or
in
that
bottom,
half
I'm,
not
gonna,
read
through
this
line.
B
So,
let's
take
a
look
at
the
course
of
a
corresponding
constraint
object.
So
you'll
see
this
one.
The
enforcement
action
here
on
what
is
the
line.
Six
it's
set
to
dry
run
dry
run,
is
essentially
saying
allow
admission
to
a
service
that
might
violate
this
constraint
and
audit
any
breakage
right
audit,
any
pension
violations
and
then
you'll
see
down
there
as
well.
The
namespaces
I've
chosen
for
this
are
the
sto
system.
B
B
So,
let's
push
the
constraint
into
their
cluster.
Alright.
That
was
already
in
there
because,
like
I
said,
I
just
ran
this
about
30
minutes
ago.
That's,
okay
and
let's
take
a
look
at
a
bad
port
name
object.
So
if
you
look
over
here
at
the
very
top,
this
is
an
example.
I
showed
earlier
in
the
slides,
but
the
port
name
is
hello.
Port
right!
I!
Don't
have
any
of
those
well-known
prefixes,
so
this
well.
B
This
deployment
will
actually
get
a
sidecar
proxy
as
part
of
ISTE,
oh,
but
it
won't
actually
respond
to
traffic
rules
because
I've
got
a
bad
port
name.
So
now,
let's
see
what
happens
if
I
push
that
into
their
cluster,
that's
gonna
go
in
alright!
Well,
that
was
already
there
and
the
next
thing
is:
let's
take
a
look
at
the
constraint,
object
that
I
created,
so
it
ends
up
being
a
little
bit
long
right
because
you
actually
have
to
refer
the
entire
full
path
of
it.
B
So
what
I'm
saying
is
I
want
to
get
the
that
CR
that
container,
that
customer
resource
allowed
service
port
name
constraints,
gate
keeper
data
SH,
get
the
specific
port
name
constraint.
I
gave
it
take
a
look
at
it
when
ya
mo
and
I'm
gonna
watch
it
for
any
status
changes
because
in
the
status
field
down
here
in
the
lower
third
of
the
screen,
you'll
see
there's
a
couple
of
violations
noted.
B
Alright,
we
actually
have
a
situation
where
it
says:
well
the
kubernetes
service
by
itself
already
it's
the
wrong
one
as
well,
but
the
service
hello
world,
the
default
port
name.
Is
it's
missing
a
prefix
right?
So
this
is
an
example
of
one
where
we
did
dry
run.
This
was
we're
gonna
block
admission
to
the
cluster
for
this,
but
we
wanted
to
be
able
to
audit,
because
this
could
be
a
reason
that
things
aren't
working
like
we
expected.
B
Alright,
so
the
next
one
I
want
to
talk
through
is
mismatched
MPLS
settings,
and
this
one
is
interesting
because
if
you
look
about
see
line,
17,
that's
kinda,
the
templates
kind
of
start
to
blend
together
for
a
while
and
again
I'm,
not
gonna,
go
through
the
Rigo
code
in
depth.
But
this
template
is
a
good
example
of
I'm
evaluating
a
destination
rule
coming
in,
but
before
I
can
evaluate
that
destination.
Rule
I
need
to
check
for
a
corresponding
sto
policy
object
that
might
already
be
in
the
cluster.
B
So
the
first
thing
I'm
going
to
do
is
I'm.
Actually
gonna
pull
out
of
the
sort
of
inventory,
I'm
gonna,
pull
out
any
policy
objects
and
make
sure
I
kind
of
iterate
through
them
and
check
for
any
places
where
the
policy
object
specifies
a
hostname
and
that
it's
strict
MPLS,
you
know
and
the
destination
rule
is
saying
the
same
hostname,
but
it
might
be
saying
disable
MPLS.
So
that's
what
this
policy
is
doing.
B
B
B
Okay,
well
that
didn't
work
so
I
apologize.
I
will
check
on
that
later
that
one
I
think
is
already
in
there
because
I
broke
it
earlier,
so
I
will
double
check
it.
So
the
next
one-
and
we
will
make
our
way
through
here
so
here's
another
good
example.
This
is
one
where
we
might
want
to
say:
hey
I
have
a
corporate
policy
that
says:
M
TLS
must
be
on
in
a
particular
namespace
for
all
services.
B
Now,
what's
interesting
about
this
policy
is
that
you
can
see
that
the
sort
of
violation
conditions
kind
of
go
on
and
on
here
and
there's
a
reason
for
that.
So
one
the
way
it
works
in
Rego
is,
if
you
have
multiple
different
ways
that
a
violation
can
be
thrown,
you
need
to
specify
them
in
sort
of
different
violation.
You
know
functions
or
sort
of
groupings
and
what
happens
is
if
any
of
the
and
when
you,
when
you
do
it
this
way
where
you
have
you
know
separate,
separate
blocks
of
violations,
they
get
Ord
together.
B
So
if
any
one
of
these
throws
it'll
throw
a
violation,
and
so
in
this
case,
I've
got
three
different
options.
Here,
because
the
way
you
specify
em
TLS
in
an
sto
policy
object
is
a
little
weird.
You
actually
have
two
specific,
like
I'm,
specifically
checking
for
different
combinations
of
the
API
object
to
make
sure
that
it's
gonna
qualify
here
right,
I
need
to
check
for,
for
example,
in
in
this.
If
you
don't
specify
this
spec
peers
field,
then
it's
actually
turning
off
M
TLS,
all
right.
B
If
you
don't,
if
SPECT
up,
here's
is
just
an
empty
array,
it
also
attempts
to
turn
off
M
TLS
and
then.
Finally,
if
it's
set
to
permissive,
that's
obviously
explicitly
turning
it
off
but
they're.
Basically,
there
are
a
couple
implicit
ways
and
turn
it
off.
So
you
need
to
make
sure
you
check
for
all
possible
conditions.
B
So
let's
try
that,
let's
see
if
this
one
works,
all
right,
so
the
constraints
in
there
and
we're
gonna
take
a
look
at
a
bad
policy
object
here.
So
this
is
one
that
we're
trying
to
catch
so
good.
It's
trying
to
try
to
push
this
one
in
and
let's
see
what
happens
all
right.
So
here's
an
example
where
the
admission
control
had
caught
it
and
said
sorry,
gate
keeper
said
no
thanks.
B
You
can't
get
in
here
because
you're
violating
this
rule,
then
I'm
not
gonna,
read
out
to
you,
but
it's
basically
a
bunch
of
error
message
now.
What's
also
interesting
about
this
one.
This
constraint
in
particular
is
that
there
was
already
a
bad
policy
object
in
the
cluster
that
I
left
there
from
earlier
on
purpose.
B
All
right,
so
we
didn't
cover
all
of
them,
preventing
virtual
service
hostname
collisions,
recording
services,
the
disabled,
unauthorized
access,
I
apologize,
we're
gonna
run
out
of
time.
So
what
I
would
say,
though,
is
I,
have
a
link
to
the
github
repo
where
all
of
these
are,
with
kind
of
a
little
bit
more
example,
and
more
a
little
more
information.
Please
take
a
look
at
them,
hoping
to
eventually
push
them
into
the
gatekeeper
sort
of
contribute
so
that
we
can
start
creating
a
large
base
of
these
things
to
share
with
everybody.
B
So
one
more
thing
I
did
want
to
mention.
Is
policy
controller
right?
What
is
policy
control?
Well,
so
policy
controller
is
actually
part
of
anthos
config
management.
Right
anthos
is
google's
sort
of
hybrid
kubernetes,
multi
cloud
software
right.
It's
a
giant
package
of
stuff
in
there
particularly
is
one
component
called
anthos
config
management,
so
Anthes
config
management
does
get
ops
right.
That's
actually
what
it
is
for
your
clusters
and
for
your
deployments
as
if
I
think
anthos
one
dot
once
or
a
couple
of
months
ago.
We
included
something
called
policy.
B
Controller
policy
controller
is
based
on
gatekeeper,
right
and
the
reason
I
mentioned.
This
is
because
gatekeeper
is
growing
in
its
popularity
in
its
usage.
We
are
now
including
it
as
a
core
part
of
one
of
our
biggest.
You
know
products
as
well
and
cloud
so
that
you're
gonna
see
a
lot
more
of
these
policies
and
objects.
I
strongly
urge
you
all
if
you
have
any
kind
of
IT
governance,
regulatory
compliance-
if
you
just
have
people
who
are
freewheeling
and
like
to
push
objects
in
your
cluster
all
day
long
I
need
to
set
some
rules.
B
Take
a
look
at
gatekeeper,
it's
incredibly
powerful
before
I
leave.
You
I
do
want
to
mention.
There's
a
handful
of
links
here.
These
are
all
the
slides.
Oh,
if
you
download,
with
the
slides
already,
do
it
again,
because
I
changed
a
bunch
of
stuff
in
the
last
two
days,
so
grab
them
again
from
the
link
there,
but
you
can
check
my
github
repo
for
now.
That's
where
those
policies
are
once
I
get
him
into
the
gatekeeper
contribute
and
do
all
that
stuff.
B
There's
a
link
to
gatekeeper,
there's
a
link
to
the
rego
policy
language
and
then
a
link
to
the
ACM
Docs
page.
If
you
want
to
dig
into
it,
the
other
thing
I
would
mention.
Is
there
anybody
from
styro
in
the
room,
real,
quick,
no
hands?
Okay,
there's
a
couple
people
back:
there
awesome!
Listen!
If
you're
gonna
write
rego,
they
had
this
great
tool
called
the
rego
playground,
which
makes
life
so
much
easier.
You
get
to
just
write
your
code
and
test
it
in
a
browser.
It's
really
handy
and
I
strongly
recommend
you
do
it.