►
Description
Speakers: Surya Seetharaman and Andrew Stoycos
Although the NetworkPolicy API allows developers to secure applications, admins have been forced to use out-of-tree APIs to secure clusters. This is evident by the large number of disparate CRDs offered by CNI plugins, such as Cilium’s ClusterWideNetworkPolicy and Calico’s GlobalNetworkPolicy. The SIG Network Policy API subgroup believes that such functionality should be provided by the core Kubernetes community to make cross-vendor portability possible and provide a standard solution for plugins which do not already implement such an API. The AdminNetworkPolicy API, written by a diverse group of community members and designed to specifically meet the needs of the cluster admin, is this solution. To date it has undergone two years of active development and over 800 (and counting) GitHub review comments, highlighting both the challenges and benefits of open source API development. This session will present the new API to the wider community and teach best practices regarding its use. Such learnings will enable the community to quickly adopt the AdminNetworkPolicy API and ensure future iterations include ideas from users throughout the Kubernetes ecosystem.
A
A
Yeah,
so
let's
go
over
what
we're
going
to
see
today
so
for
folks
who
don't
know
the
admin
Network
policy
API
is
a
brand
new
API
out
of
the
Sig
Network
policy,
API
subgroup
to
Sig
Network,
it's
a
mouthful,
but
this
is
what
we're
going
to
go
over
today:
kind
of
the
back
story
to
what
led
up
to
us
working
to
create
a
new
API,
the
user
stories
for
the
new
API,
what
the
API
implementation
actually
looks
like
and
then
what's
next.
So
what's
coming
next
for
this
API
and
the
group
that's
working
on
it.
A
Awesome,
so
this
is
what
we
started
with
like.
This
is
a
not
a
super
new
problem
statement.
Admins
have
needed
to
apply
Network
policy
at
a
cluster
scope
for
a
long
time.
Okay
and
they've
had
no
built-in
tooling
to
do
so.
So
what
did
admins
have
for
policy
tools
that
were
built
into
kubernetes?
Well,
most
of
us
know
about
Network
policy,
but
Network
policy
was
not
designed
for
the
admin
right.
A
A
So
the
next
question
right
we
said
we
needed
policy
applied
to
a
cluster
as
a
whole,
so
why
don't
we
just
go
and
make
Network
policy?
Cluster
scoped
it'd
be
pretty
easy
to
take
the
network
policy
API
and
add
a
namespace
selector
and
say
that
you
can
apply
it
to
all
namespaces,
but
there's
a
few
reason.
We
a
few
reasons
we
didn't
do
that.
Okay,
so
Network
policy,
the
existing
API
is
a
pretty
old
API
and
it
makes
some
assumptions
that
we
aren't
super
wild
about
for
admins,
specifically
one
of
the
major
ones
is.
A
Another
problem
with
network
policy
is
it's
just
additive,
so
you
can
make
multiple
Network
policies
and
and
they're.
Just
the
behavior
is
additive.
There
aren't
any
explicit
actions
or
priorities,
and
then
one
of
the
last
ones
is.
This
is
a
hotly
debated
topic.
Ip
block
is
how
we
select
north-south
traffic
with
network
policy.
It
was
added
after
the
original
spec
was
designed.
I
believe
and
folks
have
a
problem
with
that,
because
when
we
are
talking
about
Ingress
mechanisms,
pre
and
post
Snap
becomes
kind
of
an
issue.
A
So
these
are
some
of
the
reasons
we
decided
to
leave
the
network
policy
API
behind
and
kind
of
Forge
ahead,
creating
a
new
API
for
admins,
and
why
should
we
care,
I
mean
Surya
and
I?
Both
have
talked
to
customers
where
they
have
to
create
hundreds
of
identical
policies
across
their
cluster?
It's
it's
really
laborious.
It's
a
real
big
pain
and
another
show
that
goes
to
goes
to
show
how
important
this
is
is
a
lot
of
Downstream
implications,
have
their
own
versions
here:
I've
labeled,
three
Andreas,
psylliums
and
calcas.
A
B
Thank
you,
Andrew
yeah.
So
let's
look
at
some
of
the
user
stories
that
we
had
in
mind
when
we
designed
admin,
Network
policy,
the
cap
and
maybe
looking
at
these-
will
give
us
the
motivation
behind
why
ANP
was
designed
to
the
way
it
is,
and
it
can
help
you
know
the
when,
where
how
to
use
the
ANP
in
you
know
real
life
scenarios,
the
first
story,
we're
going
to
look
at
is
being
able
to
deny
traffic
on
a
cluster-wide
level.
B
So
maybe,
as
a
cluster
administrator,
you
want
to
be
able
to
say
that
I
don't
want
certain
set
of
PODS
or
namespaces
to
be
able
to.
You
know
talk
with
any
other
namespace
and
you
want
to
enforce
this
on
a
cluster
scope
level.
Network
policies
allow
you
to
do
this
on
a
more
namespace
level
or
on
a
more
application,
developer,
10
and
twice
level,
but
as
an
admin,
you
want
to
be
able
to
Define
these
rules
in
a
way
that
are
not
being
overridden
by
other
tenant
owners
or
app
developer
in
the
cluster.
B
The
second
is
a
story
that
we
have
is
the
opposite
of
the
deny
case,
which
is
the
allow
case
you
want
to
be
able
to,
for
example,
say
the
metric
spots
that
are
in
your
monitoring
namespace.
They
should
be
able
to
scrape
every
namespace
in
the
cluster
to
know
its
health
and
the
the
owners
of
those
namespaces
should
not
be
able
to
deny
the
sort
of
traffic.
B
So
you
want
an
ANP
rule
to
be
enforced
on
a
more
higher
priority
level
that
says
hey
this
traffic
should
always
be
allowed
and
I
don't
give
the
right
to
anybody
else
in
the
cluster
to
be
able
to
override
these
same
with,
for
example,
Ingress
traffic
towards
the
cube
DNS,
which
should
always
be
allowed
right.
So
nobody
should
be
able
to
override
these,
and
you
know,
ANP
again
gives
you
a
way
to
define
these
allow
rules
in
a
very
easy
way.
B
The
third
user
story
is
actually
a
very
interesting
one
and
it's
a
bit
different
from
the
allow
and
the
deny
that
you
probably
have
seen
before
it's
a
way
for
admins
to
be
able
to
delegate
or
Grant
some
amount
of
power
to
the
developers
in
the
cluster.
So
they
can
Define
rules
that
say
Hey
if
the
traffic
is
matching
the
specific
full
namespace
or
it's
an
Ingress
traffic
coming
from
a
specific
set
of
pods
in
the
full
name,
space
I
don't
want
to
do
anything
about
it.
B
I
just
want
to
delegate
this
to
the
network
policies
that
are
defined
for
that
namespace.
So
it's
a
way
for
admins
to
say,
I'm
going
to
skip
all
the
ANP
rules.
No
A
and
P
will
be
evaluated,
we'll
straight
go
to
all
the
NP
rules
that
are
defined
for
the
namespace,
like
as
an
admin.
You
may
not
be
aware
of
all
the
details
of
a
specific
application,
and
maybe
in
that
case
you
just
want
the
developers
to
set
up
the
policies
or
enforce
security
rules.
A
B
The
fourth
user
story
is
a
common
one,
which
is
done
in
isolation.
A
tenant
here
could
mean
either
a
single
namespace
or
a
group
of
namespaces,
but
essentially
you
want
a
way
to
be
able
to
say
that
this
tenant
should
not
be
able
to
talk
to
that
tenant
or
no
tenants
should
be
able
to
talk
to
each
other
should
only
be
explicitly
allowed
based
on
the
tenants
defining
rules
themselves.
B
So
we
saw
the
first
user
story,
which
is
the
deny,
so
we
can
use
the
same
set
of
rules
to
actually
also
deny
traffic
between
tenants
so
and
the
final
user
story
that
I'm
going
to
talk
about
is
being
able
to
deny
traffic
on
a
cluster-wide
level
in
the
sense
that
you
want
to
secure
your
entire
cluster.
You
want
to
have
a
basic
default,
deny
policy
on
your
cluster
and
then
be
able
to
see
that
no
part
should
be
able
to
talk
to
any
other
part
in
the
cluster
or
no
name.
B
Space
should
be
able
to
talk
to
any
other
namespace
in
the
cluster
unless
explicitly
Allowed
by
the
network
policies
or
admin
Network
policies,
for
example.
So
you
want
to
have
a
way
of
saying
I'm,
doing
I'm,
denying
everything
I'm
protecting
my
entire
cluster
and
then,
if
you
want
to
allow
anything
on
top
of
it,
please
just
go
and
Define
those
explicit
allow
roles
with
a
higher
priority
than
your
denial
over
here.
So
so
these
are
some
of
these
stories
that
we
had
in
mind.
A
Yeah
keep
those
in
mind
because
they're
going
to
be
really
important,
we're
going
to
see
some
yamls
for
this,
so
these
are
kind
of
two
principles
we
started
with
with
admin,
art
policy
and
it's
key
it's
important
to
keep
in
mind.
So
the
admin
Network
policy
API
we
designed
it
to
be
extremely
extremely
readable
and
explicit.
Okay,
there
is
no
implicit
Behavior
as
with
network
policy
and
for
V1
Alpha
One
of
this
API
we're
also
focusing
only
on
East-West
traffic
and
we
hope
to
address
the
north-south
traffic
use
case
in
a
further
release.
A
A
Awesome
so
we
implemented
the
user
stories.
We
already
talked
about
with
two
new
objects
that
they
are,
what
we
call
the
admin
Network
policy
API.
Those
objects
are
the
admin,
Network
policy
object
and
the
this
object
is
used
to
define
rules
which
are
not
cannot
be
overridden
by
developers
I.E.
They
cannot
be
overridden
by
Network
policy.
The
other
object
is
the
Baseline
admin
Network
policy
object,
which
was
used
to
specifically
satisfy
use
case
5,
where
we
want
to
flip
the
use.
A
The
default
stance
of
the
cluster
from
allow
all
to
deny
all,
and
these
can
be
overridden
by
developers
using
network
policies
and
the
things
we
just
want
to
constantly
remind
throughout
this
talk
is
our
Persona
okay,
so
admin
Network
policies
and
Baseline
Network
policies
are
defined
explicitly
for
the
system
admin,
while
Network
policies.
Remember,
are
always
for
the
developer
to
use
awesome.
So
let's
talk
about
some
explicit
parts
of
the
new
admin,
Network
policy,
API
specific
to
admin,
Network
policy
objects.
A
A
Is
this
brand
new
sparkly
action
that
there's
not
really
any
precedence
for
it,
and
this
is
what
allows
us
to
essentially
delegate
traffic
enforcement
explicitly
to
application
developers
and
that
basically
allows
us
to
solve
use
case
three
which
we'll
see
again
later
on
in
these
slides,
some
other
really
great
design,
teal
details
that
came
out
of
the
development
of
this
API,
where
we
added
priorities
so
pretty
simple
here
most
cluster
admins
are
used
to
setting
up
firewalls
with
traditional
ACLS.
Most
of
those
ACLS
have
priorities,
so
we
added
it
here.
It
just
made
sense.
A
So
the
next
thing
we
have
in
the
API
are
our
standard,
Ingress
and
egress
rules.
We
know
those
from
Network
policy.
Thankfully,
however,
nowadays
in
each
Ingress
and
egress
rule
you
must
Define
at
least
one
and
at
least
in
action.
So
then
there's
no
defaulted,
unknown
behavior.
That
can
happen
if
you
mess
up
your
yaml
or
if
you
do
something
else
like
something
else
wrong.
We've
also
added
a
name
field
to
these
Ingress
and
egress
rules.
A
So
that's
just
so:
admins
can
in
the
future,
share
rules
with
other
users,
and
hopefully
our
developer
tooling
can
make
use
of
them
as
well.
The
last
thing
we've
added
for
this
API
is
a
status
field
for
V1
Alpha
One,
it's
just
a
list
of
conditions,
but
in
the
future,
based
on
what
implementations
do
we
might
fix
these
conditions
to
a
certain?
You
know.
B
Yeah,
so
we
looked
at
the
previous
user
stories
that
I
was
talking
about
when
ANP
was
designed.
So
let's
look
at
how
an
adminator
policy
rule
would
actually
look
like
for
each
of
those
use
cases
and
keep
in
mind
that
these
were
just
the
basic
use
cases
that
we
had
that
we
had
in
mind
when
the
API
was
designed.
B
But
if
you
have
more
resistories
that
you'd
like
to
see
or
more
use
cases
for
ANP,
please
do
reach
out
to
us
and
we'll
try
to
include
them
as
well
when
we
do
the
V1
Alpha
2
version
of
it.
So
the
first
story
that
we
saw
at
was
how
to
deny
traffic
on
a
cluster-wide
level
as
an
admin,
and
we
saw
we
took
an
example
here
of
a
security,
sensitive
namespace
and
you
want
to
deny
traffic
from
any
other
namespace
into
it.
B
This
is
all
this
is
how
a
typical
object,
A
and
P
object
would
look
like
the
yaml
would
look
like
and
get
you
can
see.
The
kind
being
admin
Network
policy
and
Andrew
spoke
about
priorities,
so
you
can
set
priorities
for
each
of
the
objects
and
all
the
rules
that
get
defined
inside
this
object
will
share
the
same
priority.
So
you
have
to
be
careful
what
roles
you
define
inside
it
because
the
when
they
are
of
same
priority
they
get
evaluated
with
the
same.
You
know,
you
know
they
are
evaluated
at
the
same
level.
B
So
here
in
this
case,
you
can
see
that
the
subject
is
something
that
you
apply.
The
the
object
on
that
is
the
ANP
rules
that
are
defined
in
this
object
would
be
applied
on
the
subject
which
is
defined
here.
A
subject
in
this
case
is
just
a
pure,
so
it
can
be
a
namespace.
It
can
be
a
part.
It
can
be
some
set
of
set
of
PODS
inside
a
namespace
any
of
those.
So
here,
in
our
case,
the
subject
is
the
sensitive
namespace
that
we
care
about
and
that's
selected
using
match
labels.
B
You
know
fundamental,
we
see
it
in
a
lot
of
objects
in
kubernetes
and
we
Define
an
Ingress
rule
here
that
says
I
want
to
drop
any
traffic.
That's
coming
towards
the
sensitive
namespace
from
any
other
namespace
in
the
cluster
and
that's
defined
using
namespace
selectors
and
we
leave
it
as
empty
and
empty
means
all
namespaces
get
selected
by
default,
and
the
second
user
story
that
we
saw,
which
was
the
opposite
of
the
deny.
B
The
allow
case
is,
in
this
case
it's
a
bit
special
because
you
can
also
you
can
have
different
ways
to
express
this
right.
So
in
our
case
we
have
taken
the
subject
to
be
all
namespaces
in
the
cluster.
So
this
is
the
one
way
that
admins
can
say
that
every
namespace
in
the
cluster
should
always
be
able
to
accept
traffic.
That's
coming
from
the
monitor,
namespace
or
every
namespace
in
the
cluster
should
be
able
to
send
traffic
to
the
qdns
namespace.
B
You
could
have
made
the
monitoring
namespace
or
the
qbns
namespace
as
your
subject
here,
but
that
would
mean
that
you
lose
the
fine
control
over
defining
what
other
name
spaces
can
do.
So,
in
our
case,
we
want
all
the
all
the
other
namespaces
to
behave
this.
The
way
we
want
it
to
right,
so
a
tenant
owner
or
an
application
owner
or
an
a
full
namespace
administrator
in
this
case
should
not
be
able
to
say:
hey,
I,
don't
want
any
traffic
coming
in
from
the
monitoring
namespace.
B
They
cannot
say
that,
because
you
have
an
amp
rule
here
that
defines
that
you
are
supposed
to
accept
traffic
coming
from
the
monitoring
namespace
and
that's
the
whole
Guru
here.
So
you
can
see
this
subject.
Here
is
all
the
name
spaces
and
we
have
an
Ingress
Rule
and
an
egress
rule
that
both
allow
traffic
from
their
respective
namespaces.
So
it's
the
Ingress,
is
allowed
from
the
monitoring
namespace
and
the
egress
towards
Cube
system.
B
B
The
third
user
story,
which
is
a
special
one
which,
where
ANP
interacts
with
NP
in
some
sense,
is
where
you
have
admins
delegating
the
power
to
the
actual
app
developers
or
the
namespace
owners
in
this
case.
So
here
you
have
traffic
coming
from
the
full
namespace
going
towards
the
bar
namespace,
with
pods
that
are
labeled
with
SVC
Pub
as
the
as
the
match
label
here
and
at
layer
four.
You
want
to
specify
TCP
and
the
port,
the
protocol
and
the
port
to
be
able
to
be
matched
on
that
level.
B
So
we
want
to
say
that
anything
that
matches
this
don't
evaluate.
Anp
rules
instead
go
straight
to
the
NP
rules.
So
it's
a
way
for
you
to
essentially
skip
evaluating
the
rules
on
an
admin
Network
policy
level
and
for
you
to
just
go
over
to
the
controlled
rules
that
are
defined
for
the
network
policies
by
the
developers.
So
here
there
is
some
sort
of
control
that
is
given
to
the
namespace
owners,
which
is
good
because
maybe
the
admins
don't
don't
know
what
to
do
with
this
kind
of
traffic.
A
Yeah
and
another
really
small
thing
to
note
here
that
didn't
make
it
into
the
slides,
is
we've
totally
redesigned
the
port
selector?
As
you
can
see
here
we
have
a
ports
array
and
then
a
port
number
entry.
We
also
have
Port
name
and
Port
range
entries.
It's
just
a
little
more
explicit
than
it
works
with
the
network
policy.
Existing
ports
so
go
check
that
out.
B
And
the
fourth
story
was
about
tenant
isolation,
and
here
we
are
actually
displaying
a
special
API
change
here,
which
is
not
their
end
piece.
So
in
ANP
we
have
a
way
to
select
peers
based
on
labels,
so
you
have
not
same
labels
that
we're
defining
here.
So
let's
say
that
we
have
two
tenants,
Foo
and
bar,
and
each
of
these
tenants
have
labels
with
the
key
tenant
and
the
value
can
either
be
four
bar
respectively
and
we
have
match
Expressions
that
select
all
the
tenants
using
the
key
value
tenants.
B
So
if
that
exists,
then
all
the
name
spaces
which
belong
to
those
tenants
get
selected,
and
then
you
want
to
apply
an
Ingress
rule
that
says
deny
traffic
or
drop
traffic.
That's
coming
from
other
tenants.
So
in
this
case
what
we
have
is
a
not
same
label.
So
what
it
essentially
does
is.
It
goes
over
all
the
namespaces,
it
checks
for
the
labels,
and
then
it
sees
if
the
value
of
the
label
with
the
key
tenant
is
the
same
as
what
is
defined
for
the
subject.
B
So,
in
our
case
let's
say
the
subject
is
10
and
Foo
that
that
gets
selected
and
it
has
it.
It's
a
has:
a
label
with
the
key
tenant
and
the
value
Foo.
But
then
now,
when
you
evaluate
the
Ingress
rule
over
here,
we
are
saying:
don't
allow
traffic
unless
it's
from
tenant
Foo.
So
if
it's
tenant
bar
or
near
the
tenant,
we
don't
allow
so.
A
B
And
the
final
story
that
we
had
in
mind,
which
was
for
the
Baseline
at
the
network
policies
that
Andrew
talked
about
it's
the
the
banp,
is
the
last
to
get
evaluated.
So
first,
you
have
the
ANP
and
then
the
network
policies,
and
then
the
banp,
and
here
when
you
say
that
you
don't
want
any
part
to
talk
to
be
able
to
talk
to
each
other
or
any
namespace.
For
that
matter,
you
can
just
say,
select
all
namespaces
and
then
have
this
Baseline
rule
that
says:
I
am
denying
traffic
on
an
intra
cluster
level.
B
No
East-West
traffic
is
allowed
with
each
other
unless
you
are
defining
allow
rules
on
top
of
it.
So
as
you
can
notice,
there
is
no
priority
for
Baseline
admin,
Network
policy,
and
we
don't
expect
too
many
objects
or
rules
under
this
constraint.
For
example
like
this
is
one
of
the
main
use
cases
that
we
have
where
you
want
to
be
able
to
do
a
default
and
I,
and
you
can
see
that
the
Ingress
action
here
would
be
a
drop
and
the
from
is
any
other
namespace
right
in
the
whole
cluster.
So.
A
Yeah
awesome:
okay,
thanks
Surya!
So
what
comes
next?
We
talked
about
this
really
new
fun.
Api.
A
lot
of
work
went
into
this,
so
thanks
to
everyone
in
the
community
that
helped
along
the
way
today,
right
now,
you
can't
try
this
out.
There
are
no
implementations,
it's
you
know.
We
need
folks
like
you
to
come
in
and
start
writing
implementations,
but
let's
kind
of
look
at
what
our
next
plans
are
as
part
of
this
API
we
really
in
the
cap
and
in
other
places,
talked
about
developer
tooling.
Over
and
over
and
over
again.
A
A
We
are
also
fostering
implementation
so
far.
Red
Hat,
VMware
and
Google
all
have
kind
of
bought
in,
and
that's
for,
Andrea,
oven,
kubernetes
and
psyllium,
and
then
we
also
have
future
plans
to
add
more
features
to
this
API
and
specifically,
north-south
traffic
control,
I'm
sure
that
one's
going
to
come
up
and
we're
going
to
have
to
redesign
IP
block.
So
we
need
help.
We
need
opinions,
we're
really
excited
about
it
and
ready
to
get
the
ball
rolling.
A
This
is
a
QR
code
for
our
website.
Everything
you've
seen
here
today
is
pretty
much
mirrored
on
our
website
and
I
will
share
these
slides
out.
As
I
said,
we
need
help
so
come
get
involved,
come
get
involved
in
our
repo
and
yeah
thanks
so
much
for
coming
today
and
love
to
take
some
questions.
The
time
we
have
left.
C
Hi
so
I'm
just
looking
at
this-
and
this
looks
really
exciting
and
also
seems
to
overlap
substantially
with
our
needs
in
the
Gateway
API
mesh
working
group
for
East-West
service
authorization
policy,
so
yeah
definitely
just
interested
in
working
and
kind
of
connecting
with
you
on
this
to
see.
If
we
can
like
address
a
shared
need
with
this,
because
this
looks
really
cool.
So
thanks
yeah.