►
From YouTube: Network Policy API Meeting for 20230228
Description
Network Policy API Meeting for 20230228
A
Amazing:
okay,
everybody:
it
is
Tuesday
February,
28
2023..
This
is
a
meeting
of
the
Sig
Network
policy,
API.
Subject:
Network
we're
here
to
talk
about
Network
policy
and
all
their
fun
related
things
and
work
towards
a
better
future.
So
let's
follow
the
rules,
be
nice
to
each
other
and
let's
get
started
today
so
not
too
much
on
the
agenda
before
we
get
rumbling
a
kill,
I
think
you're
newer.
Here
you
want
to
just
give
a
quick
intro
for
everyone
in
the
group.
B
Yeah
sure
yeah
recently
started
contributing
to
various
like
kubernetes
networking
projects.
I
work
at
Google
on
the
data
plan,
V2
team-
that's
pretty
much.
It.
A
Sweet
thanks,
Akil
and
you
kind
of
lead
us
into
our
first
topic,
which
is
an
issue
you
opened
regarding
protocol
being
at
a
higher
level
than
ports.
So
yeah.
B
Yeah,
maybe
I
can
give
a
quick
summary
so
yeah
we
were
exploring
using
the
sort
of
traffic
selection,
components
of
admin,
Network
policy
for
like
a
completely
unrelated
use
case,
and
so
we
thought
that
was
a
good
place
to
start
and
that's
when
we
stumbled
across
this
particular
issue,
because
we
were
having
trouble
representing
like
traffic
selection
Behavior,
where
really
the
user
wants
to
define
a
rule
concerning
the
IP
protocol.
B
So
in
like
one
specific
example,
is
icmp
right
being
able
to
allow
or
deny
icmp
traffic
I
think
that's
a
bit
tricky
to
do
in
the
current
API,
because
sort
of
the
ports
is
sort
of
the
top
level
field
in
the
rule
and
protocol
is
a
sort
of
a
sub
field
of
port
number
or
I
think
Port
range,
and
so,
if
it
wasn't
obvious
how
you
would
represent
a
rule
such
as
you
know,
all
TCP,
Port,
80443
traffic
and
all
icmp
and
I
think
this
is
just
more
relevant
with
IPv6
adoption,
because
icmp
is
like
a
core
part
of
IPv6
and
I.
B
Think
it'll
become
like
increasingly
common
that
you'll
want
to
Define
rules
over
ipv
over
icmp
and
I.
Noticed
some
of
the
other
Network
policy,
implementations
or
network
policy
apis
already
have
custom
like
Behavior,
around
icmp,
they're,
icmp,
sort
of
a
top
level
field,
and
so
I'm
wondering
if
you
know
either
ISO
be
specifically
or
protocols
themselves,
should
have
more
like
I
guess
priority
in
some
sense
of
reports
like
whether
that
API
makes
sense.
D
I
added
a
comment
to
this,
but
right
as
the
meeting
was
starting
basically
like
kubernetes,
networking
is
only
concerned
with
TCP,
UDP
and
sctp,
and
nothing
else
is
is
really
well
defined.
D
D
So
so
this
is,
this
is
actually
a
bigger
question.
Then
then,
what
the
the
filer
said.
A
So
this
is
a
like
very
valid
use
case,
so
I
feel
like
especially
like
I
actually
had
someone
ask
me
about
this
a
week
or
two
ago,
so
it
was
perfect
timing,
Akil
Thanks,
for
opening
this.
Is
this
a
place
Dan
you
think
we
can
start
to
Define
that
in
terms
of
policy,
or
do
you
think,
because
we
don't
reference
icmp
explicitly
anywhere
else,
there
could
be
a
lot
of
cnis
who
are
like.
We
can't
do
this.
What
do
you
think.
D
So
there
will
certainly
be
Network
plugins
that
that
would
not
be
able
to
implement
the
things
that
we
come
up
with
here
about
icmp
or
other
lower
level
protocols,
which
might
mean
that
we
would
have
to
you
know,
figure
out
some
sort
of
status.
You
know
whatever
for
the
implementation
indicating
whether
or
not
it
could
Implement
that
feature
if
we're
going
to
add
it,
but
but
backing
up
you.
D
You
say
that
there
are
good
use
cases
for
this,
and,
if
that's
true,
why
were
they
not
in
the
document
so
so
I'm
I'm
going
to
push
back
on
that
the
facts
that
other
people
are
doing
it
does
not
necessarily
mean
that
that
there
are
good
use
cases
for
having
it
in
a
mid-network
policy
and
I'm,
not
saying
that
there
aren't,
but
what
we
should
come
up
with
what
the
use
cases
are
and
and
then
think
about
how
and
if
we
would
Implement
them.
A
Agreed
yeah
I
think
they
should
start
from
use
cases
if
anything,
it
was
just
never
kind
of
that
detail
was
never
brought
up
when
we
discussed
use
cases
explicitly
I
think
this
issue
is
kind
of
a
good
start
at
it
right
it's
less
of
a
use
case
more
of
a
problem,
but
I
definitely
think
it
is
a
problem.
E
I
think
I:
hey.
Can
you
hear
me
yep
I,
think
I
I
just
saw
a
kind
of
use
case
for
that
I.
Don't
know
too
many
details,
so
I
can
try
to
dig
into
that
a
bit
more,
but
the
there
is
a
customer
that
is
trying
to
do
the
health
checks,
I
guess
between
name
spaces
and
everything
else
should
be
denied
for
all
these
namespaces,
but
they
want
to
allow
a
CMP
only
because
that's
how
their
health
checks
work.
So
there
may
be
a
better
way
to
implement
that
I'm.
E
D
So
with
network
policy,
it's
totally
vague
what
happens
with
icmp
and
and
like
ARP
and
other
protocols.
When
you
have
a
network
policy
in
place,
I
don't
know
for
sure
what
ogan
kubernetes
does
I
know
that
in
openshift
sdn,
it's
like
totally
deranged
where
like.
If
you
create,
if
you
isolate
a
pod
and
then
say
that
another
pod
IP
can
access
it,
then
it
will
allow
icmp.
D
But
if
you
only
allow
access
on
a
particular
Port,
it
won't
allow
icmb
and-
and
that's
not
even
like
intentional-
it's
just
like
a
side
effect
of
these
rules
that
were
written
without
any
thought
for
how
you
know
what
we
should
be
doing
about
icmp,
so
we
should
probably
like,
or
we
should
definitely
have
clearer
rules
about
you
know,
should
this
is
do
we
even
if
we
don't
have
explicit
ways
for
adding
icmp
support?
We
should
say
whether
the
rules
are
expected
to
affect
icmp
or
not.
D
D
A
I
mean
it
depends
on
the
use
case
right
Nadia
like
for,
if
we're,
if
we
could
come
up
with
a
use
case
that
says
like
not
blocking
icmp
leads
to
a
really
insecure
scenario.
It
makes
sense
for
health
checking.
Is
that,
like
a
security
use
case
or
more
of
a
functionality
use
case
like?
Why
would
we
ever
want
to
I
guess
what
Dan's
trying
to
say
is
like?
Why
would
we
ever
want
to
block
health
checks?
A
E
A
I
think
in
the
immediate,
like
it's
an
important
point,
we're
missing
our
documentation.
We
should
have
a
note
somewhere
that
says
like
today.
We
we
ignore
icmp
like
and
for
the
implementers
like
icmp
should
always
be
allowed,
but
in
the
future
we
can
analyze
a
use
case
for
selecting
icmp
and
dropping
it
or
allowing
it
explicitly.
I
think
those
are
kind
of
the
two.
A
C
D
D
B
So
that
was
just
that
was
the
exact
use
case
that
we
ran
into
the
needs
frag
like
defining,
basically
allowing
those
specific
icmps
and
blocking
all
other
icmp
packets.
Those
are
specific
use.
B
There's
no
real
reason
why
we
want
the
Pod
to
be
able
to
probe
arbitrarily
by
any
other
client
in
the
network.
Maybe
we
need
to
dig
into
it
deeper
and
find
out
if
that's
really
a
risk,
but
just
our
initial
thoughts
were
block
unnecessary
icmp
types,
but
yeah.
A
I
mean:
could
it
be
a
risk?
This
is
a
totally
question.
A
question.
I
have
no
idea
about.
Maybe
someone
does
here.
Can
you
like
flood
an
interface
with
icmp,
Echo
requests
like
say,
you're
an
attacker
and
you
like,
spend
a
million
I.
Think
a
request
to
an
interface
like?
Are
you
going
to
overwhelm
the
system.
B
I
think
it's.
The
concern
is
more
around
some
icmp
packets.
You
expect
a
response
from
so
it
allows
you
to
maybe
saturate
the
link
or
even
probe
the
detection
of
a
pod
again,
maybe
on
a
local
network.
None
of
these
are
actual
risks,
so
I'll
have
to
like
investigate
more
it'll.
Just
start
initial
Instinct
was
hey,
we
probably
shouldn't
allow
it
but
yeah
it's
it's
worth
digging
into.
A
Cool
well
again,
thanks
for
opening
this
issue,
I
think
you
definitely
poked
a
hole
in
something
we
missed.
I.
Think
continuing.
The
conversation
on
this
issue
is
great,
but
then
also
like
turning
it
into
a
piece
of
documentation,
at
least
for
what
we
have
now
and
then
using
it
to
drive
any
further
use
cases
for,
like
our
our
V1
Alpha
2
discussion
would
be
the
way
to
go
Nadia.
E
G
E
F
A
I
think
a
good
starting
point
to
go
from
is
what
Dan
was
saying
like
we
should
we
shouldn't
any
undefined
Behavior
shouldn't
break
core
functionality
so
like
if
we
can
make
sure
that
we
Define
things
that
aren't
going
to
to
break
like
standard
functionality
of
the
data
plane
like
that,
would
be
great
or
have
some
note
in
the
docs
for
that,
because
we
definitely
don't
have
anything.
That's
a
really
good
point.
E
E
B
A
Their
their
things
are
going
to
function
for
their
use
case,
but
it'd
be
definitely
easier
if
we
could
divide
some
sort
of
catch-all
for
now,
but
yeah
so
I
think
okay
step,
one
is
just
Define
like
or
maybe
put
a
note
on
it
in
our
documentation
and
step.
Two
would
be
starting
to
look
at.
If
there's
use
cases,
we
can
bring
up
for
V1
Alpha
two
that
go
around
this.
E
A
A
H
Yeah
so
I'm
on
the
related
note,
you
know,
since
we
brought
up
this
issue
I'm
also
thinking
about
like
when
we
design
the
amp
did
we
did.
We
agree
on
the
use
case
where
you
know
we
wanted
to
define
the
rule
where
it's
between.
Maybe
you
know
up
one
sort
of
product
in
the
other,
and
we
only
wanted
to
allow
TCP
Connections
in
between
these
pods
rather
than
in
the
other
protocols
such
as
UDP
or
whatever
other
product
calls.
How
do
we
actually
Define
the
rule
like
that?
H
I
would
imagine
that
for
the
current
apis
as
Tim
suggested
at
some
point,
we
were
needed
to
use
a
poor
range
and
list
the
entire
TCP,
Port
Rich
out
explicitly
say
I
want
to
allow
these
as
the
entire
TCP
connections
and
then
have
a
denied
rule
which
says
everything
else
will
be
denied.
Is
that
how
it's
supposed
to
to
well
to
be
written
as
of
now
I'm?
Just
I
I
just
wondering
this,
because
I
mean
even
for
the
protocols
that
we
do
support
right
now.
G
H
So
sorry,
you
mean
no
policy
actually.
Does
it
no
right.
A
Right,
like
that's
what
I
was
going
to
say,
I
think
you
can
express
it
between
like
doing
a
default,
deny
all
Baseline
Advent
policy
with
the
port
range
in
the
admin
Network
policy.
You
could
do
something
like
that
right,
okay,.
A
Cool
okay:
the
next
thing
we
had
on
the
agenda
was
I
just
wanted
to
touch
base
on
this
PR,
because
it
is
really
important
thanks
for
opening
it
basically
for
anyone
who's.
Not
here,
we
didn't
have
a
generated
client
step
for
our
API,
so
it
was
hard
for
users
to
actually
interact
with
it.
So
Yang
kind
of
came
in
and
started
doing
that.
Do
you
need
any
help
here?
Yang
I
think
we
figured
out
the
verifier
and
then
I
had
like
one
comment,
but
otherwise
it
looked
good.
H
Yeah
I
I
still
need
to
look
at
this
because
I
I
didn't
see
it
yesterday.
So
yeah,
okay,
no
worries
bro.
It's
about
the
vendor
package
right.
F
H
It
was
a
little
bit
tricky
because
I
was
going
to
you
know,
write
descripts
without
the
vendor.
The
the
vendor
package,
but
I
do
saw
that
one
of
the
things
that
I
saw
I
think
it's
even
some
repository
inside
redhead
that
uses
you
know
the
the
vendor
directory
and
call
the
script
in
there,
because
you
know
the
general
group
script
was
so
well
written.
H
You
can
just
use
one
single
script
to
generate
everything
that
you
have
ever
needed,
whereas
if
you
put
in
things
like
in
the
make
file,
you
have
to
write
a
couple
of
them.
You
know
on
your
own,
so
I
just
thought
there
will
be
a
quick
hack
to
use
that
we
already
script
and
have
everything
generated
in
one
place
so,
but
I
can
definitely
change
it
to
the
other
way
around,
though.
A
No,
that
makes
sense,
I
I,
just
personally
don't
like
calling
a
script
in
the
vendor
directory
I'd,
rather
use
go
run
kind
of
like
manually
to
generate
the
client
set
informers
and
listers
like
individually.
So
then,
if
there's
a
problem,
it's
a
lot,
it
should
be
easier
to
debug
like
one
individual
step,
I
kind
of
got
this
from
the
Gateway
API,
so
I
I
didn't
know
a
lot
about
it
beforehand,
but
I
had
to
do
something
similar
recently.
So
no.
H
Worries
yeah
I'll
I'll,
see
if,
if
it's
it
should
be
pretty
straightforward
to
change
it
in
that
way
as
well,
and
hopefully
it
doesn't
really
affect
any
of
the
generator
codes.
It
should
not
ideally
right
yeah.
That
should
be
the
point
you
know.
A
And
the
only
other
thing
I
didn't
get
to
look
at.
Did
you
add
to
our
actions
or
to
our
CI,
like
a
verification
to
make
sure
that,
on
a
given
PR,
all
the
generated
code
is
correct?.
H
Yeah,
that's
a
good
point:
yeah
I
should
okay
yeah
I
should
I
should
I
think
there's
already
a
check
called
Jing
in
in
a
repo
right,
but
I
just
don't
know
if
it
actually
checks
for
the.
A
It
doesn't
check
it,
definitely
wouldn't
yeah.
There
is,
and
it
wouldn't
check
for
the
for
the
thing
that
I
added
right
for
the
client
set
and
foreign.
A
Sweet
that
would
be
awesome
and
if
you
go
to
that
link,
I
had
I
just
had
to
do
the
same
thing,
so
you
can
kind
of
see
there
and
if
you
need
more
examples,
check
out
the
Gateway
guy,
they
did
a
really
good
job.
Okay,.
H
A
Sweet
amazing
thanks
Yang,
that's
an
annoying
little
task,
but
it's
going
to
be
really
helpful
for
our
users.
I
have
kind
of
a
previous
note
on
that,
like
on
a
different
repo,
I
was
gonna.
Try
to
avoid
maintaining
client
sets
and
tell
it
just
telling
users
to
use
a
dynamic,
go
client,
a
dynamic
client
go
package,
but
that
was
kind
of
ugly,
so
I
think
doing
maintaining
clients.
That
is
the
right
call.
A
Cool
okay.
Lastly,
on
the
agenda
for
today
good
point:
Shane,
we
need
to
update
everything
to
the
new
kubernetes
image
repository
I
have
to
make
I,
don't
even
know
if
we
have
anything
pointing
to
the
old
one,
but
we'll
have
to
do
an
audit
on
that
for
sure.
G
F
G
A
A
No
worries
bear
how's,
it
going
okay
and
then
there
was
one
other
thing.
I
know:
Nadia
offline,
you
and
I
had
talked
about
another
issue
you
found
with
our
API.
Did
you
get
to
get
a
second
to
make
an
issue
for
that,
or
are
you
planning
on
doing
it
or
do
you
need
someone
else
to
do
it.
E
A
Amazing
cool,
okay:
does
anyone
have
anything
else
for
today,
I
think
we
have
some
good
action
items
thanks
again
a
kill
like
this
is
awesome.
This
is
what
we
need.
Are
there
any
updates
from
Yang
or
Syria
on,
like
implementations
or
just
chugging
right
along
there,
foreign.
C
H
Yeah
that
that's
actually
really
good
to
know
and
I
I
do
have
a
related
question
on
that
regard.
I
think
on
the
interior
side
we
are
also
trying
to
you
know,
implement
the
amp
and
that's
why
you
know
when
we
run
into
the
concept
problem
and
I.
H
Think
one
of
the
things
that
we
are
I
heard
that
we
are
actually
running
into
a
little
of
trouble
is
that
you
know
for
the
let's
say
the
not
self
or
the
not
same
labels
implementations
in
Nigeria,
because
in
in
amp,
obviously
we
decided
that
we
don't
want
the
the
MP
to
affect
North
sales
traffic
right
so
essentially
for
for
now
self,
when
we
select
some
sort
of
like
namespaces.
The
the
effective
semantics
of
that
selector
will
be
everything
in
the
cluster,
except
for
that
namespace.
H
So
in
I'm,
just
wondering
over
kubernetes
is
there
any
sort
of
like
difficulties
or
other
things
that
you
you
encountered
or
imagine
would
encounter
in
implementing
a
semantic
like
that
or
you
think
it
it's?
It
should
be
fine,
Urban
kubernetes.
C
C
So
the
Ingress
and
egress,
but
not
South,
is
not
yet
on
the
horizon.
So
let's
also
keep
in
sync
and
I
will
talk
more
when
we
start
with
that.
A
And
so
yeah
I
think
it
should
be
a
little
easy,
I
think
what
Yang
was
saying
like.
Is
it
going
to
be
easy
for
oven
kubernetes
to
implant?
Only
looking
at
East,
West
and
I
I
could
be
wrong,
serious
or
correct
me,
but
it
should
be
a
little
easier
because
once
traffic
enters
into
the
overlay
with
oven,
kubernetes
like
you're
in
the
overlay
like
you're
in
the
cluster
Network,
once
your
traffic
has
made
it
in
there,
and
so
it
should
be
easier
just
to
focus
on
East-West.
There
am
I
right
in
saying
that.
H
H
Let's
say
we're
enforcing
the
egress
rule,
I
think
in
entry
it's
a
little
bit
tricky
to
sort
of
like
knowledge
at
the
you
know,
beginning
or
the
egress
enforcement
level,
because
it
it
has
no
idea
on.
You
know
whether
this
corresponds
to
a
destination.
That's
on
another
node
or
it's
actually
cluster
external.
So
that's
I
think
the
the
the
thing
that
we
are
actually
running
into
a
little
bit
trouble.
A
H
Well,
for
for
local
I,
shouldn't,
say
local
environment
for
normal
use
cases,
yes,
but
not
on
public
clouds.
A
H
H
Okay,
no,
no,
no!
No,
the
the
the
I
it's
in
in
public
clouds.
You
know
in
in
the
the
mode
that
I
trade
actually
runs.
The
public
clouds
actually
manage
ipam
for
the
for
the
the
the
Pod
eyepiece.
So
what
what
the
ensure
runs
is
a
mode
that's
called
non-incap,
meaning
that
it
doesn't
really.
It
doesn't
really
do
the
ipam
and
everything
you
know
for
for
the
pods,
it's
just
a
cni
that
you
know
implements
connectivity
as
well
as
Network
policy.
H
So
so
when
so,
when
you
know
I
think
it's
even
it's
it's
more
like
a
idea
of
like
a
chain
cni
because,
let's
say
our
dks,
they
have
a
primary
uni,
which
does
you
know,
assigning
Paul,
IPS
and
stuff
so
and
Trail
Works
sort
of
like
hand
in
hand
with
it
and
where
we
let
the
eksc
and
I
do
their
thing
about.
H
You
know,
pause,
spin
up
and
tear
down
and
everything,
and
and
after
that
you
know,
we
ensure,
does
the
connectivity
and
now
policy
bits
so
so
right
now
we
don't
have
a
sort
of
like
good
way
to
communicate
with
eks
and
say
hey.
Can
you
just
give
me
the
you
know
entire
Plus
either
of
the
of
the
cluster,
so
that
we
can
do
a
couple
of
things?
H
We
don't
have
the
mechanism
like
that,
as
of
now
I
mean
that
that
that
can
be
one
solution
to
this,
but
this
going
to
be
tricky,
because
if
that
is
the
case,
I
would
I
remember
that
it
is
also
a
property
that
eks
users
or
the
public
Cloud
users
can
actually
config
right.
They
can.
They
can
sort
of
like
manually
change
the
Parts
either
they
wanted
to
assign
to
a
specific
cluster.
H
It's
on
in
their
own
VPC,
so
so
when
that
happens,
enter
or
other
cnis
may
need
it
to
sort
of
like
watch
for
those
changes
and
and
updates.
You
know
it's
it's
underlying
implementation.
You
say
hey
tools
right
now.
You
know
the
the
entire
cluster
doesn't
mean
this
either
anymore.
It
means
a
bigger
set
or
a
smaller
cider.
H
So
this
is
probably
a
route
that
we
didn't
really
want
to
go
into,
but
but
anyway
it's
it's
I
I
do
realize
it
can
be
implementation
specific,
definitely
because
if
we
are
using
some
sort
of
like
label
based
so
a
matching
for
Network
policy-
and
this
should
be
sort
of
like
a
little
bit
easier
because
you
can
just
look
for
a
specific
label
or
or
something
like
that
to
understand
hey.
This
is
coming
from.
H
D
So
so
one
of
the
arguments
for
for
having
the
you
know
only
applies
to
East
West,
not
to
North.
South
was
that
you
can
end
up
with
policies
that
do
the
same
thing
in
network
policy,
because
if
you
have
just
an
empty
namespace
selector
as
the
the
selector
of
a
policy
and
that
that
selects
all
pods.
So
is
that
also
difficult
for
you
to
implement
in
in
Andrea
or
no.
H
D
So
so
anyway,
that's
what
I'm
saying
like
that
was
part
of
the
argument.
Well,
they
already
have
field
to
do
it.
So
therefore
we
can
do
that
if,
if
it
turns
out
that,
like
you
know,
the
use
cases
are
different
enough
that
it
it's
okay
to
have
that
in
network
policy,
but
it
would
be
painful
to
have
an
admin,
Network
policy.
Then
then,
maybe
we
should
revisit
that.
H
Yeah,
that's
that's
what
I'm
trying
to
bring
this
up
and
see!
You
know
if
everywhere
else
encountered
this
problem,
because
because
I
see
per
head
a
hand
up
sorry,
oh.
F
No,
that's
like
it's.
The
same
I
mean
this.
We
discussed
multi-networking
before
right.
This
is
when
it
gets
really
really
iffy
with
multi-networking,
that's
really
to
to
understand
if
something
is
in
cluster
or
which
node
or
if
it's
leaving
that
that's
when
it
starts
to
it,
has
the
potentially
to
explode
and
become
really
really
expensive
to
to
do
the
filters
right.
H
Right
I
think
I
think
the
problem
is,
you
know,
I
I
agree
with
the
the
argument.
It's
just
that
you
know
when,
when
we
during
the
narrow
pass
implementation
to
the
Implement,
let's
say
the
namespace
selector
anti-career
presses,
which
is
probably
the
part
address,
is
in
there
and
it's
not
as
bad,
whereas
when
we
have
the
not
self
selector
now,
for
example,
let's
imagine
that
we
have
a
policy
that
selects
all
the
namespaces
right
and
say
for
each
namespaces
as
Computing
ourselves.
Now
the
problem
becomes
like
a
n
Square.
Worse.
F
That's
what
you
end
up
with,
or
you
have
to
build
your
policy
implementation
in
such
a
way
that
that
you
can
sort
of
by
following
the
routing
know
that
it
will
end
up
at
some
point
of
your
firewall
and
from
where
you
ended
up
can
can
draw
conclusions.
It's
it
has
the
possibility
to
become
really
really
expensive,
I
mean,
especially
if
you
do
I
mean
to
currently,
if
you
use
one
L2
that
can
connect
to
pods
on
every
node
and
even
on
stuff,
that's
outside
the
cluster
and
has
its
own
iPad
like
it's.
F
It's
going
to
be
challenging,
so
so
to
speak,
to
to
do
that,
it's
really
easy
to
write
the
policies.
Right,
I
mean
you
just
say:
label
set
in
reality
and
label
sets,
but
the
cost
to
implement
it
will
be
high
and.
F
G
H
I
I
don't
know
about
how
narrow
policy
actually
treats
that,
but
I
would
also
imagine
it
does
not.
You
know,
for
let's
say
if
we
select
a
Ingress
or
egress
peer,
it
would
not
actually
include
host
Network
pods.
If,
if
my
understanding
was
correct,.
D
H
D
H
Think
I
think
one
of
the
reason
is
that
you
know
for
for
the
IP
based
Solutions.
Obviously,
if
you
actually
include
the
host
Network
parts,
then
you
basically
just
put
the
node
IPS
into
the
Ingress
and
period
that
you
enforce
a
policy
on
and
it
it
really
makes
you
know
the
no
part,
traffic
and
stuff
like
that,
really
really
messy.
If
we
actually
include
the
host
Network
pausing
to
the
the
rules
and
it's
it's
not
really
correct
it
in
in
terms
of
traffic
enforcement
as
well.
H
So
because,
if
you
put
the
address
in
there,
it
affects
maybe
other
host
Network
pods
that
you're
that
doesn't
really
match
the
label
selectors
but
happen
to
share
the
same
address.
If
that
makes
sense,.
E
Yeah,
exactly
that's
how
kind
of
how
it
works.
You
know
when
kubernetes
also,
but
I
mean
that
means
that
admin
Network
policy
cannot
really
be
applied
to
host
Network,
Bots
and
I
would
say.
There
is
like
a
popular
request,
allow
qbps
to
report
something
like
that.
E
C
H
Yes,
I
think
I
think
that
the
reason
why
I'm
brought
really
in
this
up
isn't
that
you
know
we
can't
realize
this
like.
We
can't
implement
this.
It's
it's
just
not
going
to
be
efficient
if
I'm
making
sense,
because,
let's
say
if
we
have
a
cluster
with
a
hundred
namespaces
and
there
is
actually
a
amp
saying
that
for
each
of
these
namespaces
I
wanted
to
drop,
not
self
namespace
traffic
right.
So
by
the
end
of
the
day,
if
you
do
it
by
Brute
Force,
obviously
you
can
do
it
right.
H
You
just
have
a
rule
for
each
of
these
namespaces
and
put
all
other
namespaces
IPS
in
the
rule.
Saying
that
hey
I
want
to
drop
these
it.
We
would.
We
gotta
be
able
to
implement
that,
but
it's
going
to
be
really
really
not
efficient.
It's
not
going
to
scale
well
at
all,
so
so
it's
definitely
a
challenge
in
cnis
to
sort
of
like
find
a
way
to
implement
this
correctly,
I
would
say.
E
Yeah,
there
may
even
be
a
problem
with
the
physics
in
general,
because
you
basically
need
to
explicitly
ignore
everything
that
is
not
internal
destination.
Let's
say,
and
you
like,
when
you
open,
like
the
definition
of
internal
destination
changes
if
there
is
like
any
use
either
or
something
there
may
be
some
delay
in
updating
that,
especially
if,
like
Network
policy
managing
plugin
doesn't
know.
F
Anything
about
that
yeah,
the
the
brutal
truth
is
that
whenever
Anything
Grows,
especially,
we
have
a
lot
of
addresses
and
if
I
want
the
comparison
addresses
will
become
inefficient
and
the
more
things
you
have
a
change
just
to
keep
it
updated,
which
address
is
used
for
what
right.
So
as
long
as
we,
the
firewall,
basically
compare
if
two
I
mean
if
addresses
belongs
to
two
sets,
it's
going
to
be
very
inefficient.
The
larger
the
Clusters
we
go
I
mean
when
we
heard
numbers
from
Google
right,
15,
000
nodes.
E
Yeah
but
I'm
also
saying
so
now
for
Network
policy.
It
kind
of
should
ensure,
before
a
setting
pod,
to
ready
right
before
saying
that
the
networking
for
the
Pod
is
ready.
It
should
make
sure
that
all
deny
rules
for
Network
policy
are
set,
so
Paul
should
not
be
able
to
access
with
just
the
network.
Policy
definition
are
Paul
should
not
be
able
to
access
any
denied
resources
since
it
is
created,
and
then,
if
we
consider
like
pods
that
may
be
managed
by
something
that
else.
H
Well,
you
technically
can
right
like
because,
because
right
now
it
doesn't
really
require
you
to
have
a
narrow
policy
in
place
before
the
part
is
created.
You
can
technically
create
it
at
our
policy
that
applies
onto
the
part
10
minutes
after
the
Pod
is
up,
and
we
just
expect
you
know
the
cnis
to
take
whatever
delay
it
takes
to
actually
implement
the
network
policy,
maybe
in
like
0.01
seconds
or
something
and
then
boom
it.
It
comes
into
place
and.
E
Yeah
I
I
think
I'm
actually
about
to
add
docs
to
the
network
policy.
Saying
we've
discussed
that
with
Dan
that
actually
deny
rules
should
be
in
place,
so
in
general,
the
like
based
on
common
sense.
If
the
network
policy
is
applied
and
then
the
Pod
is
created
that
is
selected
by
the
network
policy,
it
shouldn't
be
able
to
access
any
denied
endpoints
at
any
point
of
its
life
cycle.
But
the
allow
rules
may
come
later.
F
But
I
mean
if
it's
an
existing
Network
policies
and
that's
the
threat
it's
like.
If
the
policy
is
created
or
I
mean
you
can
only
talk
about
this
set
of
policies
that
are
already
known
and
I
would
say
that
when
it
comes
to
anything
that
transforms
things
into
addresses
for
supplementation,
especially
on
the
sort
of
both
Egos
and
Ingress,
you
can
have
I
mean
the
number
of
PODS
that
can
you
can
access
or
you
can
be
accessed
by,
is
a
changing
set,
and
if
that's
changing
quick
enough
fast
enough,
you
will
never
no.
F
F
Wasn't
exactly
I
mean
the
way
this
is
done
to
have
stability
in
the
rules?
The
way
most
most
five
I
mean
how
most
implementations
are
done
when
both
the
the
source
and
destination
address
needs
to
be
known
and
mapped
at
the
source
pod
they
will,
if
a
large
system,
this
will
never
be
stable.
Basically,
you
need
to
have
a
distributed
firewall
to
to
have
this
table
so
that
it's
on
the
receiving
side,
that
the
final
check
is
done
and
you
would
need
we
need
to
build
implementations.
F
G
A
A
With
it
yeah
and
it
has
to
be
but
I,
think
we're
in
a
unique
position
to
kind
of
see,
what's
possible
and
then
create
like
a
continuous
feedback
loop
to
the
API
to
say.
Okay,
we
tried
this.
It
didn't
work
so
like
Yang.
If
you
could
just
take
the
problem
you're
running
in
tune,
maybe
throw
it
in
that
issue
just
so,
we
have.
It
documented
I
think
it
would
be
great
for
our
next
iteration,
so
yeah.
H
C
Also,
the
comment
from
Dan:
that's
on
the
chat
right
I'm,
going
to
try
to
get
a
bit
of
a
bit
of
that
one
of
the
plugin
have
a
rule
that
is
okay
to
get
confused
with
some
IPS
that
are
near,
even
if
they
aren't
really.
D
So
yeah
like
the
the
problem
here,
is
that
because
the
the
cloud
is
the
one
assigning
pod
IPS
and
so
the
network
plugin
doesn't
know
the
complete
set
of
ips
it
might
be
using.
But
it
knows
you
know
roughly
what
the
local
subnet
is,
and
so
we
could
just
say.
Okay,
you're
allowed
to
just
pretend
that
that
entire
subnet
consists
of
odd
IPS,
even
though
some
of
them
might
actually
be
node,
IPS
or
or
other
things
in
the
cloud
and
and
possibly
like.
That
would
end
up
working
as
an
implementation.
F
When
just
put
it,
because
that's
what
you're
asking
for
right,
you
take
a
destination
address
and
you
want
to
know
if
it's
should
be
considered
under
the
Ingress
and
egress
rule
towards
other
ports
and
not
sort
of
an
address.
That's
on
the
net,
so
it
would.
It
would
help
because
then
we
could
push
up
all
the
way
up
to
when
people
do
for
multi-networking
and
say
that
well,
you
need
to
put
put
the
classification
here
addresses
on
this
network.
Can
they
be
considerably
local
and
sort
of
backward
iPad.
F
C
A
Yeah
having
a
note
on
scenarios
where
the
cni
is
in
in
direct
control
of
the
Pod
subnet
or
doesn't
have
an
explicit
pod
subnet
like
I,
think
that's
really
important.
So
if
we
could
add
like
a
bit
to
that
issue
and
maybe
even
find
a
place
to
put
some
a
note
in
the
docs
I
think
that'd
be
a
good
start.
E
I
have
also
a
question
so
some
of
the
things
like
host
if
host
Network
pods
should
be
subject
to
network
policy
and
admin,
Network
policy
and
also
some
notes
about
the
protocol.
That
is
also
related
to
the
kubernetes
network
policy
we
have
now
so
do.
We
also
want
to
try
and
update
that
documentation
like
together
with
admin,
Network
policy.
A
You
mean
existing
documentation,
I
think,
there's,
there's
no
negative
to
that
right.
A
H
Yeah,
to
be
honest,
I
think
I
remember
a
while
ago,
when
somebody
opened
me
sure
saying
that
hey,
why
and
Chad
doesn't
actually
select
host
Network,
pods
I,
remember
what
the
dev
team
in
the
Android
did
was
actually
interestingly,
deploy
CDM
and
catacly
and
see
if
their
Network
policies
actually
select
host
Network
Parts,
just
to
verify
that
we
are
having
the
same
behavior.
So
so
I
guess
that
really,
you
know,
says
to
the
documentation
on
you
know
the
network
policy
API
documentation
doesn't
really
say
anything
about
that.
H
So
it's
it's
basically
up
to
the
implementations
and
I,
don't
and
I
don't
feel
like.
There
are
ET
test
cases
covering
those
two
yeah.
A
That's
another
thing:
I
was
thinking,
maybe
when
you
e2e's
test
case
to
prove
that
they
don't
today.
If
that's
what
we
put
in
the
docs
right
so
I
know,
openshift
doesn't
affect
host
Network
quads,
either
with
our
policy.
So
maybe
we're
all
doing
the
same
thing
just
by
pure.
It's
really
hard
to
implement
right.
E
A
E
E
D
E
A
Again,
if
we're
not
reporting
or
if
not
we're,
providing
a
mechanism
to
report
that
in
the
API
like,
is
it
our
role
to
Define
that
flow
in
the
API
I,
don't
know
I'm
a
little
confused
on
that.
F
B
A
Okay,
anything
else,
some
really
good
conversation
today,
thanks
everybody.
If
we
could
just
kind
of
update
the
issues
with
what
we've
talked
about
today
or
I,
know
specifically
around
the
explicit
protocol,
one
and
the
east
west
traffic,
one.
That
would
be
really
great.
C
The
east
west
traffic,
one
that
Yang
brought
up,
do
you
think
it
needs
a
new
issue.
The
other
one
seems
a
bit
more
wider.
Just
support
for
regress.
A
I
was
thinking
about
that
too
I'm
yeah
I
think
why
not
make
a
new
issue,
because
implementability
of
east
of
just
east
west
was
a
concern
in
the
cap,
so
I
think
it
wants
a
new
issue
if
that
works
for
you
Yang
yeah.
E
I
think
I
can
okay
go
ahead.
A
Amazing
cool
well
on
that
note,
a
really
great
conversation
today.
Thank
you
so
much
everyone
and
yeah
I'll
look
forward
to
seeing
some
of
the
updates
and
the
issues
and
we'll
just
keep
chugging
along
and
if
I
don't
see
you
soon,
I'll
see
you
in
two
weeks.
So
thanks
everyone
hope
you
have
a
really
good
day
and
we'll
talk
to
you
soon.
Bye.