►
From YouTube: Network Policy API Meeting 20210726
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
A
No
new
issues
to
triage
this
week,
usually
pretty
simple
sig
network
picks,
most
of
them
up
and
there's
none
pertaining
to
network
policy,
so
we're
just
there
to
help
out
if
there
are
any
but
didn't
see
any
good
new
ones.
That
concerned
us
today.
A
A
So
we
want
to
start
coming
to
a
conclusion
on
those
I
think
here
in
the
next
week
or
two
so
that
we
can
keep
moving
forward
with
that
kept.
Is
there
anything
else
anyone
wants
to
bring
up
before
we
get
started
with
cmp,
because
it
will
probably
go
for
a
little.
A
Bit
going
once
going
twice
sold:
okay!
Well,
let's
hop
straight
into
it,
then,
unless
I'm
forgetting
anything
yang
or
abhishek,
do
you
want
to
get
us
started
with
what
you
all
put
together
for
today.
A
B
Share
sure,
probably
you
need
to
enable
sharing.
C
Yep
yeah
all
right.
Okay,
I
think
you
know
we
added
young
and
I
added
some
of
the
use
cases
that
we
we
thought
about
and
added
a
bit
more
specific
user
stories.
C
We
can
see
first,
whether
all
approaches
are
able
to
solve
all
use
cases
and
if
yes,
then
we
will,
we
will
see
which
which
which
sample
spec
seems
more
intuitive,
to
write
more
easier
to
consume,
from
a
user's
perspective
and
and
then
and
then
you
know
we
can,
we
can
hopefully
make
informed
decision
in
terms
of
which
proposal
the
group
wants
to
move
forward
with
so
just
to
give
a
quick
overview,
and
you
know
feel
free
to
interject
in
between
folks-
and
you
know,
if
you
want
to
ask
more
questions
or
if
there's
something
that
we
have
not
included
here
and
so
so
on
a
high
level.
C
These
are
the
use
cases
that
we
think
and
we
try
to
make
them
a
bit
more
specific.
So
the
first
one
was,
you
know
something
that
we
spoke
about
was
a
strict
deny
that
is.
An
admin
administrator
may
perhaps
want
to
strictly
isolate
certain
malicious
spots
within
the
cluster.
So,
for
example,
you
have
detected
that
you
know
these
set
of
pods
are
kind
of
having
some
malicious
activity
and
you
would
want
to
lock
them
down.
C
So
you
sh,
the
administrator
should
be
able
to
write
a
deny
rule
which
kind
of
like
trumps
every
other
rule
and
they
should
be
able
to
isolate
such
workloads.
So
a
specific
example
would
be.
You
know,
you've
labeled
these
pods
as
type
malicious,
and
you
know
they
are
they're,
probably
in
the
name,
space
called.
Let's
say.
D
C
Have
great
names
for
them
this
was
just.
This
is
just
you
know
as
an
example,
but.
D
The
type
is
a
marking
they,
but
they
could
label
them.
D
The
operator
would
go
in
and
basically
have
the
rule
and
then
just
go
in
and
label
them
as
type
malicious
and
the
rule
would
probably
say
all
name
spaces.
Basically,
all
pods
of
type
malicious
will
be
denied,
always.
C
Yeah
yeah
that
that's
that's
most
likely
what
would
happen.
I
just
wanted
to
give
a
bit
more
specific,
but
yes,
definitely
the
more
realistic
would
be.
The
path
would
be
labeled
with
certain
special
label,
and
then
you
will
just
apply
this
rule
to
all
all
pods
which
have
carried
this
label.
Perhaps
they
could
be
from
all
languages
or,
and
we
could
also
specify
them
so
but
yes,
you're,
correct
in
your
understanding.
D
F
Okay,
yeah,
I
asked
question,
I
mean
one
correction.
This
is
not
saying
you
have
to
necessarily
completely
isolate.
You
can
have
any
number
of
isolation
options,
so
you
can
say
that
it
is
either
completely
isolated
or
you
can
say
that
it
is
isolated,
except
from
this
monitoring
pod,
which
I
have
launched
into
this
namespace.
F
D
C
Yeah,
so
I
think
this
is
one
specific
use
case
and
of
course
you
can
have
like
a
lot
of
combinations
of
these
use
cases,
so
you
could
have
a
strict
deny,
but
you
current
exceptions,
and
then
you
know
we
will
go
through
all
of
those
other
use
cases
as
well
and,
of
course,
in
real
deployment.
I
think
the
administrator
would
be
looking
at
solving
a
combination
of
these
use
cases,
or
perhaps
all
of
these
so.
C
C
C
This
is
a
label,
so
let's
say
you've
detected.
Certain
pods
are
acting
maliciously
and
now
you
would
want
to
isolate
those
pods,
so
you
want
to
be
able
to
group
them,
and
you
know,
typically,
you
would
group
them
as
label
selectors.
So
you
that's
why?
As
an
example,
we
have
said
that
these
malicious
parts
will
be
labeled
with
type
malicious,
so
I
mean.
E
My
my
question
is
rather,
let's
say
you
know:
instead
of
let's
say,
foo
equal,
I
mean
type
equal
to
foo,
then
you
would
be
denying
them
right.
So
so
I
mean
it's
just
a
deny.
There
is
no
special
thing
called
type.
You
know
malicious
or
something
like
that.
D
You're
reading
it
exactly
as
I
did,
this
is
an
example.
This
is
this
is
not
the
policy.
It's
a
use
case.
If
you
want
to
write
the
rule,
so
you
can
isolate
pods
that
you
have
labeled
with
type
malicious
from
a
namespace
called
isolate
me.
Then
that
should
work.
I
read
it
completely
backward
that
you
had
a
pro
that
you
had
a
policy
that
looked
like
this.
C
Yes,
this
is
not
yet
a
policy.
This
is
just
a
use
case.
You
you,
don't
necessarily
have
to
have
this
tight,
malicious
label.
You
may
have
an
identifier
for
the
pods
already,
let's
say
all
your
pods
of
app.
C
D
D
E
No,
I
think
you
know
db.
Actually
you
know
initially.
I
thought
there
is
a
type
called
malicious,
but
right
now
the
way
I'm
reading
it
is.
You
have
a
label
called
you
know
equal
to
bar.
Then
you
use
the
dna
rules
with
the
four
equal
to
bar
right.
So
yes,
so
it's
like
a
just
a
deny
policy.
E
G
E
E
C
Yes,
I
mean,
I
think
I
think
we
all
kind
of
agree
that
the
so
basically
this
is
just
to
give
a
more
specific
example,
so
that
we
can
write
specific
policies
to
demonstrate
the
api,
but
you
could
you
know
this
is
not
a
necessary
that
necessity
that
the
label
must
be
this
fubar.
Whatever,
whatever
is
the
naval.
However,
you
identify
these
compromised
pods,
you
should
be
able
to
isolate
them.
I
think
that's
the
use
case.
E
Yeah,
I
mean
at
least
you
know
in
in,
in
my
view,
maybe
I
would
change
the
you
know.
Example
saying
that,
or
maybe
add
another
example
saying
that,
like
you
know,
you
wanted
to
deny
certain
set
of
selected
parts.
You
know
by
type
equal
to
foo,
and
you
know
name
speak
name.
Space
equal
to
xyz
would
be
the
second
example
so
that
people
won't,
like
you
know,
divert
themselves
into
type
malicious
or
like
an
isolate
me
kind
of
a
thing.
C
Sure
we
can
update
the
example
to
to
what
you
suggested.
Thank
you.
D
C
D
No,
no,
not
necessarily
sort
of
you
have
this
example.
I
would
have
typed
militias
right.
Maybe
I
used
it
in
my
application
because
I'm
doing
something.
So
how
do
you
ensure
sort
of
that
things
that
an
operator
might
want
to
tag
a
pod
with
is
separated
from
the
tags
yeah?
I
think
I
think
the
user
might
typically.
C
Operate
yeah.
I
think
I
understand
the
question.
I
think.
Typically,
a
user
or
operators
may
have
their
own
predefined
prefixes
to
label
keys
and
they
can
use
that
so
that
you
know
application
owners
do
not
handle
those
labels
like
that.
C
Basically
and
then
just
use
the
rmac
that
you
cannot
set
them.
Yes,
you
you
could
you
could
enforce
that
so
that,
for
example,
communities,
dot
io
is
a
resource
space
as
a
label
prefix,
so
similarly
and
the
operators
may
have
their
own,
but
anyway,
I
think
the
the
the
idea
is
not
how
to
label
the
pods
or
name
spaces.
This
is
just
an
example.
I
think
the
idea
is
to
how,
but,
but
definitely
we
will
update
the
sometimes
by.
C
C
Yeah
yeah,
but
it's
good
too.
It's
good
to
get
that
feedback
so
that
we
yeah.
We
use
the
correct
set
of
labels
to
to
make
sure
that
it's
it's
widely
understood.
A
E
So
so
so,
just
to
give
one
example
of
at
least
the
way
you
know
contrail
was
doing
is
so
we
have
predefined
labels,
like
you,
know,
application
deployment
and
you
know
etc.
So
for
certain
of
our
customers,
like
you
know,
when
you
know,
let's
say
they
are
finding
the
ddas
attacks
using
the
analytics
engine.
E
E
E
So
I
don't
know
if,
if
maybe
it
goes
beyond
this
example,
but
you
know
if
we
want
like
you
know,
we
can
have
a
predefined
tags
or
predefined
labels.
C
Yeah,
I
think
that's
beyond
the
scope
of
policies
and
network
policies,
so.
E
Them
yeah,
I
think
if,
if
that
is
the
way,
maybe
I
mean,
as
you
say
I
mean,
as
you
agree
like
you
know,
we
can
change
that.
You
know
content
so
that
you
know
it
won't.
Divert
us
into
malicious
thing.
C
C
Has
the
same
yeah?
Thank
you.
C
The
next
one
is
a
strict
allow,
so
within
a
within
a
cluster,
you
would
want
to
allow
your
workloads
to
be
able
to
talk
to
code
dns
for
them,
assuming
they
are
labeled
with.
I
think
they
are
labeled
with
k
its
app
kodians,
but
let's
assume
that
they
all
come
up
with
app
code,
dns
labels
and
there.
So
so
as
a
specific
example
here
is
new.
E
H
Comes
in
because
even
a
namespace
admin
will
not
be
override.
This.
E
Oh,
I
see
correct.
Okay,
sorry,
I
think
I
missed
you
know
last
conversation.
C
Yeah
so
to
I
think,
to
bring
to
you
know
re-emphasize
on
the
fact
that
when
we
say
strict
something,
it
essentially
means
that
the
cluster
administrators
rules
are
enforced
before
namespace
owners,
so
namespace
owners
cannot
override
these
goods
got
it
yeah.
I
should
have
clarified
that
earlier
thanks
thanks
for
bringing
it
up
so
yeah.
So
that's
the
one.
F
One
one
small
point
on
this
and
let's
continue,
but
our
initial
sort
of
on
basic
assumption
was
all
of
the
cluster
admins
policies
take
priority
over
the
name
space
right,
so
the
in
effect
they're
all
strict,
because
every
one
of
the
we
can
come
back
to
the
this
is
like
there's
a
subtle
point
about
the
strictness
at
the
source
versus
destination.
But
the
fundamental
point
was
that
cluster
network
policy
by
definition,
implies
everything
in
a
cluster
network
policy
takes
precedence
over
namespace
network
policy,
at
least
that's
what
we
had
earlier
now.
C
I
think
from
the
get
go
we
wanted
to
solve,
set
of
broad
use
cases,
one
where
cluster
administrator
are
able
to
define
these
stricter
rules
which
cannot
be
overridden
by
a
namespace
owners,
and
then
there
are
certain
set
of
rules
which
the
cluster
administrator
wants
to
provide
as
baseline
rules,
which
can
be
overridden
by
the
namespace
owners.
And
so
this
was
this
was
from
the
beginning-
and
I
think
is
also
part
of
the
cap.
C
So
that's
why
we
make
the
the
differences-
or
rather
we
add
the
keyword
strict
here
to
denote
that
you
know
certain
policies
or
certain
rules
are
meant
to
be
not
overridden,
while
certain
others
could
use.
Cases
could
also
mean
that
I
would
want
namespace
owners
to
write
network
policies
to
override
them.
If
not,
then
it
should
be
denied
or
whatever
the
default
policy
is.
C
The
third
use
case
is
you:
have
this
stricter
deny,
but
you
would
want
to
have
some
exceptions
to
this
deny
and
you
want
to
allow
those
exceptions.
So
essentially,
this
is
like
a
subset
of
rules
which
should
be
skipped
or
accepted
from
the
deny
rule,
and
then
they
should
be
allowed.
C
This
traffic
should
be
allowed.
So
a
specific
example
is:
let's
say
you
want
to
do
namespace
isolation,
and
in
this
case
you
want
to
deny
all
of
that
inter
name
space
traffic,
so
namespace
a
should
not
be
talking
to
namespace
b,
but
you
want
to
give
some
exceptions
to
this
rule
that
is
namespace
a
should
still
be
able
to
talk
to
the
system
name
space
like
stomach
system
or
monitoring
and
cube
system,
and
then
it
should
also
be
able
to
allow
traffic
to
certain
certain
pods
in
other
namespaces
like
core
dns.
C
C
Clear:
okay,
moving
on
to
the
next
one,
which
is
strict,
deny
but
delegate
now.
The
difference
here
is
in
both
cases
we
are
actually
giving
a.
C
We
are
actually
allowing
the
administrator
to
write
some
exception
rules
to
the
deny.
But
in
this
particular
case
you
are
actually
delegating
the
disposition
for
this
traffic
to
the
to
the
name,
space
owners.
C
So
as
an
example,
you
you
have
defined
a
strict
deny
for
the
internet
space
traffic
that
is
namespace
a
cannot
talk
to
namespace
b,
but
perhaps
you
have
a
a
public
service
in
a
certain
different
name
space.
Let's
say
public
name
space.
You
would
want
all
your
name.
Spaces
to
you
know,
decide
whether
they
want
to
access
this
public
service
or
not.
You.
C
That
deny
or
allow
a
disposition
for
this
traffic.
You
want
your
name
space
owner,
so
you
want
to.
You
want
to
delegate
that
traffic
to
the
new
space
bonus
and
the
name
space
owners
can
then
write
kubernetes
network
policies
to
either
allow
this
traffic
or
simply
isolate
these
traffic.
To
this,
these
set
of
sources.
F
C
You
know
the
strict
deny
is
for
the
internet
space
traffic,
but
you're
providing
exceptions
to
those
internet
internet
space
traffic,
denials
for
public
service.
C
F
Yeah,
so
some
of
these
are
there.
There
is
a
certain
assumption
of
a
tendency
model
here,
which
I
think
we've
got
yeah.
C
Okay,
okay,
I
think
maybe
maybe
to
take
a
step
back
here.
The
tenancy
model
we
are
assuming
is
one
is
to
one
one
name:
space,
one
tenant.
We
could
also
make
it
more
generic
by
saying
that
one
one
name
space,
sorry,
one
timer
can
own
multiple
namespaces
and
we
should
be
able
to
solve
the
same
so.
F
The
point
here
is
about
whether
whether
the
admin
wants
to
needs
to
know
what
what
kind
of
communication
patterns
are
valid
and
what
kind
of
communication
patterns
are
invalid,
so
that
people
decide
whether
to
monitor
for
the
valid
graphic
patterns
right
if
the
admin
normally
an
admin
needs
to
know.
These
are
my
officially
allowed
traffic
patterns,
and
these
are
now
right
so
that.
F
So
that's
where
I
was
going
with
the
tennessee
model,
even
with
that
there
has
to
be
a
clear
understanding
of
what
should
the
tennis
should?
Does
the
tenancy
admin
not
know
or
not,
care,
which
are
the
exceptions,
are
happening
to
the
tendency
boundaries
right
because
basically
saying
that
some
clients
are
violating
some
tenancy
boundaries
and
that's
not
visible
to
the
tenant
admin
or
that's
not
controllable
directly
by
the
tenant
admin
because
they
decide
how
much
of
the
tenancy
boundary
to
violate.
F
E
For
me,
it's
not
clear
abhishek.
Can
you
expand
unfold.
C
Yes,
so
on
four,
a
okay.
So
let's
assume
that
in
your
cluster
you
have
a
namespace
which
is
called
public
namespace
and
you
have
a
service
which
is
called
a
public
service
within
this
namespace
as
a
as
an
administrator,
you
would
want
all
your
tenants
to
access
this
public
service
or
maybe
not
depends
on
whether
the
namespace
owner
wants
to
access
or
not
so
so.
Let's
say
you
know,
I
have
a
namespace
called
abhishek
namespace
and
I
don't
really
care
about
the
public
service
and
interface.
C
C
Now,
as
a
cluster
administrator,
I
want
to
make
sure
that
abhishek's
namespace
does
not
talk
to
yang's
namespace,
but
I
let
abhishek
decide
whether
he
wants
to
access
the
public
service
from
public,
namespace
and
yang
decide
whether
he
wants
to
access
public
services
to
public
namespace.
So
this
is
like
a
delegation
for
this
particular
traffic
to
both
yang
and
abhishek,
as
name
space
owners,
but
for
inter
namespace
traffic
for
other
namespaces.
I
want
to
strictly
deny
them,
which
means
I
cannot
write
any
rule
to
talk
to
services
offered
by
young's.
E
Okay,
yeah,
I
think
you
know
I
got
the
use
case,
but
I
think
okay,
maybe
I'll,
think
a
little
more
and
you
know
give
the
proper
comments.
Yeah
go
ahead.
H
Abhishek,
this
is
vane
again
the
same
question
that
I
think
we
were
asking
so
the
name
that
you're
using
for
pub
slash
service
pub
slash.
These
are
not
j.
These.
These
are
just
placeholders.
C
H
Four
and
I'm
sorry
to
come
back
on
4a.
So
this
the
use
case
4a,
is
coming
because
see
in
this
becoming
a
very
different
intersection
between.
I
mean
three,
which
is
already
intersection
with
one,
so
so
having
a
deny
and
allowing
certain
some
subset
of
that
as
an
exception.
H
C
F
H
I
mean
there
are
multiple
ways
to
do
it.
If
I
mean
one
way,
is
to
definitely
rewrite
your
deny
rule,
but
I
I
mean
I
made
my
point
so
I
can
you
can
go
ahead.
F
Yeah,
so
I
had
actually
introduced
this
use
case,
but
it
was
a
slightly
different
version
of
this
when
I
first
introduced
it,
which
is
in
that
policy
apis
repo
right
in
the
user
stories
repo,
although
something
similar
might
have
been
in
the
original
cape
as
well.
I
mean
we've
had
so
many
use
cases,
so
the
thought
at
that
time
was
that.
F
This
is
a
tendency
model
which
is
controlled
by
and
visible
to
the
admin.
So
even
if
you
have
to
make
an
exception,
the
exception
is
also
visible
and
possibly
controlled
by
the
admin.
But
when,
but
now
we
have
slightly
changed
it,
which
is
that
the
tenancy
is
controlled
and
visible
to
the
admin.
But
the
exceptions
are
not,
and
we
have.
F
We
don't
have
a
real
world
validation
of
what
is
the
operational
model
in
which
that
happens,
because
what
it
does
is
the
admin
is
not
sure
whether
a
certain
flow
is
a
validly
allowed
flow
because
it
is
crossing
a
tenancy
boundary
or
whether
it
is
not
a
valid
flow,
because
tenants
are
supposed
to
be
isolated.
But
there
are
some
exceptions
which
I
don't
know
right.
The
admin
doesn't
know
which
are
the
exceptions
so.
A
H
H
H
I
think
that
is
the
delegation
part
right,
I
mean
namespaces
can
write
policies
that
circumvent
this
denials,
but
if
you,
if
you,
if
the
cluster
network,
the
cluster
admin,
has
complete
visibility,
then
we
don't
have
delegation
to
the
name
spaces
right
I
mean
everything
is
now
handled
by
the
cluster
network.
Admin.
F
Yeah,
so
that's
why
we
there
is
a
risk
that
we
could
end
up
spending
a
lot
of
time
on
it,
and
I
want
to
make
sure
that
abhishek
is
time
to
go
through
all
I
just
mentioned
one
point
here,
which
is
that
your
original
point,
yeah,
I
mean
intra
name
space
and
intra
tenant
traffic-
is
already
completely
under
the
name
space
users
control
right.
So
we
what
we.
F
F
He
delegates
it
by
just
not
having
a
policy
to
it.
So
implicitly
what
I
don't
control,
I
let
you
control
right.
So
so,
basically
the
point
is:
if
I
care
about
it,
then
I
have
a
policy
because
I'm
super
user,
I'm
the
admin.
If
I
don't
care
about
it,
I
don't
have
a
policy,
you
do
what
you
want
with
it,
but
you
can.
C
C
F
E
H
Then
right
so
so
I
just
okay.
So
now
I
understand
it
more
clearly
after
your
discussion,
but
I'm
still
a
little
bit
confused
because
of
the
naming.
So
what
I
understood
is
this
4a
is
basically
kind
of
a
weak
deny
not
I
mean
if
name
space
admin
allows
the
traffic,
then
they
can
allow
it,
but
if
they
don't
by
by
default,
it
will
fall
back
to
these
denies.
C
No,
no
so
so,
let's
take
a
example
of
kubernetes
network
policies.
We
have
it
blocked
today,
right
in
the
ip
block.
There
is
a
there's
a
accept
site,
so
people
have
used
cider,
and
then
you
accept
a
subset
of
that
cider.
By
doing
an
accept
call
right,
the
accept
does
not
say
that
you're
denying
that
traffic
you're
actually
just
delegating
it
to
a
next
namespace
or
policy
rule
so
until
and
unless
someone
actually
explicitly
denies
or
isolates
it,
you
are
your
your
traffic
should
be
allowed.
So
this
is.
C
E
C
E
E
So
so
abhishek
you
know
just
I
don't
know
whether
I
mean
just
wanted
to
recap
to
understand
right.
Let's
say
I
have
a
to
b
traffic
and
you
know
b
consists
of,
like
you
know,
b1
to
b10,
and
you
wanted
to
say
you
know
a
to
b,
deny
except
b9
and
b10
and
b9
and
b
tends
fate
would
be
driven
by
the
name,
space
admin
to
say,
b9
and
b10.
You
know
whatever.
C
Is
to
kind
of
like
have
that
difference
between
3a
and
4a,
because
in
3a
you
are
strictly
allowing
the
extension.
So
let's
say
taking
your
example
a
to
b,
let's
say
b9
you
want
to
allow
you
do
not
want
to
let
namespace
owners
decide
that
so
that's
an
accepting
and
allow
so
that's,
three
and
b10
is
something
that
you
want
to.
Let
your
name
space
owner
decide.
So
that's
delegating
so
just.
F
Okay,
so
so
abhishek.
So
let
me
jump
in
on
this
point,
which
is
what
I
was
trying
to
raise
earlier,
but
I
was
differing
but
figured.
We
are
anyway
going
on
a
tangent
now,
so
I
might
as
well
throw
this
one
in
as
well,
when
we
do
remember
that
there
are
two
parts
to
any
allow
or
deny
right
what
you
do
at
the
source
and
what
you
do
at
the
destination
right.
F
E
It
right
yeah,
but
sanjiv
I
mean
see,
the
premises
is
like
you
know,
do
we
agree
even
in
the
egress
right?
Do
we
agree?
You
wanted
to
give
a
exception
for
b9
and
b10
in
a
given
a
to
b.
Deny
right,
I
mean
see.
Even
it
could
be
still
ingress.
E
A
Need
to
do
yeah.
Well,
look.
We
have
18
minutes
left
y'all.
I
think
what
abhishek
and
and
what
everyone
else
wants
is
like.
Are
these
valid
use
cases
so
there's
all
these
different
arguments
around
and
the
implementation
side
of
these
use
cases
and
I
think,
we've
been
kind
of
diving
into
them,
but
you
know
the
clarity
level,
which
has
been
brought
up
a
couple
times.
That's
important
like
we
want
to
hear
like.
Are
these
used
cases
clear,
a
and
then
b?
A
Do
we
agree,
so
we
haven't
even
gotten
to
the
yammels
yet,
but
I
think
if
we
could
just
finish,
let
abhishek
talk
for
a
little
bit
if
we
have
any
more
concerns
about
understanding
what
the
use
cases
are
saying,
not
arguments
about
the
use
cases
just
understand
what
they're
saying
and
whether
or
not
we
agree
we
should
move
forward.
That
way.
Does
everyone
agree.
E
Yeah,
I
think
you
know
I
mean
at
least
you
know
in
my
mind,
till
this
discussion
right.
I
didn't
understand
what
is
the
you
know
deny
and
delegate.
So
maybe
we
need
to
have
a
you
know.
Little
more
different,
you
know
descriptions,
you
know,
you
know
to
give
some
more
clarity.
C
C
Use
cases
right
so
and
and
that's
what
I
want
to
get
get
a
message
from
you
guys
is
that
is
3a
and
the
difference
is
between
three
and
four
clear
to
everyone
like
the
intention
should
be
clear
at
least,
and
then
we
can
once
the
intentions
are
clear.
I
think
it's
easier
to
read
the
right
propositions,
yeah.
H
Except
the
meeting
was
a
little
yeah,
a
little
confusing.
C
E
Least
now,
okay
yeah,
so
so
why
it
is
named
as
only
inter
namespace
yeah.
C
So
just
to
talk
about
4b
now
so
in
4b,
so
let's
say,
inter
namespace
is
basically
with
traffic
between
namespace
one
to
namespace,
two
or
maybe
a2b
right
and
as
a
administrator.
My
my
tenancy
model
here,
let's
say,
is
one
is
to
one
we
can
solve
the
other
tendency
models
as
well.
But,
let's
you
know,
simplify
the
scope
here.
One
is
to
one
tendency
model.
C
C
The
intra
namespace
traffic
is
basically
anything
within
that
namespace,
so
within
namespace
a
how
I
want
my
traffic
to
talk
like
how
I
want
my
workloads
to
you
know
talk
to
each
other
is
the
responsibility
of
the
namespace
owner.
The
administrator
doesn't
really
care.
So
let's
say
you
as
a
owner
of
namespace
a
would
want
certain
services
to
talk
to
certain
other
services
within
your
own
namespace
and
isolate
certain
other
services,
so
that
should
be.
You
should
be
able
to
do
that
and
it
should
not
be
like
the
cluster
administrator
has
said.
C
You
know,
inter
namespace,
traffic
should
be
denied,
but
international
traffic
should
be
allowed
now,
since
the
cnp's
rules
are,
but
the
allow
rules
are
strict
in
the
sense
that
they
cannot
be
overridden.
You
will
never
have
an
opportunity
to
isolate
certain
workloads
within
your
namespace.
We
don't
want
that.
We
we
want
in-space
owners
to
make
their
own
decisions.
E
E
So
so
so
isn't
it
as
a
cluster
network
policy
admin
I
would
wanted
to.
You
know,
stop
certain
traffic,
even
within
the
you
know,
name
space
to
outside
world
right.
So
let's
say
I
don't
want,
like
you
know
my
across
the
board
in
my
company.
E
You
know
I
have
lots
of
tenants
and
I
don't
want
them
to
go
to
xyz.com.
So
do
I
have
do.
I
have
ability
to
block
that
at
the
cnp
level
or
not.
C
That
is
a
very
good
question,
and
that
is
a
very
valid
use
case,
but
I
think
you
know
there
was
a
bit
of
discussion
about
you
know
doing
the
outside.
You
know,
cluster
external
traffic
requires
ipv
block
and
ip
block
for
ingress.
Egress
has
a
different
semantics,
so
we
need
to
first
nail
down
those
semantics
well
before
we
you
know
use
them
in
cnp
as
well.
C
So
I
think
that's
why
we
like
kind
of
de-scoped
it
put
it
as
a
non-good
for
external
traffic
for
specific
blocks,
but
I
agree
that's
a
very
important
use
case
and
we
should
be
solving
that.
I
do
not
disagree
on
that.
D
A
Yeah-
and
so
I
think
I
think
it's
something
that
needs
to
be
thought
about
further,
but
right
now
it
makes
more
sense
just
to
design.
For
you
know,
intra-cluster
traffic.
C
And
basically,
the
use
cases
that
we
are
trying
to
today
solve
for
our
all
traffic
within
the
cluster,
so
cluster
internal,
but
nothing
cluster
external
like
no.
We
don't
want
to
address
those
use
cases
with
this
proposal,
but
but
yeah
those
are
valid.
That
doesn't
mean
that
they
are
not
valid
use
case.
They're,
definitely
valid.
E
Okay,
so
let's
let
me
take
another
example:
let's
say
in
a
given
cluster
right,
I
have
n
number
of
name
spaces
and
each
name
species
has
you
know
certain?
You
know.
Example,
let's
say
maybe
you
know
monitoring,
you
know
monitoring
parts.
So
what
I
I
mean
I
don't
want.
You
know
certain.
E
You
know
part
selector
doesn't
reach
to
the
that
monitoring
pod.
So,
but
if
this
is
across
the
board
right
for
any
name
space
which
is
spun
up
in
the
cluster,
would
I
have
a
ability
to
specify
that
the
cluster
you
know
network
policy?
E
Or
do
you
say
that,
like
you
know
it's
your
name
space
problem
and
you
know
you
go
and
define
it
inside
your
namespace.
Now.
C
If,
if
as
an
is
as
a
cluster
administrator,
you
know
that
all
your
name
spaces
or
should
not
be
like
certain
parts,
should
not
be
able
to
talk
to
certain
other
parts,
then
you
use
a
strict
deny
and
you
you
should
be
able
to
write
such
certain
strict,
deny
policies,
and
that
would
affect
your
name
space
traffic
as
well.
So
you
can,
you
should
be
able
to
do
that,
and
you
can
do
that.
So
this
is
the
first
one.
A
use
case
is
kind
of
for
that.
C
C
C
C
C
Okay,
thank
you
all
right,
so
I
think
for
so.
I
I
feel
like
today.
We
are
only
going
to
at
least
hopefully
and
that's
actually
not
a
bad
exercise
that
you
know.
We
are
at
least
agreeing
on
the
use
cases,
and
then
we
can
look
at
samples,
but
the
fifth
one
is
basically
now
so
now
now
that
we
understand
four,
which
is
which
is
stricter
denies,
but
you
know,
do
you
want
to
delegate
certain
traffic
patterns
to
the
name
space
owners?
C
The
fifth
one
is
how
what
happens
when
the
name
space
owners
do
not
act
on
that
delegated
traffic.
So
so,
let's
say,
as
a
namespace
owner
the
the
administrator
has
delegated
the
responsibility
of
public
service
to
me
and
as
a
namespace
owner,
I
have
not
written
any
rule
for
it.
So
what
should
be
the
default
disposition
for
such
delegated
traffic,
not
for
all
traffic,
but
for
such
delegated
traffic?
C
As
as
a
cluster
administrator,
I
could
force
administrators
to
write
network
policy
by
saying
the
default
disposition
would
be
deny
which
means
that
any
delegated
traffic,
if
not
allowed
specifically
by
kubernetes
network
policies,
will
be
denied
or
I
could
let
it
be.
As
is
you
know,
so
you
know
if
you
don't
allow,
if
you
don't
write
any
rule,
that
means
you
know
the
traffic
is
allowed.
C
H
C
So
that
again,
that's
again
talking
a
bit
about
implementation
right.
Are
you
talking
about
like
you're
thinking,
in
the
terms
of
how
I'm
going
to
order
these
right?
We
don't
want
to
talk
about
that.
H
C
G
No
worries,
I
think
what
nadim
is
saying
that
it's
just
like
a
a
wording
thing
where,
where
he
understand,
for
example,
weak
deny
as
if
there's
no
namespace
natural
policies
that
regulates
the
traffic,
then
we
have
a
default
layer
of
this,
which
is
specified
by
cnp
and
if
that's
denied
or
allowed.
G
So
in
that,
in
that
sense,
we
could
call
it
like
a
week
deny
or
weak
allow
meaning
that
you
know
if
all
four
through
right,
if
we,
if
the
traffic
is
not
captured
by
a
strict
cmp
rule,
and
if
the
traffic
is
not
captured
by
a
namespace,
the
at
the
main
network
policy
rule.
Sorry,
not
I
mean
like
namespace
kubernetes
network
policy
rule,
then
the
the
weak
rule
sort
of
like
gets
hit.
G
E
You
mean
the
five
yeah
you
are
calling
it
as
a
weak
rule.
I
mean.
Is
that
what
it
is,
and
five
a
and
b
I'm
just
calling
it
a
week
rule
I
mean.
H
H
Yeah
I
mean
for
a.
I,
in
my
opinion,
is
just
a
more
sophisticated
way
of
writing
one
with
more
grammar
but
yeah.
I
was
talking
about
like
a
fifth
one
fifth
day
right.
If
you
call
it
a
week
deny
or
a
week
allow
which
comes
in
later
right,
then
then
that
can
that
can
basically
define
use
cases
for
a
and
b.
C
Yeah,
I
think
that
makes
sense
yeah,
but
but
at
least
I
think
we
understand
so,
is
there
any
more
confusion
on
the
use
case?
C
C
Right,
the
sixth
one
is
again
we
you
know,
we
just
spoke
about
like
the
external
traffic
and
one
of
the
things
that
we
thought
that-
and
this
is
something
that
tim
horton
brought
up
was
that,
with
with
cluster
network
policies,
we
are
aiming
that
this
is
going
to
be
a.
C
B
C
To
be
a
guardrail
for
kubernetes
network
policy
right
so,
but
kubernetes
network
policies
allow
you
to
write
ip
block
selectors
for
external
traffic.
Now,
even
though,
if
you
lock
down
a
particular
name
space,
you
can
still
write
an
ip
block
to
allow
external
traffic
mx
escape
cluster
network
policy
rules.
So
so
we
wanted
to
wanted
to
see
whether
this
makes
sense
or
not,
whether
to
lock
down
all
or
nothing
for
external
traffic
and
not
like
have
like
a
specific
ip
block,
selector
or
not.
C
H
So
so
one
of
the
thing
which
I
think
sanji
mentioned
last
time
right
about
the
ability
to
do
all
the
things
from
a
persona's
perspective
right.
So
if
you
don't
have
ip
block,
then
we
are
restricting
the
persona
at
cap
level
right.
It
has
to
go
and
fall
back
at
the
enemy
space
level.
To
do
something
related
to
external
traffic
will
not
be
able
to
cover
everything
from
the
from
the
cluster
admins
perspective.
A
D
And
what's
the
problem
that
we
find
the
current
ip
block,
not
good
enough,
so
that
it
would
be
sort
of
to
have
another
way
to
specify
right
if
you
box-
and
I
mean
I
from
a
I'm-
a
networking
guy
right.
So
I
still
don't
understand
why
we
don't
have
some
way
to
to
specify
longest
prefix
matches
for
these
things
instead
of
a
range
and
then
exceptions
as
long
as
prefix
match
is
well
established
and
it
works
both
for
v4
and
v6,
so
so
build
something
like
that.
Instead,.
A
D
F
So
the
current
thing
is
that
I
mean
yeah.
All
of
these
things
are
valid
at
the
same
time,
what
has
been
sort
of
agreed
loosely
is
that
all
ingress
and
egress
use
cases
will
be
addressed
separately,
potentially
with
different
crds
or
potentially
extensions
to
the
same
theory
and
all
those
ingress
and
egress
use
cases
are
the
ones
that
rely
on
ip
block,
which
mostly
has
been
problematic
on
the
ingress
because
of
various
netting
operations.
There
is
also
eager
standing
operations.
That's
why
it
is
being
different.
F
So
so
now,
let's
just
focus
on
the
intra
cluster
and.
D
I
think
so
we
should
not.
So
today
the
cost
to
specify
sort
of
a
new
policy
type
is
very
high.
I
think
in
the
end,
we
need
computers
to
kubernetes,
where
adding
a
new
policy
type
has
no
impact
on
the
cni's
and
has
very
little
impact
on
the
system
itself.
Well,
we're
sort
of
we
haven't
even
started
there,
but
that's
what
you
need
to
get
to
in
the
end.
D
So
you
can
do
these
things
and
add
them
and
add
a
new
version
of
the
network
policy
without
impacting
the
cni's,
because
they're
just
testing
for
communication
right.
They
shouldn't
have
to
know
how
to
break
out
down
all
these
policies
into
something
that
then
can
be
used
to
build
a
firewall
from
right.
A
E
C
The
number
seven
is
like
you
know,
whatever
proposal
that
we
come
up
with
should
be
extensible
in
a
way
that
we
should
try
to
be
able
to
accommodate
future
extensibilities
to
the
proposal,
and
this
is
not
a
use
case,
but
it's
a
good
to
have
that.
You
know
the
proposal
that
we
have
is
extensible.
So
so,
let's
say
an
example
is
that
you
know
in
future
we
decide
to
do
ip
block
within
the
cnp.
Then
it
should
be
able
to
be.
You
know.
C
The
proposal
should
be
extensible
enough
to
include
that
and
the
final
eight
one
is
like
it's
like
an
all-inclusive
policy,
because
typically
you
you're
gonna,
have
a
mix
of
use
cases
right.
So
as
a
typical
use
case
for
your
cluster
would
be,
you
want
to
deny
or
enter
name
space
traffic,
but
you
want
to
strictly
allow
traffic
to
core
dns
for
the
chief
system
and
system
name
spaces
and
then
delegate
interning
space
and
traffic
to
public
service
to
developers.
So
this
is
like
an
all-inclusive
policy.
C
She
should
also
be
able
to
cover
with
the
proposal
without
you
know,
having
too
much
of
mental
trauma
associated
by
writing
policy.
So
so
that's
that's.
I
think
these
are
the
use
cases
and
then
I
think
we
have
kind
of
gone
over
all
of
the
the
use
case,
and
I
think
now
everyone
at
least
understands
the
intention
of
the
use
cases
and
if
we
have
left
out
any
particular
use
case
that
is
not
and
covered
by,
you
know.
C
127
then
do
let
us
know,
and
I
think
next
week
we
can
talk
about
how
the
implementations
sample
specs
can
be
used
to
solve
these
use
cases.
E
C
Add
this
the
link
to
the
to
the
agenda
today.
C
So
I
know
I
think
I
think
it
was
like
the
action
item
for
this
week
was
to
run
through.
These
use
cases,
agree
upon
those
intentions
and
then
you
know,
take
a
look
at
the
sample
specs
for
for
the
three
action
proposal
and
for
the
priority
based
proposal.
So
I
think
so
sanji
if
you
agree
upon
these
use
cases.
C
So
maybe
we
can
have
like
a
priority
based
sample
yamas
and
we
can
have
three
action
based
sample
yamls
to
to
look
at
next
week
and
that
way
we
document
them
and
we
see
and
and
if
there's
there
are
other
implementations
specifically,
then
we
can
speak
about
that
next
week.
That's
fair
enough
because
I
don't
want
to
just
show
the
three
action
yamas,
because
I
think
majority
it
seems
like
you
know,
there's
like
either
a
three
action
for
three
action
or
for
priority
based.
C
So
it
will
be
good
to
see
yammers
for
each
of
those
use
cases
on
on
both
the
coupons.
A
Great
well
thanks
so
much
for
doing
that,
all
that
today,
I'm
preparing
all
that.
Please
share
that
link
in
in
the
agenda,
and
I
hope
everyone
has
a
really
good
day
and
let's
get
some
more
comments
on
this
and
try
to
iron
some
about
some
stuff
out
by
next
week.
F
A
Whatever
I
think
is
decided
upon
should
be
reflected
in
the
network
policy
api
repo
for
future
reference.
I
think
it
just
started
moving
so
fast
that
it
almost
was
easier
to
do
via
a
slideshow
manner,
but
yeah.
It's
all
a
learning
experience.
We
want
to
get
better
at
this.
So
that's
an
awesome
feedback.
We
need
more
of
it.