►
From YouTube: Network Policy API Meeting 20200727
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).
B
Hey
everybody,
so
today
is
the
7th
the
27th
of
july.
So
this
is
the
sig
network,
sort
of
network
policy
plus
plus
subproject.
B
Group-
and
I
guess
I
think
this
is
our
first
actual
recording
that's
going
to
get
posted-
I
don't
recall
if
we
recorded
last
the
last
meeting
or
not,
we
did
okay,
so
it's
our
second
official
recording,
so
this
will
be
on
the
internet,
so
everybody
be
nice
to
each
other.
B
Follow
the
cncf
guidelines-
and
we
don't
haven't-
had
a
lot
of
structure
to
this
group,
thus
far
other
than
going
through
these
use
cases
so
to
get
us
back
to
where
we're.
At
last
time.
We
we
started
talking
a
little
bit
about
service,
some
of
the
some
of
the
service
policy
stuff.
B
We
also
were
talking
a
little
bit
about
network
policies
around
the
specifically
around
the
kubernetes
service
endpoint
and
what
we
should
do
for
those
because
they
may
or
may
not
be
in
a
pod
and
whatnot,
and
I
think
our
really
our
current
kind
of
goal
is
to
get
as
much
feedback
from
new
people
as
possible.
Now
that
we
have
a
much
broader
audience
and
just
to
remind
everybody
so
far,
we've
been
using
a
grading
system
of
green,
yellow
and
red
red,
isn't
necessarily
bad.
B
It's
just
something
that
we
really
have
no
idea.
How
well
how
we
can
move
forward
and
green
is
something
that
people
really
want
for
sure
and
it
seems
like
there's,
probably
a
reasonable
path
forward.
It's
not
a
completely
theoretical
thing
and
yellow
is
somewhere
in
the
middle.
It's
something
that
some
people
might
want,
but
we
need
to
clarify
exactly
what
they
want,
and
at
least
some
intuition
on
how
we
might
get
there
eventually
to
know
that
it's
a
practical
goal.
C
B
Yeah,
that's
a
good
point
in
general.
It
seems,
like
that's,
been
the
the
way
we've
been
using
green,
even
though
it's
not
the
formal
definition
of
it.
So
I'll
just
add
it
in
there.
E
B
Okay,
it's
good
to
see
you
cody.
So
is
anybody
new
here
it's
cody's
first
time
to
come
since
we've
had
the
official
subproject
title,
but
is
there
anybody
new
here
that
wants
to
introduce
themselves
at
all?
I
see
a
lot
of
I
think
I
see
a
few
new
new
faces.
F
Yeah
gladly
introduced
myself,
hey
hey,
my
name
is
josh
harshman
and
a
company
recently
really
investing
kubernetes,
so
I'm
kind
of
getting
more
involved
or
wanting
to
get
more
involved
in
some
of
these
sigs,
especially
around
the
networking
stuff,
because
we
got
really
bit
in
the
butt
about
a
month
or
two
ago
when
some
networking
changes
came
down
and
all
of
our
stuff
stopped
working.
F
So
that's
my
motivation
for
being
here
and
here
to
help
out
I
mean
where
I
can.
B
Cool
yeah
we
we're
new,
so
we
need
people
to
help
us
for
sure
right.
This
is
something
that
something
that's
kind
of
new,
and
so
it's
a
new
working
group
and
so
feel
free
to
reach
out
to
me
on
slack
after
this.
If
you
want
to
like
get
caught
up
on
things,
so
you
can
make
some
help
us
move
forward
sort
of
yeah,
I
so
just
a
quick
for
for
you
and
maybe
for
others.
That
haven't
been
a
part
of
this.
B
But
that
could
be
tools
that
some
of
us
off
go
off
and
collaborate
on
on
the
side.
So
there's
kind
of
three
different
funnels
that
things
may
flow
into
out
of
this
working
group.
An
example
of
the
latter
is
you
know
this
idea.
We've
been
bouncing
around
about
a
policy
ctl
right,
a
tool
that
could
manage
network
policies
for
you,
statelessly
as
a
client-side
tool,
just
something
we
might
build.
The
sig
network
doesn't
need
to
necessarily
help
with
so
there's
a
lot
of
stuff
going
on,
but
yeah.
B
B
G
G
Hi,
my
name
is
gilman
hi.
I
was
just
curious.
I
just
sort
of
you
know
helped
me
understand
things
a
little
bit
better.
You
know
kubernetes
had
that
sort
of
place,
and
then
you
know
there's
a
lot
of
innovation
happening
in
the
the
mesh
space
as
well.
You
know
in
open
source
trying
to
understand
like
how
people
are
viewing
this
and
from
other
perspectives.
When
it
comes
to
network
policy
redesign,
do
you
feel
like
there
is
some
dovetailing
there
do
you
feel
like
there
is?
G
You
know
necessarily
some
sort
of
a
ramp
from
kubernetes
to
to
service
match
like
how
are
people
thinking
about
that.
I'm
just
trying
to
organize
my
thoughts
as
we
go.
B
Yeah,
so
I
that's
a
tough
question
right.
I
mean
that
the
whole
thing
with
the
service
mesh,
like
takes
over
your
whole
network,
so
there's
a
whole
different
set
of
security
boundaries
that
you
define
there.
B
I
don't
know
if
I
don't
have
an
answer
for
that.
I
just
I
I
think
that's
an
ongoing
question.
Does
anybody
else
these
were
originally
designed
for
developers
right,
so
these
network
policies
so
something
you.
D
B
With
an
application,
I
don't
but
we've
treaded
into
this
area
of
global
policies
very,
very,
very
rapidly.
Once
we
started
collecting
use
cases,
a
lot
of
people
wanted
those
yes,
so
it
gets
really
muddy.
Okay,
it
seems
to
me,
like
the
natural
answer.
Is
that
it's
redundant
at
this
point?
But
that's
probably
not
a
good
answer.
I
don't
know.
Does
anybody
have
a
better
answer
than
that.
H
I
I
don't,
but
I
think
it's
safe
to
assume
that
most
of
the
people
here
are
coming
at
it
from
this
united
perspective,
sorry,
which
perspective
like
the
perspective
from
like
a
cni
implementation,
I
don't
know,
maybe
I'm
wrong.
Maybe
there
are
people
here
representing
service
classes,
but
at
least
like
the
focus
of
this
group.
As
far
as
I've
seen,
this
we'll
see
like
at
the
container
level,
okay.
G
Yeah
I
just
wanted
to
sort
of
like
fill
out
the
the
group
and
see
like
what
does
it
mean
to
have
that
thing
sort
of
hovering
you
know
somewhere
up
in
the
air,
so
appreciate
you
all,
sharing
your
perspective,
so
yeah
didn't
really
need
a
binary
answer,
one
or
the
other
just
wanted
to
understand
how
people
are
singing
thanks.
B
There
is
one
policy
in
place
that
is
proposed
by
one
of
your
friends
over
at
google
saying
who
about
you
know
about
this
very
topic.
Well,
there
is
one
thing
which
is:
you
know
like
andrew
mentioned,
and
I
like
you
there
even
with
this,
I
like
you,
you
may
need
to
open
certain
things
up
in
order
for
your
mesh
to
work
properly
right.
So
there's
there's
some
synergistic
value
to
that
in
case
he
was
about
to
say
something.
I
Yeah,
I
didn't
have
a
lot
to
add,
but
like
the
way
that
I
know
that
I
have
looked
at
this
a
little
bit
before,
is
that
there's
some
overlap
but
they're
not
really
necessarily
exclusive
with
each
other.
Certainly
like.
We
have
a
lot
of
calico
users
that
are
using
both
network
policy
and
service
meshes
and
yeah.
Calico
actually
has
an
integration
where
we
kind
of
blend
the
two
and
do
some
application
layer
enforcement
yeah.
F
I
Of
that
network,
the
kind
of
access
control-
that's
provided
through
network
policies,
so
I
think,
there's
some.
I
don't
know
wiggle
room
and
flexibility
there
for
for
creativity,.
G
Oh
for
sure,
now
I've
definitely
run
the
mechanical
posts
on
on
that.
You
know
sort
of
dovetailing
effect
between
the
two.
So
I
just
I
was
curious
to
know.
If
there's
I
can't,
if
they're
evolving
the
neural
policy
posture,
is
there
a
certain
direction
that
we
want
to?
You
know
stay
true
to
kind
of
thing,
and
and
how
do
we
want
to
keep
service
mesh
in
perspective
or
not?
Just
was
just
curious
to
something
and
understand
that.
I
Do
you
think
it's
really
important
that
we
keep
our
like?
I
don't
know
the
right
way
to
say
it
is
concepts
clear.
You
know
like,
like
you
kind
of
hinted
at
jay
network
policy
was
originally
a
developer,
focused
api
and
a
lot
of
the
way
that
it,
the
design
and
the
way
that
it
turned
out
in
the
end
was
was
influenced
by
that
you
know.
I
We
expect
this
to
be
a
developer,
focused
api
that
application
developers
are
going
to
use
and
not
necessarily
like
a
cluster
admin
or
a
security
team
is
going
to
be
using,
and
I'm
keen
that
we
keep
that
sort
of
focus
while
we're
building
these
things
out,
maybe
yeah
we
need
additional
apis.
Maybe
we
change
the
scope,
but
let's
do
that
explicitly
if
we
do.
C
D
D
A
little
I've
been
trying
to
do
a
little
bit
of
synthesis
because
there's
been,
you
know
this
recurring
issue
of
an
app
yeah.
I
tend
to
go
with
a
trichotomy
of
you
know.
D
There's
there's
app
like,
like
wilhelm,
will
tell
you
right,
there's
an
app
developer,
there's
an
app
deployer
and
we've
got
cluster
admins
right
and
the
app
deployer
is
the
one
who
you
know
really
cares
about
what
this
app
needs
and
the
cluster
admin
wants
to
be
wants
to
be
able
to
be
in
a
position
to
say
no,
and
I
I
think
you
know
a
lot
of
the
reason
we
got
into
egress
was
really
about
being
able
to
say
no,
you
know
when
we
talk
about
app
or
developer
focus.
D
What
we're
really
talking
about
is,
you
know,
app
app
deployer
and
I
I
think
you
know
we
have
later
in
this,
not
on
the
the
top,
but
you
know
lower
down
on
our
list
of
use
cases.
You
know
stuff
about
controlling,
egress
and
and
cluster
admin
concerns.
D
D
The
same
as
ingress,
because
it's
really
somebody
else's
problem
and
I
think
the
maybe
a
good
synthesis
would
be
to
say
you
know
the
app
deployer
gets
to
say
what
this
app
wants
in
terms
of
egress,
but
something
else
is
to
say
what
this
app
is
allowed
in
terms
of
egress,
and
so
maybe
if
we
had
a
dichotomy
such
as
there's
an
egress
request
and
then
the
egress
gets
granted.
D
We
could
even
add
this
to
the
current
system.
If
we
had
our
back
had
the
ability
or
we
split
the
objects,
but
you
know
if
one
way
or
another
we
could
say:
okay,
an
app
can
say
what
it
will
allow
in
and
that
can
say
what
it
would
request
to
go
out.
Somebody
else
gets
to
approve
and
actually
create
the
egress
policy
that
allows
it
or
not.
D
I
think
it's
the
cluster
admin
is
the
one
who
really
cares.
So
a
lot
of
this
is
about
reaching
stuff
outside
the
cluster,
and
it's
really
the
cluster
admin
who's
going
to
say.
I
want
stuff
in
my
cluster
to
be
able
to
reach.
You
know
this
and
not
that
right
because
often
the
click,
the
the
cluster
is
running
in
some
infrastructure
that
the
cluster
admin
wants
to
protect,
but
he
may-
and
he
may
or
may
not
want
to
allow
access
to
some
stuff
right.
Maybe
he
wants
to
allow
free
access
to
the
internet.
D
J
It
seems
like
when
people
talk
about
egress
they're,
almost
always
talking
about.
I
want
to
block
this,
which
is,
is
the
opposite
of
ingress,
where
yeah
you're
talking.
I
want
to
allow
this
to
block
everything
else.
So
yeah
I
mean
I,
I
totally
agree
with
everything.
Mike
just
said.
I
think
we
did
screw
up
with
egress.
D
Yeah
but
again
I
think
I
I
I
do
like
the
positive
you
know
focus.
I
do
think
that's
right.
I
think
we
should
just
try
to
do
egress
right
in
that
in
that
way.
So
I
I
do
think
you
know
that
an
app
deployer
or
developer
knows
what
the
app
would
like
to
connect
to
outside,
but
it's
somebody
else
who
gets
to
say
what
I
want
to
allow.
They
typically
think
about
it
in
a
negative
way.
Right.
Security
is
often
coasters
in
nature.
D
I
want
to
forbid
this
one
forbid
that,
but
it
can
just
as
well
be,
and
often
is
right.
If
you
look
at
firewalls
right,
their
default
deny
and
then
the
firewall
administrator
says
he
wants
to
allow
right.
We
do
the
same
thing
here
with
the
egress
right.
The
app
has
egress
requests
and
then
the
administrator
will
grant
the
egress
requests
that
he
wants
to
grant.
H
G
I
actually
you
know,
you're
all
the
experts
on
this
I'd
love
to
hear
opinions,
but
I'm
like
it
feels
like
this
is
sort
of
what
the
model
that
might
describe
makes
a
lot
of
sense
where
it's
like.
You
know,
there's
a
sort
of
intention
that
you
know
a
developer
may
convey
in
the
network
policy.
You
know
that
they
write
today
and
say
I
want
egress
to,
I
don't
know
internet
and
then
there's.
G
I
don't
know
cluster
number
policy
that
the
platform
admin
writes
and
says:
okay,
app
x
is
allowed
to
do
internet
app
x.
App
y
is
not
allowed
to
do
internet,
and
then
you
know
whoever
white
lists
or
pardon
me
allow
lists
internet.
Then
they
can
actually,
just
you
know,
run
against
the
cluster,
never
policy
and
say:
okay,
it's
denied
or
it's
accepted,
so
it
feels
like
it's
in
different
realms.
Instead
of
expanding
scope
of
number
policy,
it
could
be
two
different
objects
because
it's
being
targeted
at
two
different
personas.
J
D
Right
right,
we
could
do
this
with
new
objects
if,
if
only
we
could
do
something
like
could
we
I've
been
thinking
about
our
back.
You
know
for
years
right,
I'd
like
to
get
our
back
a
little
more
expressive.
What
if
we
got
our
back
to
say
that
you
know
our
back
is
about
what
objects.
Certain
subjects
can
can
actions
that
object.
Subject
can
perform
on
objects.
D
What
if
we
can
allow
some
additional
distinction
on
the
object,
so
so
that
we
can,
for
example,
allow
creation
network
policies
to
specify
ingress,
but
not
creation
of
network
policies
that
specify
egress
right.
That
would
allow
us
to
kind
of
additively
or
without
changing
our
objects,
turn
off
the
ability
to
grant
of
app
deployers
to
grant
themselves
egress
access.
Then
we
introduce
new
objects
which
they
can
request
and
be
granted
egress
privilege.
B
B
We've
had
all
this
other
stuff
about
specifically
like
being
able
to
reason
more
about
why
things
weren't
happening.
This
would
make
solve
that
problem.
Also,
do
we.
D
I'm
not
jumping
to
that
conclusion.
I
think
that's
another
harder
problem.
B
E
E
We're
not
here
to
implement
process.
We're
not
here
to
you,
know,
implement
you
know
or
make
it
like.
Look
pretty
necessarily
in
terms
of
you
know,
visualization
any
of
that
type
of
stuff.
We
just
want
to
make
sure
that
all
the
features
that
are
necessary.
I
hear
what
casey's
saying
about
about
developer
stuff.
I
don't
know
that
I'm
totally
intent
limiting
it
to
one
persona.
E
I
think
there's
going
to
be
different
tools
that
are
going
to
use
this
api
that
may
target
different
personas.
I
just
want
to
ensure
that
whatever
api
we
develop,
you
know
it.
It
satisfies
all
the
necessary
use
cases
whether
that
be
blocking
traffic
or
allowing
traffic.
You
know
from
from
a
developer
perspective
and
do
it
you
know
with
the
most
simple
you
know
semantics
possible
and
then,
if
and
then,
if
other
tools
need
to
build
on
that
fine,
I
just
I
want
to
be
very
careful
that
we
don't.
I
Here
I
think,
if
I
can
summarize
a
little
bit
of
what
I've
been
hearing,
we
think
that
network
policy
went
a
little
bit
outside
of
its
scope
when
it
introduced
egress
support,
because
that
is
really
more
of
a
cluster
admin
or
security
focused
concept
over
the
use
cases.
For
that.
I
So
we're
talking
now
about
one
ways:
to
kind
of
bring
that
back
in
so
remove
that
capability
from
users
of
the
network
policy
api
who
don't
actually
need
that
level
of
privilege,
but
also
how
to
then
provide
that
and
other
security-focused
use
cases
to
the
people
who
do
need
it.
G
I'm
just
gonna
add
another
sentence
to
that.
This
is
exactly
why
egress
gateway's
come
up
all
the
time.
You
know
this
is
where
the
administrator
says.
Oh
yeah
developers
are
doing
egress.
You
know
left
right
and
center.
I
want
all
the
traffic
to
go
through
this
gateway.
However,
that's
deployed
whether
it's
a
vm
or
pods
or
whatever,
and
then
I
can
monitor
all
the
traffic
at
the
l3
l4
l7
layer.
G
Whatever
so
it's
exactly
the
the
need
that
we're
talking
about
this
is
where
egress
gate
was
also
shown.
H
D
D
Yeah
my
remarks
for
attempt
to
synthesize
some
issues
that
were
kind
of
bubbling
through
several
of
the
user
stories.
B
D
B
B
E
You
know,
as
as
part
of
the
api
or
part
of
the
network
policy,
api
right
like,
for
example,
you
know,
as
we
think,
about
personas
or,
as
we
think
about
you
know,
for
example,
we're
talking
about
whether
an
admin
should
be
able
to
block
right.
Is
that
something
that
should
be
in
policy?
Or
is
that
something
that
should
be
handled
by
what
a
I
just
had
a
emission
controller?
E
Sorry,
I
had
a
brain
freeze
right
there
right,
so
it
should
be
handled
by
admission
controller
or
should
be
part
of
policy
as
a
first
class.
You
know,
citizen
to
to
the
api
those
types
of
things
like.
I
think
we
need
to
define
the
principles
that
we're
going
after
here.
Otherwise
we're
going
to
get
a
bunch
of
use
cases
out
there,
but
we
won't
know
necessarily
how
to
make
them
concrete
into
what
we're
trying
to
get
to
from
an
api
perspective.
D
Yeah,
I
think,
actually
part
of
what
you're
saying
that
was
kind
of
getting
into
implementation
or
solution
details
right
I
mean
whether
something's
an
emission
controller
or
not.
That's
the
detail
that
I
could
argue
with
you
know,
but
I
think.
E
That's
true
that
that's
true
I'm
what
I'm
trying
to
get
at,
though,
is
is
it
something
that
you
know
is
is
going
for
an
api
change.
Rather,
you
know.
Yes,
the
mission
controller
could
be
implementation
deal,
but
it
also
speaks
directly
to
whether
this
is
you
know
part
of
the
api
surface,
or
are
we
trying
to
do
something
with
the
api
that
is
not
intended
to
be
done.
H
H
B
B
I
think
we're
gonna
get
back
to
where
we
were
because
before
we
became
official
or
you
know,
we,
we
really
were
getting
close
to
narrowing
down
a
very
a
very
clear
set
of
sort
of
norms
that
that
we
tried
to
adhere
to,
but
we're
kind
of
open
the
funnel
back
up.
But
in
the
next
couple
of
weeks
let's
make
a
let's
try
to
do
that
for
sure
right,
like
maybe
next
week.
You
know
remind
us
of
that
that
again,
because
we
need
to
get
to
that.
That's
that
set
of
principles
to
be
efficient.
H
B
But
I
wanted
to
do
this
this
week
or
next
week
was
like
make
some
concrete
scenarios
up
so
that
we
could
actually
speak
to
something
concrete
and
and
kind
of
maybe
go
so
far
as
to
actually
make
that
a
bar
for
the
use
cases
we
go
forward
with,
like
you
know,
actually
define
like
a
use
case
in
terms
of
an
actual
I've
got
my
sql
running.
I've
got
an
irc
server
running.
I
don't
care
what
it
is,
but
there's
an
actual
application
that
people
can
think
about
and
touch
and
feel
and
say.
Oh
yeah.
B
B
But
if
anybody
has
ideas
on
how
we
can
actually
make
the
bar
for
defining
a
use
case,
a
little
bit
more
structured-
and
you
know
I
I
mean
I
don't
think-
there's
anything
off
the
table
there,
but
any
any
idea
to
make
to
constrain
the
way
that
we
describe.
These
would,
I
think,
be
really
cool
if
we
could
come
up
with
one.
D
I
actually
think
jay
we're
we're
talking
here
in
this
group
about
multiple
kinds
of
things.
One
of
the
kind
of
things
we've
been
focusing
on
which
is
really
kind
of
a
high
level
use
case,
but
we're
also
very
concerned
with
the
actual
expression
in
the
api
people
do
want
it
less
confusing
less
tricky,
less
ugly
yeah.
So
I
I
think
it's
valid.
I
mean
I
think
our
api
is
sharp
edged
just
in
the
way
it's
expressed.
B
Yeah,
so
yeah,
so
how
we
make
things
concrete,
that's
a
good
point,
so
we
can't
just
have
one
way
of
making
things
concrete.
We
might
have
to
have
multiple
ways
of
making
things
concrete,
but
we
should
probably
have
ways
of
making
things
concrete
right,
and
I
agree.
That's
all
I'm
saying
and
if
anybody
has
a
way
to
do
that
for
some
funnel
of
use
cases
that
would
save
us
a
tremendous
amount
of
time.
B
I
think
and
and
it
would
be
fun
it
would
make
it
more
interesting
because
we
could
really
get
straight
to
the
point
of
issue
faster
and
avoid
bike
sharing.
But
I
haven't
been
able
to
think
about
this
yet,
but
I
have
some
ideas:
if
anybody
else
has
any
ideas,
let
me
know,
like
anything,
is
nothing's
off
the
table
activity
diagrams
petri
nets,
whatever
you're
into
you,
know
vague
files,
I
don't
care,
but
yeah,
okay,
cool.
So
what
else
is
there
anything
else?
B
L
B
Okay,
so
let's
see
we've
got,
we
got
30
minutes.
So
let's
try
to
get
through
a
couple
of
these.
I
forgot
okay,
so
let's
go
to
the
the
blank
one
like
like
we
mentioned
now
this
this.
I
don't
know
why
this
is
blank,
because
I
think
this
was
sandor.
K
B
A
I
H
D
Well,
actually,
if
you
look
at
the
fourth,
that's
already
implied
by
the
first
three,
if
the
first
three
are
done,
the
fourth
is
automatic
because
we
have
default
deny
whenever
there's
something
applies.
So
the
only
issue
is
the
first
three
and
for
two
of
them
it's
explicitly
noticed.
That's
expressible,
the
first
one.
You
know
someone
said:
couldn't
we
do
this
with
egress
and
I
said:
hey:
let's
do
this
with
ingress,
you
know
if
you
do
it
with
ingress.
D
What
that
amounts
to
is
someone
has
some
automation
that
says
whenever
a
new
namespace
is
created,
something
automatically
tosses
in
a
network
policy
that
says,
allow
ingress
from
every
pod
to
every
pod
in
this
name
space,
and
that
would
get
you.
You
know
the
first
part,
and
then
someone
can
write
the
spec
that
says,
oh
also,
allow
you
know
the
communication
to
and
from
the
security
gateway.
B
M
Yeah,
that's
what
I
was
that's
where
I
was
going.
I
mean
I
think
my
interpretation
of
this
use
case
is
that
the
tenant
separation
is
kind
of
like
the
namespace
boundaries.
Now,
with
the
network
policies,
you
are
able
to
do
use
namespace,
selectors
and
allow
ingress
egress,
but
you
need
like
a
cluster
admin,
to
be
able
to
sort
of
allow
or
disallow
this
kind
of
communication
between
the
tenants
which
is
like
in
this
case,
probably
could
be
a
name
spaced
scope.
So
that's
my
interpretation,
so
maybe
this
also
kind
of
falls
into
the
cluster
level.
M
J
So
what
you
were
saying
about
openshift
in
in
old
openshift?
We
have
this
multi-tenant
model
that
like
pre-network
policy,
but
when
using
network
policy,
there
is
something
there's.
We
have
something
called
the
project
default
project
template
that
for
user
created,
name
spaces.
You
can
cause
any
number
of
objects
to
be
automatically
created
with
them,
so
it
is
possible
to
have
a
default
set
of
network
policies,
be
created
with
every
new
user
namespace,
and
it
seems
like
something
like
this.
J
Yeah,
I
don't
know
because
yeah
I'm
mostly
only
involved
with
networking
related
features,
and
that's
actually,
you
know
completely.
M
D
No,
no,
you
don't
have
to
worry
about
that
again
if
you're
focused
on
ingress
right.
So
the
if
you
say
that
a
an
admin
in
a
namespace
so
an
admin
of
a
project,
he
has
authority
over
creating
objects
in
a
namespace,
so
he
can
allow
ingress.
I
guess
the
first
thing.
Let's
say
I
guess:
okay
yeah!
You
want
to
take
away
his
ability
to
allow
ingress
from
other
spaces.
Is
your
concern
other
than
that
you're
there,
because
he
can
only
allow
you
know
he?
He
can't.
Let's
see
right.
D
Yes,
if
you
focus
on
control
through
ingress,
you
know
as
long
as
you,
your
administrator
for
a
name
space
doesn't
fail
you
up
by
allowing
ingress
from
someone
other
than
the
security
gateway
or
the
name,
space,
you're
good
and
now.
What
you're
really
saying
is
this
is
a
new
gloss
and
what
or
add
to
what
I
was
talking
about
earlier.
I
think
you
you
so
gopin.
You
are
concerned
about
the
case
of
a
administrator
for
a
new
space
allowing
ingress
from
other
namespaces.
G
I
have
not
heard
the
the
same
side
of
the
ingress,
but
I
I
would
imagine
that
there
is
some
sort
of
an
administrator
requirement
that
says:
okay,
you
know
you
can
only
have
ingress
from
my
non-pii
namespace,
for
example.
You
know
like
if
you're
doing,
multi-tenant
clusters-
and
you
only
want
to
allow
ingress
from
if
you're
doing,
sort
of
tiered
installations,
where
you
have
zones
of
security
say,
for
example,
on
the
same
cluster,
then
you
would
want
to
say
that
okay,
ingress
is
only
allowed
between.
G
You
know,
zone
four
namespaces,
for
example,
or
zone
four
security
workloads.
Things
like
that.
B
D
Well,
the
way
this
item
is
written
actually
prevents
the
namespace
administrator
from
doing
fine
grain
access
control
within
the
namespace,
but
I
think
that's
an
overreach.
I
think
we
want
to
allow
that.
I
think
the
real
concern
here
is
the
cluster
admin
again
wants
to
prevent
this
namespace
admin
from
allowing
too
much
ingress
from
other
namespaces.
B
E
Yeah,
the
only
the
only
thing
a
service
gate
would
be
needed
for
is
authentication
authorization
right.
It's
got
to
do
some
type
of
l7
on
operation
there,
where.
D
Well
again,
I
think
this
thing
needs
to
be
clarified
by
roles.
You
know
what
is
it
that
the
app
deployer
or
developer
gets
to
say
what
is
it
the
cluster
edmund
gets
to
say,
because
I
think
the
real
point
here
is
that
he
wants
a
cluster
admin
to
be
able
to
forbid
some
stuff,
even
even
though
a
namespace
administrator
tries
to
get
it
and.
D
D
B
B
Know
it's
like
really
hard.
It's
really
complicated,
but
yeah
red
doesn't
mean
we
can't
do
it
though
red
just
means
we
need
someone
to
own
it.
A
little
more
so,
okay.
F
So
hold
on
a
second
before
we
move
on
sorry,
I'm
just
kind
of
like
still
getting
caught
up
on
this
stuff,
but
so
the
previous
proposal
basically
was
not
just
proposing
a
few
use
cases,
but
it
was
partly
proposing
a
completely
new
service
that
security
gateway
thing
right.
D
D
The
security
gateway
is
something
that
cluster
edmond
brings
to
the
party
they
ask
here
is
that
we
enable
the
security,
the
cluster
admit,
to
force
things
through
his
the
stuff
he
breaches
the
party
got
it.
D
B
Yeah,
it's
more
of
a
matter
of
control
than
anything
else.
Okay,
we
have
15
minutes
left,
I'm
gonna
see
if
there's
anything
blank
and.
B
I
feel,
like
things
have
things
are
starting
to
settle
in
now,
where
I
think
we
can
start
to
get
a
little
more
structured
again
like
for
cody's
comment,
but
I
don't
see
any
other
blank
ones,
and
so
I
think
what
I
think.
What
we
need
to
do
is
assume
that
the
red
ones,
unless
somebody
wants
to
bring
one
up
specifically,
we
just
we're
not
gonna,
spend
extra
time
on
them
and
we're
gonna
really
focus
on
the
green
ones.
I
think.
B
Exactly
yeah
because
the
red
ones
are,
as
is
sort
of
by
default,
lower
lower
priority
simpsons.
We
just
don't
know
what
to
do
with
them.
B
B
Not
confusing
at
all
orange
equals,
yellow,
oh
my
god,
I'm
not
gonna
write
anything
okay.
So
here
we
go
none,
okay,
just
to
clarify
okay
cool,
so
we
can
go
to
the
yellow
ones
right,
and
I
think
what
we
should
do
is:
let's
just
quickly
tally
how
many
yellow
ones
we've
got
one
now,
why
are
these
green?
B
Oh
comes
the
comment.
Okay.
B
Oh,
these
color
codes
are
really
bad,
so
I
need
to
fix
these
color
codes.
So,
basically
anything.
That's
not
that
perfect,
beautiful
green,
like
this
is,
is
yellow.
I
think,
does
anybody
care
if
I
move
the
red
ones
to
the
bottom.
H
H
Okay,
I
think
some
of
the
colors
were
set
before
this
group
kicked
off
and
I
don't
think
we
got
the
we
got
input
from
the
broader
group
on
on
what
they
should
be
okay,
but
I
also
think
that
a
lot
of
these
are
duplicated,
like
the
admin
policies
comes
up,
multiple
times
just
boarded
differently,
and
I
wonder
if
that's.
B
And
the
colors
are:
don't
have
any
intrinsic
value
really
I
mean
they
were
just
the
initial
way.
We
were
triaging
things.
I
assume
there'd
be
another
level
of
triage,
that's
more
official
that
we're
going
to
do
next.
So
maybe
we
should
move
past
colors
and
actually
say:
what
are
we
really
trying
to
do
here
like
do
do?
Should
we
go
through
them?
Is
colors
the
right,
I'm
happy
to
go
through
all
the
use
cases
again.
Do
we
want
to
rate
them
by
color,
or
is
there
some
more
semantically,
valuable
way
of
categorizing
these
things?
B
That's
maybe
a
little
more
objective
like
I
like.
Should
we
be
tagging
them?
Should
we
be
because
there's
there's
metadata
associated
with
these?
That's
lost
in
one
dimension,
categorization.
H
What
I
would
prefer
to
do
actually
is
do
like
comment
based
comment
based
voting.
So,
like
you
know,
people
just
plus
one
on
the
comments,
and
you
know
whichever
user
stories
have
the
most
plus
ones.
We
can
maybe
talk
about
those
in
more
detail,
but
I
think
we
need
to
consolidate
some
of
these
destroyers
first
before
we
go
there.
M
D
Yeah,
in
other
words
again,
I
think
we
need
to
be
moving
to
synthesis.
I
mean,
I
think
you
know
once
we've
taken
kind
of
a
rough
everybody's,
looked
at
these
user
stories
and
got
a
rough
idea
of
what
they're
about
not
not
just
a
fairly
good
idea
of
what
they're
about.
I
think
the
next
thing
we
need
to
do
is
some
more
synthesis
and
organization,
because
we're
not
going
to
address
you
know
two
dozen
use
cases
right,
we're
going
to
think
about
a
few
big
ideas
here
and
what
we're
going
to
do
about.
B
B
E
H
B
I
E
B
B
If
nobody
shows
up
later
this
week
at
that
time,
then
we
do
it
all
independently
that
way,
if
folks
want
to
talk
through
it,
they
can
do
it,
but
it's
not
part
of
this
official
meeting
and
I'll
just
say
I'll,
just
throw
a
timeout
say
wednesday,
at
the
same
time
that
we're
doing
now
so
I'll
go
through
these
myself.
During
that
time,.
H
H
And
then
I
think
at
that
point
we
might
be
good
to
just
have
people
review
it.
Asynchronously
and
and
do
comment
based
voting.
B
Yeah
I
mean:
do
we
want
to
keep
this
format?
I
feel
like
this
is
a
very
bloated
format.
For
what,
for
the
amount
of
information
we
have,
I
feel
like
text
would
be
better,
but
the
comments
here
are
nice.
I
don't
know
you
want
to
do.
I
guess
comment
based
voting.
You
need
google
docs
for
right.
A
B
Okay,
yeah,
let
me
let
me
just
I
can
I
can
try
to
go
through
these
and
I
can
try
to
clean
these
up
a
little
bit
and
then
I
will.
What
should
we
do
next
next
time
it's
4
50
now,
so
this
calls
pretty
much
done.
What
should
our
agenda
be
for
the
next
call?
D
B
I
L
We
can
we
can
ask
an
alternative
repository
as
service
api
is
doing.
Maybe
like
inside
kubernetes
seeks
yeah.
I
mean
we'll
start
with.
B
B
E
I
don't
know
that
the
selection
of
tool
necessarily
solves
our
problem
here.
I
I
think
that
you
know
maybe
one
way
to
look
at
is
we
just
create
a
new
dock
with
the
synthesized
use
cases
and
give
each
author
each
use
case
author
a
chance
to
go
through
and
and
work
on
their
stuff
there,
and
then
we
could
reference
back.
This
one
is,
you
know,
has
a
lot
of
comments
and
a
lot
of
stuff
in
it.
E
We
just
need
to
pull
all
this
into
one
dock
that
maybe
is
a
fresh,
a
fresh
look
at
where
things
are
combined
without
having
to
go
through
the
whole
effort
of
switching
the
tooling
machinery
right.
I
don't.
I
don't
want
to
slow
us
down
shifting
everybody
to
github.
Yet
if
we're
still
collaborating.
H
E
B
Gonna
take
some
yeah,
so,
okay,
I'm
gonna,
look
at
these
and
I'm
just
gonna
dive
into
these
and
start
cleaning
them
up.
I
think
that's
the
best
we
can
do
right
now.
I
don't
think
it's
worth
debating
github
or
not,
unless
we
all
agree
one
way
or
another.
B
So
let's
keep
the
doc
the
way
it
is,
and
I
just
let
me
let
me
spend
some
time
on
this
cleaning
it
up,
making
it
making
it
just
making
it
better
right
without
and
I'll,
try
not
to
be
not
to
impose
any
opinions
on
it,
and
just
actually
just
do
my
best
to
to
clarify
these
and
actually
spend
some
time
on
it,
because
I
actually
haven't
been
able
to
spend
any
focus
time
on
cleaning
these
up.
E
B
Yeah
and
we
have
that
spread,
but
that
didn't
really
solve
yeah.
It
just
needs
love,
it
needs
work,
so
we
got
to
work
on
it.
So
I'm
going
to
work
on
this.
If
anybody
wants
to
work
on
this
with
me,
let
me
know,
but
if
not
I'm
just
going
to
own
working
on
this
and
making
it
as
as
ingestible
as
possible
and
yeah,
I
I
may
have
to
take
some
creative
license
to
change
things
around,
because
otherwise
we'll
never
get
anywhere.
H
B
B
B
But
it's
gonna
get
we're
gonna
we're
gonna,
get
we're
gonna
we're
gonna,
get
where
we
want
to
be
in
a
few
weeks
in
terms
of
getting
our
rhythm
and
back
so
oh
and
cody's
gonna
help
me
that's
so
sweet
of
you,
cody
cody,
yeah,
so
reach
out
on
slack
and
we'll
hang
out
and
do
this.
I
don't
want
to
do
it
all
by
myself
and
anybody
else
and
then
that's
that's
good
enough.
Oh
there's
a
lot
of
comments
here.
Oh
here's,
ricardo!
B
Okay!
I
think
we
can
end
this.
It's
4
59.!
You
guys!
You
all
get
one
one
minute
back!
Thanks
everybody
for
coming
and
we
will
see
you
next
time.