►
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
Deep Dive: Kubernetes Policy WG - Torin Sandall, Styra & Da Ma, Zhipeng Huang, Huawei
The deep dive session of the Kubernetes Policy WG will consists of three sub-topics: - kube-batch and the policy requirements, Da Ma - Introduction of Azure Policy Controller, Torin Sandall - Container Policy Interface Proposal, Zhipeng Huang
To learn more click here: https://sched.co/FuLb
A
Okay,
so
what
I'm
gonna
talk
about
for
the
next
few
minutes
is
a
new
project.
That's
been
come
out
of
a
bunch
of
work
that
we've
done
within
the
open
policy
agent
over
the
past
two
years
and
that
is
now
being
carried
out
by
some
folks
at
Microsoft
in
the
azure
kubernetes
team.
So
these
are
not
my
slides.
These
slides
were
prepared
by
somebody
that's
working
on
the
kubernetes
policy
controller,
but
they
do
a
good
job
of
explaining
why
this
is
important.
A
So
over
the
last
two
years
or
so,
you
know,
kubernetes
has
seen
quite
a
bit
of
adoption
right.
More
and
more
enterprises
are
using
kubernetes
and
what
we're
starting
to
see
is
our
teams
forming
these
organizations
that
help
manage
kubernetes
right?
They
provide
kubernetes
as
a
service
to
the
rest
of
the
organization,
and
so
what
ends
up
happening
is
you
have
all
these
different
internal
customers
running
applications
on
top
of
kubernetes?
Now
you
have
different
teams
with
different
projects
and
different
products,
and
so
on,
and
some
of
those
teams
are
subject
to
different.
A
You
know
compliance
policies,
different
governance
policies,
and
so
that's.
This
centralized
kubernetes
management
team
needs
to
be
able
to
enforce
all
kinds
of
organization,
specific
policies
over
the
workloads
and
the
network
services
and
the
containers
and
all
of
those
things
that
are
running
on
top
of
kubernetes
now.
The
way
that
that
is
done
today
in
kubernetes
is
through
admission
control.
So
admission
control
is
basically
this
problem
of
deciding
whether
or
not
to
allow
resources
into
the
cluster
right.
A
When
they're
created
the
admission
controllers
run
and
they
decide
should
that
be
allowed
or
denied
as
well,
it
should
it
be
mutated
in
any
way.
Now,
the
thing
is
is
that
in
Mission
Control
policies
that
are
that
these
organizations
are
using
are
very
organization
specific
right.
So
a
common
example
is
that
you
want
to
set
up
a
whitelist
or
a
blacklist
of
the
container
image
registries
that
you
can
use
to
deploy
containers
with
write
that
image
registry
is
going
to
be
specific
to
your
organization.
You
know.
A
Another
common
example
is
that
you
want
to
restrict
the
host
names
that
ingress
objects
can
claim
right.
If
you
have
an
application,
that's
deployed
saying
a
development
environment
that
is
claiming
to
be.
You
know
payments
dot
like
you
know,
alibaba.com.
That
would
be
very
bad
right.
Suddenly
you
have
production
payment
traffic
going
to
like
a
developer's
installation
right.
So
there
are
all
these
very
sort
of
fine-grained
detailed
rules
that
need
to
be
enforced
in
these
clusters
in
order
to
maintain
compliance
with
regulation
and
avoid
to
avoid
outages
and
avoid
security
breaches
and
so
on.
A
So
that's
that's
admission
control
and
so
we've
been
working
on
this
problem
for
a
while
with
the
open
policy
agent
and
now
what
we're
starting
to
see
our
people
building
controllers
around
the
open
policy
agent
to
help
manage
policies
on
top
of
kubernetes.
So
the
kubernetes
policy
controller
is
basically
a
framework
and
a
service
to
help
you
create
manage
and
audit
cluster
state
against
policies.
So
you
can
write
policies
in
opus
policy
language
and
then
you
can
have
them
both
enforced
at
admission
time
as
well
as
audited
offline.
A
So
that's
particularly
important
because
you
know
the
policies
that
you
have
today
are
gonna
change,
and
so
tomorrow,
you're
gonna
have
new
policies
and
you
might
want
to
ask
the
question
what
workloads?
What
deployments
now
violate
the
new
policy
right?
What
existing
workloads
violate
that
policy?
Well,
how
do
you
do
that?
If
you've
implemented
all
of
your
admission
controllers
in
go
right
and
they
only
handle
like
incoming
admission
requests
or
incoming
requests
the
cluster
right?
You
want
to
be
able
to
ask
this
question
of
you
know
what
are
all
the?
A
What
are
all
the
policies
that
are
violated
or
what
are
all
the
ingress
objects
that
are
violating
a
particular
type
of
policy
or
what
are
all
the
violations
that
exist
within
a
particular
namespace?
So
you
want
to
build
that
both
enforce
policy
online
at
admission
time,
as
well
as
offline
as
part
of
an
audit
audit
capability.
A
Now,
in
addition
to
that,
it's
not
just
so
it's
not
just
allow
or
deny.
You
also
want
to
be
able
to
control
the
values
they're
being
I'm
specified
in
the
manifests
right.
So,
for
example,
you
might
want
to
say
that
all
workloads
need
to
have
a
product
owner
labeled
on
them
right.
You
might
want
to
say
that
this
come
this.
A
So
the
way
this
the
way
this
is
designed
is
that
you
know
you
have
the
standard
admission
control
web
hooks
in
the
kubernetes
api
server
and
those
call
out
to
the
kubernetes
policy
service,
which
basically
proxies
the
call
over
to
oppa.
And
then
we
have
another
component
called
Kubb
management
today,
which
is
responsible
for
replicating
kubernetes
state
into
OPA,
so
that
you
can
write
policy
over
like
context
right.
A
Right
in
order
to
do
that,
you
need
to
be
able
to
say:
okay,
I
have
an
incoming
ingress
object
and
I
have
an
existing
set
of
ingress
is
created
in
different
namespaces
and
I
need
to
search
over
them
to
see
if
there's
any
conflicts
right.
So
what
we
do
is
we
replicate.
You
can
configure
coop
management
to
replicate
state
from
the
API
server
into
OPA,
and
then
it
can.
It
can
use
that
when
it's
making
policy
decisions.
A
So
there's
an
initial
version
of
the
policy
controller.
That's
that
you
can
see
it's
under
the
is
your
organization,
kubernetes
policy,
controller
repository,
and
this
is
sort
of
the
initial
place
where
they
put
the
code.
The
plan
is
to
move
this
upstream
as
a
sub
project
of
cig
auth,
because
at
the
end
of
the
day
you
know
this.
This
belongs
in
Ennis
in
a
sort
of
central
place,
that's
owned
by
the
community.
A
There's
a
bunch
of
improvements
that
are
planned
like,
for
example,
allowing
you
to
basically
push
policies
into
the
system
via
CRD
having
a
kind
of
a
library
of
standard
policies
that
you
can
enable
very
easily
right.
Things
like
controlling.
You,
know,
ingress,
hostnames
and
container
registries
and
and
policies
over
persistent
volumes
and
so
on.
A
There's
a
lot
of
common
policies,
and
so
we
can
create
a
library
of
these
things
that
are
parameter,
eyes'll
and
and
easy
to
use
and
then
there's
some
work
plans
to
help
improve
how
policies
get
validated
and
how
conflicts
are
detected
and
so
on.
So,
if
you're
interested
in
these
sort
of
admission
control
policies
or
this
type
of
work,
I
recommend
that
you
check
out
the
the
repository
for
the
project
right
now
and
then
we
also
have
a
channel
on
the
open
policy
agents.
A
Lac
organization,
where
a
bunch
of
people
should
me
to
talk
about
this.
This
project
so
check
out
kubernetes
policy
on
the
open
policy
agent,
slack
org
that
might
move
to
the
Caracas.
That
would
move
to
the
kubernetes
slack
org
once
the
project
is
up
streamed,
but
that's
the
state
of
it
right
now.
So,
thank
you
very
much.
That's
that's!
All
I
have
our.
A
This
is
this
is
like
the
beginning
of
the
project.
It's
using
OPA
internally,
a
lot
there's
a
number
of
customers
that
are
using
open
it
or
you
end
users
that
are
running
open
today
for
this
problem.
But
this
is
sort
of
I
think
the
long
term
vision
is
to
have
this
integration
between
Kubb
management
and
OPA
and
and
other
things
like
audit
all
in
one
place,
that's
part
of
the
kubernetes
ecosystem.
A
A
B
A
You
well
so
I
think
that
I
mean
so.
This
is
just
focused
on
admission
control
types
of
policies.
Okay,
so
I
could
imagine
that
you
might
want
to
have
an
admission
control
policy
for
the
scheduling
policies
right
you
could
end
up.
Having
like
I
would
assume
that
you're
selecting
pods,
based
on
like
you're,
you
decide
which
scheduling
policy
to
apply
based
on
some
sort
of
label
selector
today,
and
so
you
know,
how
does
that?
How
do
you
check
that
people
are
applying
the
right
labels
right
in
order
to
get
scheduled
correctly?
A
That's
something
that
you
might
need
to
it
that
a
cluster
administrator
might
need
to
enforce.
I
would
imagine,
and
so
that
would
be
like
a
good
fit
for
this.
So
it's
not
replacing
that
in
any
way,
it's
not
replacing
Network
policy
or
our
back
or
anything
like
that.
It's
just
of
writing
a
way
to
apply
controls
over
those
things.
C
A
A
Great
question
so
like
this
is
an
example
of
an
admission
control
policy
written
with
OPA
right,
so
open,
I
I
can't
go
into
too
much
detail
right
now,
but
it
basically
gives
you
a
high-level
declarative
language
to
codify
policies
in
right.
So
this
is
an
example
of
an
admission
control
policy.
That's
searching
over
for
searching
for
ingress,
--is
and
then
deflecting
conflicts
right.
So
you
could
probably
express
some
of
that
scheduling
policy
in
here
or
you
could
load
it
into
here
and
interpret
it
yeah.
But
that's
yeah.
C
B
C
C
C
B
C
C
C
B
C
B
C
C
B
C
B
C
B
C
A
A
B
C
B
C
B
C
C
B
Matter
here
it's
the
scope,
issue,
foreign
policy
description.
I
will
describe
the
policy
for
some
poll,
you
can
use
OPA
and
it
has
its
own
set
of
language
or
description
describe
the
policy.
Basically,
there
are
various
kinds
of
ways
that
can
be
used
to
describe
the
policy
or
Jason
hall
often
would
do
the
job.