►
From YouTube: Network Policy API Meeting 20210209
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Cloud
hi
everybody.
This
is
network
policy,
subproject
working
group.
What
whatever
2021
february
8th-
and
I
got
to
do
the
introduction
today-
so
please,
please
be
very
nice
to
one
another.
This
is
an
official
cncf
call,
so
let's
all
be
nice
to
each
other,
and
I'm
very
excited
that
I
think
according
to
matt
fenwick,
we
may
have
our
first
ever
in
the
history
of
this
group
demonstrating
demonstration
today.
A
But
let
me
see
what
else
is
on
the
agenda.
First
and
I'll
share
my
screen.
B
Why
why
would
you
do
that
jay?
Do
we
have
anyone
attending
as
the
first
meeting
today,
anyone.
C
A
D
Maybe
I
can
do
a
quick
high
on
behalf
of
or
rather
poke,
erika
and
and
how
so
that
they
can,
you
know,
say
something
about
themselves,
but
they
are
part
of
our
team
and
they
are
also
interested
in
what
matt
is
going
to
be
demoing
today
and
we
hope
to
collaborate
with
matt
to
extend
the
tool
to
future
use
cases
as
well
and
include
more
features.
So
eric
now,
do
you
want
to
say
hi.
C
Hi
everyone,
this
is
erica
from
vmware.
I
work
with
every
shack,
and
this
is
my
first
time
joining
this
meeting.
E
F
A
A
D
You
think
we
should
do
do
you
think
we
need
to
update
that
that
kept
because
the
freezers
tomorrow-
and
I
think,
does
that
affect
our
status
for
the
namespace
selector
by
name.
Okay,.
A
I
think
everything
is
yeah.
Everything
is
like
hardcoded
in
there
for
20
21
22
right
yeah.
I
think
we
should
just
move
it
to
the
next
release.
Honestly,
I
I
think
that's
the
best
thing
to
do.
A
A
B
Last
time
I
was
snaploss
hierarchy,
I
was
just
like
surviving.
I
guess
I
guess
you
can
you
can
you
can?
Probably,
if
you
think
that's
that's
something
you
you,
you
should
bring
david
ads
in
in
his
life,
he's
pretty
responsive
in
his
life,
just
to
say
hey
what
about
this
one,
because
today
is
called
freeze,
but
I
think
also
he
is
crowded
with
all
of
the.
B
B
A
B
New
folks
yeah,
so
mine
is
merged,
and
now
and
and
also
that
abhishek
is
reviewing
carlos
pr
from
from
the
follow-up
that
that
that
jay
and
and
abhishek
left
about
the
port,
the
maximum
part.
I
I
I
am
honestly
I'm
not
following
the
follow-up,
but
if
you
need
me
to
follow
that,
I
can.
I
can
take
a
look-
and
I
was
talking
with
this
catechol
folks-
about
getting
that
inside
the
calico
code.
But
we
still
need
to
wait
for
the
release
right.
B
I
don't
know
how
how
andrea
folks
are
doing
this,
but
because
they
they
vendor
the
the
the
client
goal
and
other
stuffs
and
in
a
final
release.
You
know
in
a
in
a
stable
release,
probably
we
we.
We
still
have
to
wait
until
v121
before
getting
that
merged
into
calico
code.
So
I
don't
know
if
there's
something
else
to
do.
D
Yeah,
we
are,
I
think,
going
to
be
prepared
with
a
change,
but
I
think
you
know
it
will
be
merged.
Only
after
1.21
is
out
sometime
in
april,
but
at
least
we'll
start
testing
it
with
the
release
candidates
as
soon
as
they're
out
wait,
they
merged
my
cap.
B
A
A
A
D
Yeah,
so
just
a
quick
update,
I
think
most
of
you
guys
were
present
on
most
of
you
all
were
present
on
the
thursday
sig
network,
call
where
we
presented
part
two
for
the
cluster
network
policy,
and
this
time
we
came
up
with
you
know,
alternate
proposals
based
on
the
feedback
that
we
were
getting
on,
the
the
presentation
and
the
slide
deck
that
we,
you
know
put
up
the
link
for,
and
so
it
seems
you
know,
being
explicit
and
in
in
terms
of
the
meanings
for
fields
is
the
most
agreed
upon
way
to
move
forward,
and
so
we
we,
this
week,
we
plan
to
converge
upon
a
primary
proposal
based
on
the
alternates
and
open
up
a
cap
for
the
next
cycle.
F
A
H
Yeah
they
say
yeah,
so
I
think
so.
Last
time
we
discussed
about
the
proposal
and
we
fairly
like
simplified
the
scope
of
this.
I
think
cap,
because
there
are
a
lot
of
use
cases
that
can
be
you
know,
solved
or
like
that
can
be
covered.
You
are
using
this
proposal
like
as
a
when
I
say
proposal
the
term
service
selector
can
be
meant
for
different
use
cases,
but
I
think
we
paidly
simplified.
I
mean
we
reduce
the
scope
of
it
to
like
have
or
like
support.
I
Or
I
think
we
so
we
need
to
start
creating
documents,
not
using
google
accounts
so
that
it
becomes
easier
to
share
it.
I
So
you
have
a
public
private
email
id
right
that
you
use
for
github
for
your
source
code
contribution
use
that
account
if
possible.
So
this
is
a
comment
that
we
keep
running
it
all
the
time.
So,
let's
not
create
documentation.
A
I
H
Yeah,
so
I
think
so
we
had
like
a
couple
of
alternators
for
like
how
the
like,
where
the
field
should
be
introduced
in
the
the
net
policies
spec.
So
I
think
a
lot
I
mean
the
folks
from
this
group
has
provided
a
lot
of
feedback
in
the
last
presentation.
So
so
I
was
actually.
H
I
was
actually
looking
for
more
feedback
I
mean
or
like
which
way
is
better
than
the
other,
so
that
I
mean
also
like
this
being
my
first
step,
I'm
actually
looking
for
next
steps
like
trying
to
fit
like
where
we
should
go
from
the
discussion
that
we
had
before
like
in
the
last
meeting.
So
should
we
look
to
have
like
more
examples
and
use
cases
so
that
we
certify
the
the
proposal
or
or
do
we
should?
H
We
have
like
more
internal
descriptions
in
this
group,
or
should
we
go
to
networking
group
like
networking,
so
I'm
just
actually
looking
for
suggestions
here
and
probably
like.
What's
the
you
know,
the
next
step,
based
on
the
deliveries
that
we
had.
H
So
I
think
so
probably
we
should
we
should
identify,
like
I
mean
so,
which
which
addresses
like
the
most
of
the
use
cases,
whether
the
first
episodes
are
different.
So
from
what
I
can
say,
I
think
the
both
the
approaches
have
its
own
advantage,
but
again
and
it's
it's
cons
as
well
right.
So
I'm
just
trying
to
see
if
there
is
actually
a
general
feedback
from
more
folks
so
that
we
decide
one
or
the
other
one
is
better
than
one
or
the
other
inspector.
H
H
So
you're
saying
this,
the
first
approach
would
have
like
the
kept
started
already
and
like
you
have
all
the
discussion
on
the
cap
itself
or
or
the
the
other
approach
is
like.
The
more
discussion
would
happen
on
the
dock
and
presentation,
and
the
cap
would
be
more
mostly
like
ready
to
get
to
a
sort
of
state.
Is
that
what
you
are
saying
I
mean
I
just
want
to
understand,
like
the
difference
between
those
two.
A
H
B
If
you
are,
if
you
feel,
if
you
feel
that's
that's
the
time
to
to
gather
some
some
some
more
feedback
so
satish,
so
probably
it
would
be
good
to
to
post
the
document
in
in
sig
network
mailing
list.
I
don't
know,
I
can't
remember
if
you
already
did
that,
but
if
not
you
can
you
can
do
that
and
and
and
and
gather
also
some
some
feedback
from
the
brother
from
the
brother
group
from
the
brother
brother
c.
H
Okay
sure
yeah,
I
think.
D
Quick
question:
one
quick
question:
do
you
have
open
questions
that
we
have
not
yet
looked
at,
or
you
know
a
list
of
questions
that
we
have
not
yet
discussed
or
something
that
you're
still?
You
know
50
50
on
not
maybe
maybe.
D
List
down
things
that
you
were
you're
still,
you
still
want
us
to
discuss
on
something
that
we
have
not
touched
upon.
Maybe
those
questions
and
then
maybe
we
can
try
to
look
offline
or
into
the
dock
and
try
to
answer
those
questions
and
open.
H
Yeah
thanks,
subject:
yeah
that
that
makes
sense.
So
I
will,
I
will
actually
add
a
section
at
the
end
so
that,
like
all
the
open
questions,
so
that
yeah
people
can
take
a
look
at
it,
but
yeah
so
most
of
the
open
questions
I
had
like.
We
briefly
discussed
them
last
week.
H
So
probably
so
we
haven't,
I
mean
like
it's.
As
far
as
I
know
I
mean
like
we
haven't,
decided
on
one
way
or
the
other,
probably
like
we
should
so.
What
I
can
do
is,
like
so
I'll,
add
a
section
to
describe
those
open
questions
in
more
detail
and
probably
and
reach
out
to
more
people.
I
guess.
H
A
Okay,
so
you're
gonna
go
for
another
round
of
internal
feedback
before
you
no.
H
Yeah
sure
definitely,
I
think
one
other
thing
I
can
actually
do
is
like
so
I
would
I'll
actually
try
to
list
down
all
the
use
cases
and
have
like
how
the
proposal
would
look
for
each
of
those
use
cases.
I
think
so
that
would
be
the
next
step
next
step.
So,
like
all
the
like,
the
small
details
will
be
like
shown
more
clearly
and
explicitly,
I
think
so,
yeah
so
yeah.
So
my
thinking
is
like
probably
we're.
Gonna
have
like
one
more
internet
review.
H
A
Thanks
for
doing
this,
satish
we've
had
three
people
come
and,
and
almost
do
this
and
then
not
do
it
and
then
and
then
you
got
in
here
and
you've
wrangled
it
and
you're
really
getting
close
to
the
to
what
I
think
is
like
the
finish
line
here,
which
is
going
up
network
and
actually
selling
it
to
people.
So
that's
really
cool.
I
appreciate
it.
H
Yeah
no
problem
jay
yeah,
thanks
for
helping
out
like
yeah,
so
this
is
an
awesome
group.
Thank
you,
yeah
that
helps
a
luck.
A
I
Yeah,
so
so,
whatever
first
so,
there's
a
document
that
I've
been
sitting
on
it
for
a
while
I
haven't
so
I
just
like
put
a
link
there
in
the
doc,
but
before
we
do
that,
I
was
wondering
if
you
could
spend
a
few
minutes
going
through
the
network
policy,
api
use
cases,
and
I
think
I
did
add
towards
the
end
of
the
document
this
section.
Okay
here,
let
me
can
you
share
the
network
policy.
Api
use
cases,
stop
okay,.
A
Yeah,
what
is
that?
Which
one
here.
I
H
I
Yeah
I
added
this
part,
but
I
think
I
put
it
in
the
edit
mode,
and
I
think
I
just
want
to
have.
I
I
Individual
parts
running
they
all
run
within
the
context
of
a
service
account
and
the
service
account
does
not
create,
doesn't
exist.
It
automatically
uses
the
default
in
that
namespace,
but
there
is
so
there
are
some
instances
where,
for
example,
in
I'm
sure
it's
the
same
in
different
cloud
providers
too.
So
there
are
situations
where
some
of
the
pods
that
are
running
they
need
access
to
like
external
services,
which
are
restricted
for
whatever
reason,
so
they
need
to
be
audited
or
for
whatever
reason.
So
what
you'd
like
to
do?
I
I
Part
selectors,
namespace
characters
based
on
service
accounts,
so
that
it
makes
it
easier,
because
if
you
want
to
only
target
certain
parts
which
are
using
a
certain
service
account,
then
if
they're
running
across
different
parts
selected,
then
you
need
to
list
them
all,
and
then
you
know
so.
Instead
this
becomes
a
much
more
surgical
and
you
can
apply
to
the
only
the
parts
that
require
the
policy.
So
this
is
the
main
reason
behind
that.
A
I
So
yeah,
so
there
is
a
use
case
for
this
thing,
so
what
I
was
thinking
was
it
would
be
useful
to
have
this,
and
so
what
I
did
was
I
put
in
a
a
little
proposal.
I
It's
still
in
a
very
early
draft
stage.
If
anyone
wants
to
collaborate,
just
ping
me,
you
can
work
on
the
documents,
so
this
is
also
if
anyone
has
any
use
case,
additional
use
cases
that
they
would
like
to
add.
Let
me
know,
and
I'm
happy
to
add
it
to
the
doc.
Do
you,
when
you
say
service
account.
A
I
Yes,
so
so
the
the
okay,
so
the
use
case
in
so
let
me
I
think
it
will
become
more
clearer
if
we
use
a
specific
example
and
then
we
can
zoom
out
from
that.
So,
for
example,
in
there
are,
for
example,
you
have
a
pod
that
is
trying
to
access
a
cloud
service.
I
can
let's
say:
let's
go
I'm
going
to
pick
on
google,
because
that's
where
I
work
so
it's
trying
to
use
some
machine
learning,
apis
or
storage
or
some
compute
apis,
and
then
you
typically,
what
happens?
I
Is
you
need
to
provide
the
kubernetes
service
accounts,
some
roles,
ian
roles
and
that
also
actually
get
tracked
to
a
google
service
account
that
that
gets
all
these
roles
and
permissions.
That's
how
you
control
those
access.
Now,
if
I
did
not,
if
I
wanted,
for
whatever
reason
to
be
that
access
to
be
restricted
restricted
by
nature,
then
what
I
would
like
to
do
is
don't
want
to
use
the
default
service
account
that
comes
with
each
namespace,
so
in
that.
So
that
is
the
scenario
that
I'm
talking
about.
I
So
having
said
that,
that
is
a
specific
example.
So,
let's
zoom
out,
so
your
question
was:
is
it
jesus
identity?
Yes,
it
is
in
short,
but
I
know
I'm
sure
there
are
a
lot
of
nuances
around
around
that
that
concept,
but
I
think
the
short
answer
is
yes.
B
I
I
Oh
sorry,
oh
that's
all
right!
That's
good!
If
you
can
add
it
to
the
meeting
notes
so
that
then
I
can
you
don't
have
to
by
the
way.
Is
anybody
from
calico
also
here
in
this
meeting,
or
do
they
show
up
for
these
meetings.
A
Sometimes
they
do,
I
say
no,
we
haven't
seen
them
recently,
but
every
once
in
a
while
we'll
get
a
calico.
I
see.
Okay,
let
me
let
me
I'll
go.
I
A
I
A
I
Was
mostly
thinking
about
using
the
service
account
either
to
select
the
pods
or
the
select
ingress
right?
For
example,
if
you
look
at
the
link
that
I've
shared
in
the
doc,
if
you
go
back
to
the
meeting.
I
I
Yeah
so
yeah
I've
given
comment
access
to
anyone,
so
if
you,
if
anybody
needs
edit
access
just
let
me
know
I'm
happy
to
look
at
it.
So
I'm
happy
that
I
can
open
up
there.
I
don't
know
so
what
is
the
convention?
Do
you
make
it
edit
worldwide
public,
edit
or
comment?
How
do
you
guys
do
it?
I
always
make
everything
completely
open
for
people
to
edit
that
debate.
Okay,.
A
I
What
okay?
I
just
made
everybody
editors
for
this
talk,
so
I
just
changed
the
permissions,
and
so
hopefully
people
make
suggesting
changes.
Then
we
can
review
their
suggestions
and
then
etcetera.
I
I'm
sure
this
is
in
the
very
early
drafty
stage.
I
just
enumerated
the
two
use
cases,
scenarios
and
then
so.
This
basically
boils
down
to
like
having
a
different
type
of
a
selector
service,
account
selector
for
apply
yeah.
A
I
Yeah
yeah
yeah,
that's.
A
I
I
mean
I
and
since
I'm
presenting
presenting
it
for
the
first
time
if
people
can
take
a
look
at
it
and
make
suggesting
changes-
and
I
will
I'll
go
through
this-
a
little
bit
more
detail.
And
if
anybody
wants
to
collaborate,
let
me
know
and
take
it
from
there.
A
I
A
I
I
think
I'm
just
glancing
at
the
calico
link
that
recorded
that
you
posted
and
you
they
do
something
similar
to
they
call
it.
Service
accounts
yeah.
B
Yeah
they
they
they.
They
also
use
the
the
concept
of
service
account
as
an
an
identification
identification.
Sorry
folks
to
to
issue
and
some
service
mesh
like
a
multi-factor
authentication,
because
service
account
is
mostly
the
the
the
token
that
that's
inserted
inside
the
pod
right.
So
they
use
that
also
as
some
sort
of
yeah.
I
A
I
E
I
A
A
A
Anything
else.
That's
really
cool
thanks
when
I
no
yeah,
I.
I
B
Just
go
just
going
to
say
if
you
need
some
some
sort
of
of
help
or
feedback,
don't
don't
be
shy
to
ask
that
in
in
slack
also
sometimes
like.
I
have
like
a
lot
of
open
tabs
here
in
my
my
my
my
browser.
Probably
everyone
have
so
if
we
forgot
or
if
you
need
something
else,
don't
don't
wait
until
until
the
meeting
we
are.
We
are
here
to
help
you.
A
B
A
B
Actually
opened
from
cilium
opened
that
in
in
repo,
and
I
was
taking
a
look
into
that,
but
antonio
made
a
good
question
about
if
this
is
if
this
is
a
network
policy,
if
this
is
a
service
api
thing.
A
A
A
E
A
A
Well
it
I
don't
even
know
what
it
is
anymore,
like
just
something
that
people
wanted
and
like
you
want
right,
yeah,
all
seven
policies
right
and
some
were
working
on
figuring
out
how
to
do
that
at
some
point,
and
now
now
that
someone
is
here
midnight,
yeah
you're,
on
your
seven
guy
now
I
guess-
and
evidently
thomas
graf
is
but
he's
not
here.
So
as.
D
I
That
is
something
that
sounds
very
interesting,
and
I
think
I
have
some
ideas
on
that,
because
I've
worked
on
that
in
the
past
loaded
the
virtualization
networking
there,
so
I'm
happy
to
discuss.
If
you
want
to
you,
should
we.
A
Man
you
there.
Yes,
sir
okay
cool
go
for
it,
man
all
right,
I'm
gonna
share
my
screen.
Matt's
been
matt's,
got
some
interesting
stuff.
He's
got
this
net
pulse
buzzer
to
generate
all
these
different
scenarios,
based
on
our
our
work,
with
building
like
a
kind
of
a
universal
validator
for
cni's
that
has
turned
tables,
and
so
he's
kind
of
extended
that
into
the
next
kind
of
obvious,
well
non
or
non-obvious
thing,
which
is
completely
auto,
generating
all
the.
J
A
J
Jake
there
he
is
yeah
okay,
it
worked
all
right,
cool
all
right
thanks,
everybody
yeah,
so
hey
everybody,
matt
fenwick,
here
I've
kind
of
been
lurking
through
these
meetings
for
a
couple
months,
so
nice
to
actually
have
something
useful
to
show
everybody.
At
least
I
hope
it's
useful.
It's
our
first
demo,
it's
great
yeah,
so
I
work
at
synopsis
and
synopsis.
We
do
some
software
security.
You
know
some
like
software
scanning,
for
validation
and
and
security
and
stuff
like
that.
J
So
I
was
working
on
the
truth
tables
that
jay
mentioned
in
the
upstream
kubernetes
net
pal
tests.
I
don't
know
if
you've
seen
that
stuff,
but
basically
some
more
stuff
came
out
of
that.
I,
because
of
the
discussion
that
we
had
in
sig
networking.
J
I
just
ended
up
writing
something
that
can
explain
all
that
stuff
for
me,
so
I
can
have
some
idea
of
what's
actually
going
on
with
the
network
policy,
so
I
wanted
to
show
that
to
you
real,
quick
and
you
know
just
take
any
questions
or
whatever,
and
let
me
let
me
start
that
off.
Okay
cool,
so
this
is
in
this
isn't
github,
you
know
open
source
mit
license
whatever
you
can,
you
can
do
whatever
you
want
with
it,
but
I'm
also
happy
to
collaborate
with
anybody
on
anything.
J
If
you
feel
like
it's,
it's
somewhat
related,
just
yeah
feel
free
to
ping
me
on
slack
or
whatever
all
right
cool.
So
I
got
four
things
to
show
you
four
different
ways
of
kind
of
slicing
and
dicing
network
policies,
and
these
are
all
based
off
a
few
simple
network
policy
gambles
so
the
first
one
that
you
can
do
is
just
get
a
basic
explanation
of
what
these
network
policies
do
all
right.
So
the
way
this
is
organized
is
you
have
your
ingress
and
your
egress,
and
then
you
have
your
targets.
J
J
Whenever
you
first
apply
a
rule
to
it,
then
you
can
see
what
rules
led
to
that
target
and
then
you
have
your
peer
and
your
port
protocol
so
appear
as
either.
You
know
an
ip
cider
or
it's
a
it's,
a
group
of
pods
that
can
talk
to
your
pod.
So
in
this
case,
since
this
is
ingress,
these
would
be
pods
that
can
issue
requests
to
our
target.
J
J
So
I
mean
this
is
pretty
straightforward,
but
the
there's
a
little
bit
of
magic
here,
which
is
that
you
have,
if
you
have,
you
know
like
one
policy
that
denies
something
and
one
policy
that
allows
something.
As
you
all
know,
the
allow
is
going
to
override
the
deny
so
you'll
get
that
resolved
in
this
level
and
also,
if
you
have
multiple
policies
that
target
or
that
hit
the
same
target,
then
those
will
also
get
combined
for
you.
So
you
can
see
you
know
you
don't
have
to
think
across
multiple
policies.
D
That
make
sense
I
just
just
to
clarify
if
I
have
two
network
policies
both
applied
to
party
labels
for
it
and
you're
you're,
saying
that
this
tool
will
compress
those
policies
into
a
single
row
in
this
table
for
the
body
and
tell
you
what
kind
of
traffic
is
allowed.
You
won't
see
multiple
rules
for
the
same
selector.
J
Is
that
correct?
It's
not
going
to
like
delete
anything
but
like
insofar
as
rules
can
be
compressed.
It
will
do
that
so
like
if
you
have
a
rule
that
allows
port
80
and
another
rule
allows
all
ports
it'll.
Just
tell
you
all
ports,
you
know
you
won't
see
the
rule
8
anymore,
because
there's
no
point
right.
J
I
Yeah
this
is
this
is
great
man,
so
so
one
quick
question
like,
for
example,
if
some
let's
say
you
had
a
policy
with
two-
let's
say
similar
policies,
but
you
selected
the
targets.
Let's
say:
let's
use
english
as
an
example.
I
J
Would
it
combine
that
no,
those
would
be
separate
because
they're
separate
targets
and
the
reason
for
having
that
target
focus
is
because
you
know
you
get
that
target
isolation
as
soon
as
you
apply
one
policy
to
a
target,
you
know
everything
is
denied,
except
for
the
stuff
that's
allowed.
But
until
you
do
that
you
know
everything
is
like
implicitly
allowed.
J
Yeah,
I
guess
you
can
yeah,
I
guess
you
combine
the
targets
yeah,
I
see
what
you're
saying
yeah
you'd
have
all
the
targets
there,
but
then
all
the
policies
for
that
target
combined
and
then
yeah
like
you're,
saying
the
peers
and
the
protocols
and
ports,
those
things
will
actually
get
like
smooshed
and
you
might
see
something
else
disappear.
J
J
So
now
in
this
one,
what
you
can
do
is
you
can
take
a
pod
and
a
pod
has
a
name
space
and
it
has
labels
and
you
can
actually
see
like
what's
all
the
stuff
that
applies,
you
know
to
the
specific
pod,
so
in
the
previous
one
you
could
have
multiple
well
here
you
go
like
we're.
Looking
at
pod
y
labels
pod
a
right,
so
you
have
a
couple
of
different
targets
that
apply
to
it
so
to
actually
resolve
like.
What's
going
to
happen,
you
have
to
combine
those
two
targets.
J
J
You
don't
want
reports
or
protocols,
but
when
you
resolve
that
you
combine
it
with
a
different
target
for
this
specific
pod
and
now
all
of
a
sudden
you're
not
denying
stuff
anymore,
so
you're
kind
of
adding
another
level
to
the
to
the
interpretation
here
so
of
course,
you're
doing
that
for
ingress
and
for
egress
as
well,
but
then
those
two
steps
separately.
So
then
you
have
a
combined
ingress.
You
know
policy.
I
guess
that
you
would
apply
to
a
specific
pod
and
a
combined
egress.
J
A
J
Yeah,
whatever
rules
you
have
like
all
right,
these
should
be
source
network
policies.
I
guess
whatever
network
policies
led
to
this
target
right.
You'll
still
have
them
listed
down
here.
Just
so,
you
have
some
idea
that,
like
okay,
like
I
tried
to
write
this
network
policy
to
target
this,
it
actually
didn't
happen.
H
Just
one
question:
yes,
so
there,
so
I'm
actually
talking
about
the
rules
where
we
have
two
rows
right
where,
where
it
shows,
is
actually
no
eyepiece
and
yeah,
no
ips
and
no
ports
and
no
no
protocols
right.
So
so
is
it
because
I
mean
I:
I
see
that
it's
actually
getting
populated
by
the
the
network
policy
that
actually
isolates
all
the
boards,
all
the
all
the
parts.
H
J
Right,
yeah,
that's
a
great
question
and
I
think
this
is
one
of
the
really
weird
and
confusing
areas
of
network
policies.
So
the
way
that
this
is
going
to
work
is
that,
like
this
isn't
a
deny,
this
is
just
not
an
allow,
so
we're
not
specifically
allowing
any
ips,
but
it
doesn't
mean
that
we're
denying
our
keys.
So
if
something
else
came
along
and
allowed
an
ip
you
know,
then
it
would.
J
You
know
like
sort
of
override
this
rule.
I
guess
it's
just
the
way
that
I
think
about
policies
and
it's
kind
of
an
artifact
of
the
model
that
I
built.
H
J
A
J
J
I
don't
know
yeah
this
is
I
mean
this
is
why
I
built
the
thing
because
I
it
was
so
confusing
and
it
was
so
hard
for
me
to
keep
track
of
these
things
and
separate
them
out
that
I
just
needed
something
to
look
at.
That.
Just
told
me
like
this
is
what
your
policy
is
doing.
You
know
and
I'll
resolve
those
corner
cases
and
stuff
for
you,
but
anyway
yeah
like
if
you
think
I
did
something
wrong,
definitely
reach
out
to
me
and
and
I'd
love
to
figure
that
out
and
do
it
right.
Great
question.
K
Hey
man,
this
is
young
here.
I
also
have
a
question
about
the
collapsing
of
the
policies.
So
if
you
look
at
the
the
table,
that's
that
is
shown
right
here
in
the
ingress
rules.
On
the
first
on
the
first
row,
I
think
it
says:
namespace
y
match
label
labels,
part
a
and
it
has
you
know
all
these
all
these
rules
and
then
down
there.
It
says
namespace
why
all
pause
and
there's
a
different
rule.
So
do
you
mean
by
this
is
namespace?
J
K
Oh
okay,
so
is
the
is
the
row
sorted
in
that
order
where
you
would
say
that
whatever
comes
first
will
be
well
having
the
highest?
You
know
precedence
on.
I.
J
I
I
think
you're
right
this.
This
follows
the
same
union
rules
that
we
have
for
network
policy
right,
so
there
should
not
be
any
presidency.
This
is
following
the
network
yeah.
K
Yeah,
I
agree
there
will
be
no
precedence,
but
you
know
for
me
it's
it's
kind
of
confusing,
because
if
I'm,
if
I
come
with,
you
know
y
slash
a
I
will
see
there,
I
have
a
match
on
two
places.
Now
one
says
you
know:
I'm
allowed.
J
So
right,
that's
the
point
of
this
thing
down
here
like
okay,
this
is
just
trying
to
establish
provenance,
so
you
know
that
like
I'm,
if
I
just
give
you
the
final
actions
for
myself,
if
I
just
gave
myself
the
final
answer,
then
I'd
be
like:
where
did
that
come
from
the
idea
here
is
to
show
you
like
this
is
where
it
came
from,
and
then
this
down
here
is
the
final
result.
I
see
I
see
that
makes
sense
to
me,
but.
J
D
Move
on
yeah
go
ahead.
Three
sorry,
two,
two
two
things
to
ask
here.
The
first
question
is
on
the
first
diagram.
Oh
sorry,
first
two
examples
that
here,
if
you
know
in
this
case
the
the
pods
are
matching
certain
label
selectors
and
you're,
showing
the
rules
that
are
allowing
that
traffic,
what
if
a
par
is
not
selected
by
any
of
the
label
selectors,
then
what
would
the
output
look
like?
Because
in
that
case,
since
it's
not
part
of
any
target,
it
should
be
allowed
for
all.
D
And
while
you're
putting
that
together,
the
other
question
is
in
your
second
example:
you
mentioned
that
we
can
see
what's
happening
on
a
pod
or
what
policies
are
applied
to
the
pod
ingress.
Us
is
your
input,
a
label
selector
or
is
your
input,
the
name
of
the
part
or
name
reference
to
the
part,
so
you're
saying
for
this
one?
Yes,
so
the
input
here
is:
is
it
a
reference
or.
J
Is
it?
Is
it
certain
labels?
It's
like
you
know,
imagine
you
had
a
pod,
so
pod
would
have
a
name
space
and
have
actual
labels.
So
that's
the
idea
behind
this
command
is
to
you
know
like
give
me
the
actual
namespace
of
the
pod
and
the
actual
labels
of
a
pod.
Obviously
you
know
it's
just
a
test,
so
I'm
not
pulling
this
from
kubernetes
or
anything
but
yeah.
So
if
can
we.
D
Extend
it
to
in
a
way
that
you
know
if
I,
if
I
have
a
name
of
the
part
in
namespace
of
the
pod,
can
I
say
that
you
know
this
is
my
part,
and
I
want
to
see
the
rules
on
that
instead
of
find
figuring
out
the
labels
of
that
part,
and
it's
just,
I
think
I
think
you
think
you
just
need
to
figure
out
the
labels
of
the
part,
and
then
you
have
and
the
rest
of
your
magic
will
continue
to
work.
J
Yeah
definitely
yeah,
I
think
that's
a
that
would
be
a
great
feature.
Obviously
you
know
like
what
I
was
trying
to
do
here
was
model,
the
actual
like
network
policy
thing
which
is
kind
of
yeah
like
it's
it's
kind
of
weird
but
like
it
doesn't
care
about
the
pod
name,
and
so
I
didn't
include
the
pod
name
here,
but
correct.
D
G
D
J
Yeah
definitely
yeah
yeah
feel
free
to
reach
out
to
me.
We
can
figure
that
out
and
for
your
other
question
like
this
is
what
it
looks
like
if
no
targets
match
this
isn't
telling
you,
if
anything,
is
allowed
or
denied
it's
just
telling
you
that
nothing
matches,
so
the
next
step
would
actually
tell
you
whether
something
is
allowed
or
denied
all
right.
So
what
we're
doing
here
is
we
are
actually,
you
know
pretending
like
we
have
traffic,
so
our
traffic
is
on
a
port
in
a
protocol,
our
source.
J
J
So
we
have
this
ingress
which
denies
it
and
then
we
have
no
egress.
So
this
is
not
going
to
be
allowed.
Let's
see,
oh,
so
it's
a
what,
if
tool
right
exactly
yeah.
So
here
we
have
an
example
where
we
have
no
ingress
rules
that
match.
You
can
see
our
traffic
up
here.
This
is
kind
of
the
opposite
way.
So
now
this
is
traffic
going
out
of
the
cluster.
So,
of
course
we
have
no
ingress
rules
that
match.
We
have
an
egress
that
allows
an
egress
that
denies.
So
that's
an
allow.
J
I
guess
that'd
be
a
validation
of
the
tools
useful
right,
so
that
so
then
in
our
last
example
down
here,
we
have
ingress
that
allows
egress.
That
denies,
and
so
that's
actually
going
to
be
a
deny
because,
as
far
as
I
understand
it,
you
have
to
both
allow
ingress
and
egress
in
order
for
your
traffic
to
be
allowed.
I
I
think
we
got
only
two
minutes
left
matt.
I
think
this
I
I
think
there's
a
lot
more
to.
Can
we,
if
you
don't
mind,
can
we
go
through
this
thing
again?
The
next
meeting
spend
a
little
bit
more
time,
because
this
is
very
interesting
stuff
for
me
sure
yeah
I'll,
just
put
it
like,
I
don't
even
know
we
could
have
like
we
could
shut
our
other
conversations.
J
So
basically,
this
is
like
the
whole,
the
whole
shebang,
you
take
all
your
pods
and
you
see
if
they
can
talk
to
all
your
other
pods,
and
this
is
what
we
do
in
the
upstream
test
and
it,
I
think,
really
gives
you
a
lot
of
information,
but
anyway,
yeah
I'll
drop
a
link
to
cyclonus
in
slack-
and
you
know
I'm
happy
to
work
with
anybody
on
this,
like
if
you're
looking
at
adding
to
the
network
policy
api
or
something
like
that,
and
you
think
that
this
could
be
helpful
for
you.
I
You
yeah
I'm
definitely
interested
and
I
have
we
have
a
lot
of
interest
in
this
tool.
So
maybe
what
we
can
do
is
if
we
can,
if
we
can
have
a
discussion
like
in
my
couple
other
people
that
I
know
who
are
interested
from
my
team
and
then
next
week.
I
know
if
there
is
like
enough
time,
then
we
should
continue
the
discussion
next
week.
D
And
thanks
for
you'll
be
great.
It
would
be
great
if
you
could
also
share.
You
know
the
you
know.
Whatever
you
said
today,
you
know
read:
b
doc
or
something
that
will
help.
Others
that'll,
be
everybody
helpful
right.
I
A
That
was
awesome,
presentation,
thanks
matt,
so
let's
do
a
follow-up
next
week
on
this,
this
is
cool.
I
also
want
to
see
those
cni
failures
that
you
were
telling
me
about.
That's
the
thing
I'm
most
interested
in
yeah
with
with
the
different
psyllium
calico
and
tray
all
that
stuff
right
right.
Okay,
anybody
else
got
anything
before
we
jump.