►
Description
Join jay, abhishek, and stoyocos as we dig into the internals of a couple of KEPs that are setting the stage for the future of the Kubernetes security model!
- 00:01:00 Intro
- 00:02:58 News: VMWare Tanzu 1.4 is out!
- 00:06:11 RWM RWO storage volumes to Single Pod Access
- 00:11:00 Tim Hockins (Google) surprise guest !
- 00:15:00 trying to patch my golang
- 00:18:00 NetworkPolicy WG what's up
- 00:19:30 quick GKE overview of enhanced networks
- 00:25:00 there's lots of problems with Services
- 00:30:00 "proto loadbalancer" ExternalIPs
- 00:32:00 svc type LoadBalancers evolution
- 00:35:00 EndPort fields
- 00:38:00 Are EndPorts still alpha?
- 00:41:00 Kind allows you to easily declare FeatureGates for Kubernetes!
- 00:55:00 bypassing namespace restrictions
- 00:56:00 Tenants and future ClusterScoped NetworkPolicies
- 01:00:00 Empowerment vs Priority based policies for the future
- 01:07:00 more on tenants and namespaces
- 01:13:00 delegating to lower level network policies
- 01:20:00 PSPs, OPA, and the future of PSPs
- 01:25:00 how does the Kubelet deal with PSps, how will it in the future?
A
A
So
here's
everybody.
The
comments
are
flowing
and
hey
martin
from
the
netherlands.
What's
up
scottsdale
krk4,
I
went
to
the
u
of
a
that's
where
I
went
to
look
at
my
look
at
my
hat
scottsdale.
Look
at
this,
I'm
wearing
an
asu
hat
right
now,
okay,
good
martin
likes
the
way
it
sounds
okay.
So
so
we
got
a
bunch
of
people
coming
to
hang
out
today,
ricardo's
here
hanging
out
on
the
sidelines:
what's
up
ricardo,
we're
gonna?
A
A
I
think
he
just
joined
he's
from
red
hat
and
stoica
is
from
red
hat
also,
and
so
we
got
most
of
the
network
policy
working
group
here
to
hang
out
today,
but
we're
gonna
we're
also
sanjeev
how
you
doing
man
you
want
to
do
a
little
sound
check
and
make
sure
your
audio
is
doing.
Okay,
we're
live
already,
so
hey
everyone,
yeah
good
to
go
cool.
A
A
We
we
go
through
all
this
stuff
and
we're
gonna
go
through
a
lot
of
policy
related
stuff,
both
network
policy
related
stuff,
but
also
pod
security
policy
stuff,
because
that's
all
changing
and
like,
I
think,
there's
some
kept
updates
that
have
sort
of
that
have
sort
of
flown
into
the
new
like
next
generation
of
what
pod
security
policies
are
gonna
look
like
whatever
they're
called
I'm
not
even
sure
exactly
what
they're
called
now.
Here's
the
cap,
and
so
we're
gonna-
also
look
at
these
today,
but
like
before.
A
We
do
that
we
can
just
do
a
quick
look
at
the
week
in
review,
so
some
of
you
might
know
tkg
1.4
is
out,
and
I
don't
really
have
much
else
in
the
week
in
review
today.
This
is
an
interesting
blog
post,
though,
that
I
just
saw
a
single
pod
access
for
persistent
volumes,
so
for
folks
that
so
ameem
yusuf.
A
What's
up?
Okay,
so
for
folks
that
are
like
new
to
persistent
volume
stuff
like
we've
got,
we've
got
like
so
we've
always
had
different,
like
we've
always
had
read,
write
once
read:
write
many
volumes
like
those
have
always
been
around
in
kubernetes
first
since
forever,
and
so
that's
nothing
new,
and
so
like
there's
this
new
single
pod
access
volume
for
persistent
volume,
so
anybody
that's
tried
sanjeev,
I
think
you've
lost.
A
I
think
we
lost
sanjay
but
he's
back
again
so,
okay,
choco
pod
security
admission
is
that
it
I
don't
so
what
this
pods
yeah
we're
gonna
get
into
it
in
a
second
choco.
I
don't
know
much
about
it:
either.
It's
jordan,
jordan,
liggett
and
some
other
people
are
driving.
This
thing
upstream,
that's
gonna
be
like
the
next
generation
of
the
security
policies
for
pods.
So
so
we'll
look
at
how
people
use
psps
now
they're
getting
deprecated,
and
I
think
in
1.25
they're
going
away
and
then
in.
A
What
is
it
and
then
eventually
they're
going
to
get
replaced
with
this
other
thing,
which
will
which
we'll
look
at
together
and
we'll
learn
about
together,
because
that's
kind
of
that's
kind
of
a
new
thing
for
me.
Also
so
we'll
see
if
we
can
look
at
the
cup
and
try
to
read
it
and
try
to
look
at
I
I
I
got.
C
A
We
can
dig
into
the
code.
Maybe
we
can
learn
something
there,
because
I
think
right
now.
Pod
security
policies
are
implemented
as
an
admission
controller
inside
of
the
inside
of
core,
but
I
don't
even
know
so
anyways.
So
we
can.
We
can
look
around
and
see
how
they're
implemented
later
so,
but
back
to
the
news.
So
what's
going
on
this
week,
so
yeah.
The
first
thing
I
just
saw
this
is
september
13th.
This
is
a
blog
post
that
recently
came
out
and
on
k8s.io
and
it's
about
access
mode.
A
So
it
looks
so
so.
Persistent
volume
claims
you've,
probably
if
you've
done
kube
for
a
while
you've,
probably
set
up
a
persistent
volume
claim
and
done.
One
of
these
before
with
the
read,
write
many
or
read
write
once
most
people
read
write
once
because
most
storage,
unless
you're
using
gluster
or
nfs,
is
read,
write
once
and
so
like
I
know,
stoicas
knows
all
about
gluster,
because
I
know
that
his
boss,
steve
watt
at
red
hat,
is
a
old-school
gluster
guy,
so
anyways
so
read.
Write.
A
A
B
A
So
if
this
is
a
read,
write
once
pvc
right
then
actually
like
both
of
these
pods,
I
don't
have
my
apple
pencil
today.
I
lost
it.
I
don't
know
where
it
is.
Both
of
these
pods
will
then
be
able
to
write
to
the
same
volume
and
so
the
single
access
mode.
The
idea
behind
that
is
that
you,
you
can
have
this
pvc
and
then
you
can
only
and
now
only
one
pod
in
your
entire
cluster,
no
matter
what
node
these
are
on.
A
So
even
if
these
are
on
the
same
node,
only
one
pod
can
write
to
it.
So
that's
like
a
new
thing
and
I
suppose
that's
probably
the
thing
that
most
people
usually
want
when
they
do
read,
write
once
pods
like
volumes
right,
so
because
why
would
you
do
read
write
once
if
you
intended
two
two
different
containers
to
write
to
it?
Tim's
here,
oh
tim,
what's
up
so
good
afternoon,
everybody
it's
great
okay!
So
it's
great
tim's
here
we've
got
like
a
ton
of
people.
A
A
D
A
A
B
A
D
A
You
have
a
migrate
for
anthos
how
bleep.
Well
we
got
a
lot
of
stuff
going
on
well
yeah.
If
you
got
something
interesting,
go
ahead
because
we're
doing
news
for
the
week
and
then
there's
go.1.17,
that's
not
new,
that's
not
new
at
all.
I
think
it
came
out
like
a
month
ago,
but
I
haven't
updated
yet
so
I
figured
I
was
just
talking
to
stoichus
and
he
hasn't
updated
either.
A
So
I
figured
I
might
as
well
see
what
happens
if
I
try
to
update
it,
because
I
can't
build
kate's
right
now,
because
I
don't
have
ghost
71.17
so
it's
time
to
update.
So
I
figured
I'd
put
that
in
the
news
for
the
week
and
then
see
if
I
could
figure
out
how
to
update
it
and
maybe,
in
the
meantime
tim
will
have
some
updates
for
us,
so
golang
1.17.
A
B
A
Yeah
well
see
if,
if
tm
had
yeah,
if
he
was
the
first
person
to
join
like
you
andrew
stoykis,
it
would
have
been
different.
He
would
have
had
different
okay
hold
on
so
okay,
so
this
downloaded.
So
I
downloaded
my
my
see
and
I
get
the
thingy
okay.
This
should
be
easy.
I
think
it
just
adds
it
to
my
path.
A
A
B
A
A
This
doesn't
look
like
a
good
idea
to
do
right
now.
I
think
I'd
rather
just
check
out
kubernetes
1.21,
all
right,
so
cd
go
ls
all
right,
so
there's
the
bin,
the
binaries.
So
what
happens?
If
I
just
can
I
just
copy
go
into
my
which
go?
Can
I
just
copy
it?
There
cp
go
unless
I'm
doing
something
really
weird,
it
won't
break
anything
right.
A
I'm
not
formatting
anything,
it's
just
proper
is
that
it
was
that
what
it
worked
there
you
go,
then
what
happens?
Can
I
do?
Can
I
do
stuff
now?
I
don't
know,
let's
see,
okay,
so
you
don't
need
to
like
click
on
the
actual
go
logo
and
do
all
that,
oh
god,
it
didn't
like
that
all
right,
so
I
gotta
do
there's
a
bunch
of
other
binaries
right.
So
what
else
do
I
have
to
copy?
D
A
A
D
A
E
E
A
E
A
A
Okay,
now
I'm
up
to
date
come
on
all
right.
Here
we
go
so
I'm
not
going
to
spend
too
much
time
on
it
here
because
we
got
so
many
networking
people
here
that
I
think
I
want
to
dig
into
the
network
stuff.
First,
so
we'll
see
if
this
works,
but
if
not
we'll
do
some
networking
stuff
and
then
we
can
talk
about
talk
about
the
updates.
A
The
pod
security
policy
updates
that
people
are
doing,
and
so
what's
up,
what's
up
vlad,
you
said
you
were
gonna,
hang
out
with
me
sometime,
maybe
next
time.
Next
time
I
do
one
you're
going
to
come.
Hang
out
with
me,
flad's
here,
sono
buoy
guy,
I
choose
the
official
okay
noel.
You
use
the
official
tarball
for
your
default
and
gvm
for
the
others.
Okay,
eleven
chapter,
the
pr.
What's
up
carlos
okay
cool,
I
didn't
know
there
was
a
product,
a
book
club
for
kubernetes.
A
I
I'm
not
in
that
book
clyde.
I
don't
read
anything
so
I'm
not
in
any
book
clubs
would.
Would
you
please
zoom
in
the
terminal
font,
yeah
moz,
yes,
sir,
so
I
figured
before
we
dug
into
the
network
policy
api
stuff.
We
could
talk
about
some
of
the
existing
stuff
and
since
tim's
here
tim
like.
What's
the?
What
do
you
so
like?
If
I
make,
what
do
you
do
on
top
of
the
network
policy
apis
in
gke
or
in
gce,
for
containers.
A
D
A
Yeah,
okay
cool!
So
it's
good
that
it's
good!
That
we've
got
those
folks
here
today!
So,
okay,
all
right!
So
normally
and
I
make
a
gke
cluster
I
can
make
psyllium
or
calico
and
then
the
gce
cni
or
the
gke
cni
that
you
all
have
is
just
pod
networking
really
really
fast
native
google
pod
networking
right.
That's.
A
D
We
still
have
istio
via
what
we
call
antho
service
mesh,
which
you
can
ignore
the
the
word
anthos
there,
but
you
can
you,
can
you
can
use
istio
on
gke
and
get
you
know
all
the
cool
stuff
that
istio
offers?
If
you
want
right?
So
that's
a
it's.
A
pretty
big
step
function
for
like
adoption,
so
we've
got
some
stuff
sort
of
in
between
right.
We've
been
playing
with
this
multi-cluster
services,
stuff
that
the
sig
multi-cluster
put
together.
So
you
can
throw
that
on.
D
B
Should
we
talk
a
little
bit
of
more
about
the
sorry,
I
didn't
mean
to
interrupt
you.
I
was
just
saying:
maybe
everyone
here
doesn't
know
some
of
the
holes
that
are
with
network
policy.
I
know
you
kind
of
started
this
off.
Asking
tim,
like
does
gk,
do
something
special
for
you
know
the
things
that
are
lacking
in
network
policy.
Maybe
we
want
to
talk
more
about
those
holes.
A
We'll
get
into
the
holes,
let's
do
it
all
right,
so
all
right,
so
we've
got
all
right
yeah.
So
so
we
let's
go
and
let's
look
at.
We
had
a
bunch
of
asks
right
like
do.
Where
are
those
asks
now?
There's
the
network
policy
working
group
sub,
there's
like
a
do.
You
have
a
new
markdown
of
this
or
do
we
have?
I
remember
we
had
one
a
long
time
ago
that
I
had
on
my
repo,
but
you
had
one
a
new
one
right.
We.
B
A
Are
all
the
ones
that
I
remember
because
we
went
through
these
name?
Is
policy
target,
so
that's
one
that
we
recently
added,
and
that
was
actually
thanks
to
tim,
showing
me
how
to
do
it,
but
like
what
now
you
can
you
can
target
a
network
policy
by
its
name?
There
was
ingress
rules
targeting
services.
D
That
one
goes
way
back
to
like
the
very
beginning
of
network
policy
right.
There
was
some
discussion
before
we
ga
the
api
in
the
first
place
about
whether
the
targets
should
be
a
pod,
selector
or
services,
and
you
know
we
chose
at
the
time
pod
selector
because
it
was
most
flexible.
In
hindsight,
I
wonder
if
that
was
really
the
right
choice.
D
We
thought
it
was
the
most
flexible,
it
is
the
most
flexible,
and
sometimes
flexibility
is
a
something
you
have
to
carry
around
with
you
forever
and
it
makes
you
know
it
makes
some
of
the
implementations
or
possible
implementations
a
little
bit
complicated
and
honestly.
It
makes
it
sometimes
a
little
difficult
for
people
to
reason
about.
Why
do
I
have?
D
B
D
At
the
time
it
came
up
pretty
late
in
the
process
as
a
as
a
conversation,
and
we
didn't
want
to
change
tracks
and
we
didn't
want
to
delay
the
rollout
any
later.
There
was
some
pressure
you
know
and
again
in
hindsight
it
was
maybe
a
little
bit
artificial,
but
there's
some
pressure
that
we
imposed
on
ourselves
to
get
this
ga
by
a
certain
time
frame,
and
so
we
we
succumbed
to
that
pressure
and
we
launched
the
way.
It
is
that's
not
to
say
it's
bad
right
like
here.
A
C
As
a
you
know,
I
just
had
a
thought
about.
You
know
if,
if
you
had
to
go
back
in
time
and
think
about
doing
this
differently,
where
you
extract
the
selection
part
of
the
back
ends
into
a
crd
of
its
own,
like
a
group
and
then
reference
those
group
into
services
and
then
reference
the
same
groups
into
network
policies.
Would
that
decoupling
of
the
the
job
would
that
be
something
that
would
you
know,
make
make
life
of
people
easier.
D
The
the
implications
of
that
are
wide.
Adding
features
to
services
is
now
very
complicated
because
there's
too
many
cross
checks
and
conditions
and
intersections
of
features,
and
we
make
even
adding
new
features
today
where
we
know
where
all
the
we
think
we
know
where
all
the
landmines
are.
We
still
occasionally
blow
our
feet
off,
because
it's
just
so
complicated.
I
just
went
through
a
massive
cleanup
of
the
service.
D
Rest
stack
where
I
added
about
12
000
lines
of
tests
and
in
the
process
found
a
bunch
of
you
know
corner
case
bugs
that
we
had
missed
in
validation
and
cross-checking,
initialization,
etc.
So
I
think
service
does
too
many
things.
If
I
could
go
back
in
time,
I'd
probably
say
we
need
a
grouping
construct
and
then
we
need
a
bunch
of
ways
to
get
into
that
grouping
and
it
might
be
surprising,
but
that
was
what
ingress
was
supposed
to
be.
A
D
D
We
need
to
do
some
other
refactoring
within
the
stack
to
make
it
possible
to
replace
cluster
ips,
but,
like
antonio,
has
been
doing,
this
work
around
changing
the
way
the
ip
allocator
works,
which
I
think
really
conveniently
fits
into
this
gateway
model.
So
we'll
need
to
figure
out
how
node
ports
will
also
fit
into
that.
D
That
that
is
one
of
the
oldest
remaining
warts
in
the
system
that
way
predates
1.0,
and
I
I
won't.
I
won't
point
any
fingers,
but
it
was.
It
was
added
as
a
way
to
manually
set
up
load
balancers
before
we
actually
had
load
balancer
support,
so
you
could
come
into
your
service
and
say
I
have
configured
this
other
ip
address
through
some
mechanism
that
you
don't
know
anything
about.
Yeah
I've
configured
it
to
route
here.
D
D
Load
balancer,
and
we
you
know
just
in
santa
barbara-
and
I
remember
these
conversations
very
clearly
like
arguing
about-
is
it
stacked?
Is
it
concentric
circles?
Is
it
orthogonal?
How
are
we
going
to
make
this
api?
So
it's
not
crazy,
ridiculously
complicated
and
we
ended
up
with
this
sort
of
concentric
model
that
we
have
now
and
probably
we
ought
to
have
removed
external
ips
at
the
time,
but
we
for
whatever
reason
we
didn't.
A
Yeah
like
if
you
yeah,
because
it's
real
confusing
when
you
think
about
it,
because
I
guess
there's
three
different
ways
that
we
could
come
up
with
to
do
load
balancing
like
sort
of,
if
you
think
of
it
at
this
level.
I
don't
remember
what
these
arbitrary
lines
are,
that
we
drew
as
boundaries.
But,
like
you
know
you
could
you
could
like
you?
Well,
you
could
do
node
ports
and
you
could
just
do
it
manually
and
then
you
could
actually
make
a
cloud
load.
D
D
You
trust
the
other
people
you're
using,
and
you
know
in
the
real
world
that
doesn't
fly
very
far
and
so
what
we,
what
we
lacked
in
there
was
something
that
the
load
balancer
type
actually
does
have,
which
is
a
sort
of
request
and
response
model
right.
I
can
request
through
my
service
a
load
balancer.
I
can
even
request
a
specific
ip
address,
but
something
that
is
more
privileged
than
me
has
to
confirm
that
I've
been
granted.
That
and
external
ips
just
doesn't
have
that.
D
I
see
in
the
in
the
comments
right
folks
are
saying
that
you
know
external
ip
is,
is
cool
and,
like
you
can
do
really
interesting
hacks
with
it
and
that's
the
part,
that's
scary
right.
Yes,
you
can,
you
can
show
services
and
other
name
spaces
and,
as
soon
as
you
say,
cross
namespace,
something
I'm
immediately.
D
Scared
because
we
have
another
cve-
that
is
all
about
cross
namespace
exposures
when
they
ought
to
be-
and
you
know,
confused
deputies
and
bypassing
policy,
and
you
know
so
at
this
point-
I'm
pretty
down
on
cross
namespace
anything
because
it's
just
so
fraught.
Interestingly,
there's
a
proposal
that
rob
scott
from
the
gateway
working
group
just
floated
with
sig
off
to
consider
a
more
general
method
of
reference
policies
for
enabling
for
one
namespace
to
be
able
to
say.
D
Well,
it's
a
it's
a
cr
in
the
gateway
space
right
now,
okay,
the
question
to
sigoth
was
like:
should
we
generalize
this
because
it
also
applies
to
other
caps
that
are
in
flight
like
the
the
bucket
provisioning
kept
needs,
the
exact
same
pattern,
and
so
the
question
was
like:
should
we
should
we
generalize
it?
Should
we
make
it
like
a
built-in
type
that
we
recommend
anybody
who
does
cross
namespace
stuff
pursue
and
the
feedback
was?
A
Okay,
all
right
so
now,
okay,
so
all
right!
So
now
I
feel,
like
we've
got
some
of
the
stuff
with
policy
like
there's,
port
ranges,
ricardo
did
that
so
now
we
do
have
in
in
in
upstream
now
we
do
have
the
ability
to
make
port
range
policies
so
like
let's
we
can.
Maybe
I
think
we
can
look
at
the
port
range
policy
kept
right.
Port
ranges
or
endport
is
what
it's
called
right
and
ricardo.
If
you're
there
do,
you
have
like
a
yaml
snippet.
I
can
borrow.
A
B
A
A
A
A
B
A
B
A
D
B
Get
up
in
here
man,
so
jay,
while
you're
doing
this
stuff.
I
do
have
a
question
for
tim.
Like
you
talked
about
how
you
know
gateway
gateway,
api
is
looking
at
putting
smaller
pieces
of
functionality
into
each
object
or
each
resource
right.
When
do
we
see
that
becoming
a
problem,
because
I
think
we've
been
having
the
same
conversations
in
network
policy
like
we
would
rather
have
more
resources
with
explicit
behaviors
than
less
resources
with
a
wide
range
of
behaviors
that
can
be
interpreted
differently.
D
Totally
a
spectrum
where,
like
either
end,
is
going
to
be
terrible
right,
so
I
think,
with
ingress,
we
tried
really
hard
to
stay
with
one
resource
as
simple
as
we
could
possibly
get
away
with
lowest
common
denominator,
and
we
all
know
how
that
played
out
yeah.
It
worked
worked
for
a
while,
but
it
turns
out
everybody
pokes
holes
in
it
and
does
something
implementation
specific.
D
So
you
could
go
the
complete
other
end
and
say
like
every
line
of
your
nginx
config
becomes
a
different
resource
or
every
stanza
becomes
a
different
resource,
and
I
think
that's
also
madness
right.
So
what
I
think
the
gateway
process
has
done
really
well
is
breaking
down
the
the
problem:
space
normalizing,
the
the
data.
D
It's
really
a
data,
normalization
problem,
right,
they've,
sort
of
normalized
the
data,
but
then
aligned
it
with
who
is
going
to
be
using
which
parts
and
they've
gone
through
their
use
cases
in
the
context
of
like
who,
what's
a
cluster
admin,
going
to
do?
What
is
a
developer
going
to
do
and
how
do
those?
How
does
that
influence
the
split
and
then
they've
sort
of
strategically
denormalize
the
data?
And
so
we
can
put
all
these
things
together
into
one
resource,
because
they're
being
operated
on
by
the
same
people
they've
also
provided
a
lot
of
flexibility.
D
There's
a
lot
of
things
that
are
like
you
could
express
it.
You
know
as
a
list
of
a
with
a
bunch
of
b's
or
a
list
of
b's
with
a
bunch
of
a's
and
both
are
valid
representations
depending
on
you
know,
which
is
most
important,
and
this
is
an
age-old
discussion
with
proxy
configs
right.
Is
it
the
virtual
host
and
then
the
listeners,
or
is
it
the
listeners
and
the
virtual
hosts
right
and
so
they've
they've
made
it?
D
So
you
can
specify
it
sort
of
either
way,
and
I
think
it
plays
nicely
if
you're
an
app
developer.
You
can
do
just
the
things
that
an
app
developer
cares
about
like
defining,
take
this
url
path
and
map
it
to
this
service
and,
if
you're,
an
administrator,
you
can
say,
listen
on
this
port.
Accept
this
tls
certificate
map,
this
wild
card
and
those
are
different
resources.
B
Cool
great,
that's
awesome,
and
I
think
you
know
you
hit
the
nail
on
the
head
with
the
persona.
Like
you
know,
in
terms
of
network
policy
at
least
like
we've
only
had
a
policy
designed
for
the
developer
right.
So
then
we
have
the
admin
making
policies
that
weren't
designed
for
the
admin,
but
the
developer's
happy,
which
is
awesome,
because
we.
A
D
I
think
that
I
mean
you
hit
it
on
the
head
too
right.
It's
like
kubernetes
was
always
about
app
developers
from
the
beginning.
That
was
always
our
focus
and
when
we,
you
know
when
we
designed
network
policy,
it
was
very
much
a
discussion
of
like
I
don't
think
app
developers
need
that
level
of
flexibility.
One
of
the
proposals
for
network
policy
in
the
beginning
was
looked
a
whole
lot
like
ip
tables
like
with
arbitrary,
allow
and
deny
and
jump,
and
yes,
it's
like
like,
let's
not
encode
ip
tables
and
yaml
right.
D
Most
people
are
not
going
to
need
that
and
I
think
we've
done
pretty
well
within
network
policy
of
defining
app
rules,
but
now
we've
crossed
the
chasm
perhaps
and
we
need
more
control,
and
so
I
think,
where
cluster
network
policy
is
is
interesting,
is
I
keep
calling
it
the
guard
rails
on
network
policy
right?
I
want
to
give
my
app
developers
freedom,
but
only
though
so
much
freedom
right.
D
There's
a
question
in
the
in
the
comments.
I
don't
know
how
to
respond
to
comments,
so
is
the
new
gateway
api
allowed
to
route
based
on
http
method
verb
and
handle
policies
for
it?
Yes,
I
think
so,
but
I'm
not
a
hundred
percent
sure
that
verb
is
implemented
yet,
but
it's
definitely
been
discussed
and
there's
a
million
extension
points
built
into
that
stack
now.
So
I
would
definitely
go
look
at
the
gateway
docs.
I
just
did
an
api
review
for
them
and
something
about
verb
sticks
out
in
my
head.
C
C
A
What
can
I
oh?
I
killed
my
cluster
just
now.
I
have
to
hold
on
okay,
so
kind
local
up.
So
this
is
my.
I
have
a
secret
thing.
I'll
show
you
y'all
can
use
this.
I
think
I've
showed
it
to
folks
before
it's
this
and
if
you
go
in
here,
it's
kind
and
me
and
ameem
kind
of
maintain
this.
It's
a
thing
where
you
could
just
glue
kind,
local,
up
and
it'll
create
a
cluster
with
andrea
or
psyllium
or
calico
or
whatever
are
unkind
for
you.
So
it's
just
a
single
script.
You
don't.
A
If
you
put,
I
only
did
it
one
time
because
I
was
like
to
convince
antonio
to
let
me
merge
the
network
policy
test.
I
was
like
I'll
make
them
work
on
oven,
so
I
downloaded
it
and
it
was
all
python
and
I
couldn't
figure
out
what
do
I
need
to
do
to
get
this
thing
in
here.
So
if
you
could
pr
that
in
here,
I'd
love
that
yeah,
let's
do
it
yeah
k8s
prototypes
kind.
That's
the
thing.
A
A
So,
okay,
so
I'm
trying
to
do
this,
I
enabled
the
feature
gate
so
for
folks
that
use
kind
to
play
with
stuff.
I
didn't
know
it
was
this
easy
to
do
feature
gates,
but
I
just
so
what
I
did
is.
I
just
looked
gripped
through
the
code
and
I
found
the
feature
gate
for
endpoint
report,
but
in
kind
you
can.
Oh
god
I
didn't
mean
to
do
that.
Okay,
I
guess.
A
A
I
think
it's
that
it
writes
this
file,
so
actually
in
this
script
yeah,
I
think
it
like
writes
the
yeah
that
was
stupid.
I
have
to
do
it
in
here.
There
you
go,
so
this
thing
is
kind
of
hacky.
So
don't
don't
make
fun
of
me.
So
it's
called
the
feature.
Gate
is
called
and
network
policy
and
port.
That's
the
feature
gate
name
so,
whether
or
not
policy
and
port,
and
I'm
assuming,
if
I
send
a
bad
feature,
gate
name
to
k8,
it's
going
to
blow
up
right.
A
A
Working
ricardo
also
got
it
working
in
calico,
so
it's
kind
of
interest
like
when
you're
adding
a
new
network
policy
feature
like
you
got
to
go
and
like
get
all
the
cni
providers
to
network
policy
and
port
yeah
calico
can
also
support
application
layer
policies
if
istio
is
enabled
in
the
cluster.
Oh,
so
I
thought,
calico
had
its
own
service
mesh.
A
D
So
there's
some
discussion
in
the
gateway
group
about
gateway
policies
and
whether
those
should
include
what
is
effectively
security
policies.
I
don't
have
a
clear
answer
for
that.
Yet
it's
clear
that
there's
some
value
like
like
psyllium
can
do
some
l7
policies
without
having
a
proxy
right,
but
that's
a
pretty
slippery
slope
into
policies
that
require
a
smart
proxy
to
implement
and
I'm
not
super
comfortable
making
that
a
requirement
for
implementations.
Yet.
A
A
A
C
A
A
B
A
E
D
Point
they
were
all
completely
orthogonal.
It
was
really
one
of
right,
and
then
there
was
an
argument
made
for
well
name.
Space,
selector
and
pod.
Selector
is
an
interesting
combination,
so
we
should
allow
you
to
support
both
of
them,
and
since
we
had
both
fields,
we
said:
okay,
fine,
we'll
we'll
define
what
the
intersection
of
those
means.
But
now
the
semantics
are
super
confusing.
What
if
I
specify
ip
block
and
pod
selector?
Does
that
mean
only
pods
that
match
this
ip
block?
B
E
D
You
right
and
if
I
want
to
restrict
that
further,
it's
not
really
a
restriction,
because
you
control
the
namespace,
so
you
can
bypass
the
restriction
at
your
whim
right,
and
so
that
was
the
original
thinking
of
like
this
is
just
not
a
useful
intersection,
but
there
were
arguments
made.
I
forget
what
they
were
exactly,
but
there
were
plenty
of
arguments
made
about
why
it
actually
is
useful.
Even
if
it's
not
a
hard
security
boundary,
it
does
help
in
minimum
privilege
situation.
So
we
allowed.
C
A
D
A
So
I
just
realized
we
got
so
we've
been
all
over
the
place
and
I'm
thinking
about
like
five
things
right
now
that
I
want
to
talk
about,
and
I'm
also
trying
to
get
this
other
thing
working,
but
we
haven't
actually
gotten
into
the
new
cluster
network
policies
yet
so
like
yeah.
Let's
do
that?
Let's
do
that
right!
So,
okay!
So
let
me
get
rid
of
this
horrible
thing
that
I
did
okay,
so
okay!
A
So
let's
do
this,
like
I'm
gonna,
I'm
gonna
just
be
the
be
the
dumbest
person
in
the
room
and
be
like
okay.
So
what
what
does
this
gravity
mean?
Who
wants
to
tell
me
what
this
downed
up
flow
of
the
cluster
network
policy
is?
So
hopefully
everybody
gets
it.
We
don't
have
the
ability
to
specif
specify
cluster
network
policies
right,
so
you
make
these
policies
you
make
them
typically
we're
just
looking
at
the
api
right,
they're.
A
C
C
Think
I
think
you
know
we
were
talking
about
different
personas.
I
think
that
with
any
kubernetes
clusters
you
you
have
the
ability
to
set
up
the
clusters.
Then
you
have
like
a
person
of
an
administrator,
and
then
you
have
those
developers
who
are
actually
deploying
the
services
in
the
cluster
and
we
call
them
as
developers
or
name
space
owners.
Maybe,
and
then
there
is
a
concept
of
tenant
and
multi-tenancy.
C
A
B
C
B
So
open
shift
has
something
similar
to
what
you're
saying
they
have
something
called
templating,
where
you
can
template
certain
policies
that
are
spun
up
automatically
when
name
spaces
spin
up,
and
it's
also
interesting
to
note
here,
like
this
difference
in
tenant
model,
you
know
a
tenant
being
once
name
space
or
multiple
namespaces.
That's
really
important,
because,
although
network
policy,
as
is,
is
designed
for
the
developer,
when
you
define
a
tenant
as
a
single
namespace,
you
can
implement
a
lot
of
these
use
cases
right
or
some
of
these
use
cases.
E
So
the
thing
is
that
I
just
add
a
note
here:
we
don't
have
an
explicit
resource
called
tenant
right,
so
the
assumption
is
that
you're
doing
some
appropriate
labeling
thing
to
identify
which
namespaces
are
in
the
same
tenant
and
so
on.
So
as
long
so
the
simplest
way
is,
you
know,
each
namespace
belonging
to
a
tenant
is
labeled.
You
know
tenant
equals
a
and
tenant
equals
b,
but
then
you
can
create
groups
of
tenants
as
well.
E
A
D
You
know
the
the
the
classic
example
is
right,
but
enable
label
all
cokes
namespaces
as
tenant
coke
label,
all
pepsi's
namespaces
as
tenant
pepsi,
and
the
policy
allows
you
to
express
all
traffic
with
the
same
value
for
the
label.
Tenant
is
allowed,
but
all
traffic
with
a
different
value
for
that
label
is
disallowed
yeah
and
then
within
your
namespaces.
You
can't
override
that
yep.
A
Which
is
that
goes
to
our
default?
That
reminds
me
that
we
have
the
default
policy
label
thing
which
we
should
show
people
really
quickly.
So
if
I
do
coupe
ctl
get
because
I
know
this
will
work.
This
is
the
easiest
thing
to
show
people
so
at
post
121,
if
I
do
edit
namespace
default,
say,
for
example,
you'll
see
that
there's
this
metadata.name
here
right.
A
That's
because
we
actually
add
a
default
label
to
every
namespace,
which
is
that
labels
that
namespaces
aim
itself,
and
we
do
that,
so
that
people
can
be
guaranteed
that
they
can
target
namespaces
with
network
policies
if
they
want
to.
Even
if
they
don't
know
the
labels
on
that
namespace
and
you
did.
B
E
Just
to
follow
up
with
that
so
basically
now
the
point
is
that
we
want
to
allow
people
to
create
multiple
kinds
of
tenancy
models,
and
you
know,
starting
with
a
group
of
name
spaces,
and
so
because
namespaces
are
a
clusterscope
resource.
The
tenants
won't
be
able
to
relabel
those
namespaces
right,
so
the
admin.
This
is
sort
of
an
admin
driven
tenancy
where
the
admin
labels
the
tenants
and
then
he
can.
You
know,
set
up
cnp's
based
on
those
labels
and
also
have
some
shortcuts
slaying.
E
A
C
Think
yesterday's
sig
network
meeting,
we
kind
of
agreed
on
the
priority
base
the
one
on
the
right,
because
that
is
something
which
is
much
more
familiar
now.
You
already
have
implementations
which
expose
similar
sort
of
an
api
to
accomplish
cluster
network
policies.
So
so
far
we
haven't
gotten
any
feedback
which
says
that
this
is
a
terrible
idea.
C
There
are
definitely
downsides
to
it,
but
not
nothing
which
is
not
solvable
and
so
slight
difference
to
existing
implementations
with
this
new
approach
is
the
introduce
introduction
of
the
pass
action
that
you
see
the
yellow
block.
That
is
something
new,
and
that
is
something
is
probably
you
know
not
widely
available
with
maybe
other
vendor
implementations,
so
perhaps
they
might
have
it,
but
in
a
different
form.
C
The
pass
action
is
something
that
we
introduced
to
explicitly
solve
the
problem
of
what
we
just
spoke
about:
how
to
handle
the
intertenancy,
intertenancy
and
inter
tenancy
model,
so
within
a
tenant
as
an
administrator.
I
don't
really
want
to
enforce
that
all
traffic
within
this
tenants
namespaces
should
be
allowed,
because
if
I
do
a
restrict
allow,
then
that
means
the
namespace
owner
cannot
override
the
decision
and
cannot
you
know
for
for
for
that
person.
All
all
of
its
workloads
are
now
freely
talking
to
each
other
within
his
own
name,
space.
C
B
A
E
Yeah,
I
think
the
the
point
here
is
that
we
we
definitely
going
back
to
sort
of
always
thinking
in
terms
of
operational
roles,
so
which
resource
is
relevant
to
what
kind
of
operational
role
and
since
cluster
network
policy
is
clearly
designated
at
a
cluster
admin.
Slash
network
admin,
one
of
the
philosophies
was
that
they
a
they,
are
familiar
with
sort
of
these
priority,
numbering
based
models
and
b.
They
are
okay
with
slightly
more
complex
rules.
You
know
almost
like
a
swiss
army
knife
so
that
they
can
do
whatever
they
want
over
time.
E
A
D
A
A
B
A
E
B
B
A
E
A
E
So
you
see
that
there's
a
new
kind
on
the
top,
that's
cluster
network
policy
and
there
is
no
namespace
field.
It
applies
to
the
entire
cluster
and
coming
down.
It
is
applied
in
this
particular
case
to
namespaces
that
have
a
label
called
tenant
right.
So
this
is
one
policy
that
applies
to
all
namespaces
that
belong
to
any
tenant
right
and
then
at
the
top
there
is
a
field
called
priority
which
is
sort
of
covered
by
that
yellow
line
that
jay
has
been
drawing.
E
Then
and
then
the
ingress
and
egress
rules
are
syntactically
pretty
similar
to
netball
right,
so
you
have
a
from
selector.
In
this
case
we
have
a
combination
of
namespace
and
part
selector
right,
so
this
is
basically
okay.
So
the
first
model
here
is
that
this
entire
cnp
has
one
priority
of
10
and
then
within
the
cnp
rules
are
listed
in
order
of
yammer
listing
priority
right,
so
the
earlier
in
the
earlier
rule
appears
in
the
yaml
the
higher
its
priority
right.
E
A
E
So
the
first
rule
is,
you
know:
if
you've
got
traffic
from
that
that
part
selector
match
and
that
namespace
those
those
namespace
labels
pass,
you
must
pass
that
traffic,
which
means
you.
You
are
essentially
deferring
the
handling
of
that
traffic
to
the
network
policy.
So
this
is
a
public
service
that
one
particular
tenant
is
publishing
right
and
the
cluster
admin
wants
to
delegate
to
each
tenant
admin,
whether
they
wish
to
receive
this
public
service
or
not
right.
So
this
is
a
hole
in
the
tenancy
boundary
and
the
next
rule
is
you
know.
E
The
next
from
is
deny
all
traffic
from
namespaces
that
have
a
tenancy
that
have
mismatching
tenancy
labels
right,
so
that
is
essentially
a
quick
way
of
saying
block
tenants
from
talking
to
each
other
right.
So
basically,
what
this
is
saying
is
look
at
the
label
called
tenant
in
each
of
the
namespaces
and
disallow
traffic
if
from
the
source
and
destination
name,
spaces
have
different
values
of
this
tenant
label
right
so.
A
E
Quick
way
of
setting
up
an
intertenant
boundary,
so
the
first
rule
allowed
you
to
create
a
hole
for
a
public
service.
The
second
rule
allowed
you
to
create
the
tenancy
boundary,
okay,
cool
and
there's
a
similar
logic
for
the
eager
side.
So
anyway,
that's
in
a
nutshell,
the
kinds
of
things
that
you
can
do.
A
B
E
So,
keep
in
mind
that
we
didn't
have
to
actually
name
the
tenants
here
right
we
want
to
create,
we
don't
want
to
repeat
cnp
instances
for
every
tenants
unless
we
have
to
so.
This
is
basically
saying
this
applies
to
all
tenants,
regardless
of
their
tenant
label
values,
and
using
this
you
can
set
up
tenancy
boundaries
and
selectively
make
some
holes
in
them.
A
C
B
E
A
Yeah,
okay,
let
me
draw
here:
we
go
so
there.
It
is
all
right
inside
the
green,
all
right
cool,
so
I've
got
food
name
space,
one
food
name,
space
two,
and
this
is
bar
name,
space,
they're,
all
different
name
spaces,
and
but
I'm
allowing
every
name
space
in
here
to
talk
to
the
one
name
space
in
this
tenant.
A
So
to
you
so
they're
delegating
to
the
lower
level
policies
delegating
to
lower
policies
yeah,
but
so
and
for
folks,
so
to
go
back
to
the
original
diagram
for
folks
that
didn't
come
to
sig
network
yesterday,
you
all
should
cut
if
you
all
come,
you
wouldn't
need
to
be
here
right
now.
Here
we
go.
Where
is
it
okay?
Here
we
go.
A
D
I
think
when
most
people-
I
don't
know-
maybe
not
most
people
but
like
I'm
very
visual.
So
when
I
think
about
how
the
policies
work,
I
think
of
it
like
a
a
stack
right.
The
higher
priorities
go
higher
up
the
stack
and
I
think
mostly
you'll,
set
things
up
in
a
in
a
pyramid
where
you've
got
some
broad
policies
at
the
bottom
and
some
narrower
policies.
As
you
go
up
and
at
some
point
you
hit
one
of
these
past
rules
or
whatever
we
end
up
calling
the
the
word.
D
I
think
after
hearing
this
conversation
today,
maybe
we
should
call
it
consult,
but
once
you
hit
the
once,
you
hit
that
consult
rule,
it
says:
hey,
go!
Look
in
the
name
space
of
the
target
here
and
use
that
at
this
point
right,
so
you
can
say,
like
I'm,
gonna
set
up
a
default,
deny
very
broad
base
and
then
I'm
going
to
say,
I'm
going
to
set
up
a
consult
rule
that
says
within
the
same
tenant
go
look
at
their
network
policy
right.
D
So
all
namespaces,
labeled
coke
are
allowed
to
talk
to
all
other
namespaces
labeled
coke.
If
coke
allows
it
right,
they
don't
have
to
allow
it,
but
they
may-
and
then
on
top
of
that
I
can
say
I'm
always
going
to
allow
traffic
from
our
monitoring
namespace,
because
that's
really
important-
and
I
don't
want
anybody
to
accidentally-
shut
the
door
on
that.
So
I'm
going
to
force
require
that
and
these
policies
are
getting
narrower
and
narrower
as
you
stack
them
up.
D
B
A
B
It
is
interesting
to
think
about
tim.
Do
you
think,
like
a
delegate?
Action
is
something
that
would
be
used
a
lot
by
a
cluster
admin.
I
mean
I
we've
thought
about
this
a
lot
internally
and
it's
kind
of
a
sticky
subject.
Right
I
mean
how
many
times
is
a
cluster
admin.
Gonna
say
we
explicitly
don't
care
about
this
traffic,
but
we
want
to
explicitly
let
the
namespace
admins
do
something
with
it.
I.
D
Think
the
biggest
use
for
it
is
the
tendency
thing
right
without
having
some
model
that
says,
I'm
not
allowing
this,
but
I'm
not
denying
it.
I'm
saying
it's
your
choice
right
and
if
you
don't,
if
you
don't
have
some
verb
that
allow
that
gives
you
that
capability
that
expression,
then
you
have
to
write
all
of
your
other
rules
in
terms
of
carving
holes
which
makes
the
rest
of
the
grammar
so
much
more
complicated.
D
Could
we
get
by
without
it
yeah
we
could
get
by
without
it
right,
but
you
didn't
have
to
write
your
deny
rules
as
these
sort
of
complicated
boolean
expressions
where
you
deny
everything
except
this
or
that
and
not
this
other
thing
like
it
just
wasn't.
I
don't
think
it's
worth
the
complexity
there.
No.
B
Yeah
we
did
explore
that
here
and
we
were
looking
at
priority
policies
where
you
didn't
have
a
third
action
called
pass,
and
you
know
I
think
that
was
the
biggest
conflict
in
the
team
internally
for
a
while
was
a
lot
of
us
thought
that
was
really
confusing
and
we
kind
of
settled
here
on
on
a
third
action
instead,
because
trying
to
write
a
match
expression
that
says,
create
my
tenant
boundary,
except
for
like
a
hole
here.
A
hole
here.
E
This
is
an
interesting
thought
that
you
know
the
intersection
of
oppa
with
network
policies.
I
don't
know
if
the
group
has
thought
much
in
this
direction,
but
at
the
moment
you
know
oppa
is
sort
of
independent
of
network
policy.
Of
course
you
can
use
oppa
to
decide
whether
to
allow
application
of
a
certain
network
policy
at
all.
C
So
I
was
gonna
say
correct
me
if
I'm
wrong,
but
oppa
kind
of
like
is
so
validation
on
the
resources
that
are
created
in
kubernetes,
as
as
opposed
to
the
cluster
network
policy
or
network
policy,
which
is
like
a
enforcer
of
the
traffic
of
packets.
So
I
feel
like
they
are
orthogonal
and
it's
a
common
misconception.
D
But
I
think
that's
impossible.
I
think
like
if
some
implementation
wanted
to
put
oppa
in
the
data
path
they
could
right.
But
what
would
have
to
happen
is
every
new
connection
that
you
established,
you'd
have
to
trap,
go
to
opa,
consult,
get
an
answer,
come
back
and
decide
whether
to
allow
or
not
allow
that
network
connection
to
happen,
which
certainly
isn't
impossible,
but
it
doesn't
seem
like
it's
going
to
be
the
best
return
on
investment,
whereas
we've
got
these
rules
that
are
loaded
into
whatever
policy
engine
is
currently
in
the
data
path
right.
D
E
D
A
This
this,
this
fact
that
we
are
talking
about
oppa
means
it's
a
good
segue,
because
there
is
this
whole
psp
thing-
and
I
remember
I
I
had
seen
this
earlier.
I
was
like
looking
around
and
there
are
some
people.
Who've
come
up
with
opa
alternatives
to
psps,
but
I'm
not,
I
don't
know
like
so
with
psps
being
when
are
they
deaf
so
like?
Let's,
I'm
gonna
pull
up
the
blog
post.
A
A
A
A
Here
we
go
so
here's
a
here's,
a
good
one,
and
that's
I
guess
in
our
public
examples,
here's
a
here's,
a
psp
right.
So
in
this
pod
security
policy,
these
are
getting
deprecated,
but
it's
you
know,
so
you
could
special.
You
can
specify
whether
you
know
whether
or
not
your
your
pod
itself
is
like
allowed
to
run
as
this
particular
user.
In
this
case,
you
can
run
any
user.
I
think
in
open
shift
you
you
do
a
lot
with
this
right
like
in
openshift.
A
B
A
E
What
became
psps
and
and
to
apply
these
psps
you
it's
sort
of
tied
to
our
back.
You
have
to
have
like
a
resource
like
the
deployment
sets
has
to
have
the
our
back
permission
is
sort
of
slightly
convoluted
logic,
which
is
one
of
the
reasons
why
it
was
deprecated
and
that
ties
to
you
know,
containers
which
end
up
enforcing
that
policy.
A
Yeah,
where
are
they?
So?
If
you
know
a
little
bit
about
this,
tell
us
a
little
bit
about
it.
I
so
I
I
know
people
are
using
opa
to
replace
them
and
there's
a
blog
post
here
and
I
think
there's
gonna
be
like
os
specific
stuff.
That's
gonna,
be
that's
gonna
start.
I
guess
there's
there's
something
going
on
where
they're
gonna
there's
a
cap
and
let
me
get
the
link
to
the
cap.
I
have
it
somewhere,
but
I
think
they're
gonna
have
operating
specific
system.
A
Sec
yeah,
I
mean
setcomp-
is
a
linux
specific
thing,
though
right.
That's
not!
You
can't
do
that
in
windows.
Can
you
so
that's?
That
would
be
an
os
specific
thing
for
sure.
Okay,
right
I
mean
I
could
be
wrong.
Maybe
they've
got
setcomp
in
windows,
I
don't
know,
or
maybe
they've
got
some.
So
this
is
the
cap.
It's
identify,
pods,
oh
no!
This
is
not
the
thing
I
was
looking
for.
A
This
is
a
different
one
from
ravi,
which
is
related
to
what
I
wanted
to
talk
about
anyways.
So
let's
get
in
this
is
a
new
one.
That's
coming
out.
That
is
super
exciting
for
us
on
the
windows
side,
which
is
that
during
scheduling
we'll
be
able
to
identify
a
pods
operating
system,
so
you
won't
have
to
do
magic
with
taints
and
tolerations
if
you
have
a
different
os
or
different
type
of
pod.
A
Okay,
so
alex
here
says
alex,
says:
oops
second
looks
like
ppf
yeah
choco,
so
alex
says,
set
comp
is
blocking
linux,
syscalls,
okay,
so
and
then
we
have
a
lot
of
comments
from
folks.
I
haven't
been
able
to
keep
up
while
it
in
openshift
or
cluster
level,
and
you
associate
service
account
to
it.
Yeah,
that's
what
it
is.
You
create
a
service
account
openshift
that
you
can
do
that
stuff
and
then
your
pods
launched
with
that
service
account
and
then
that
service
account
is
then
associated
with
the
psp.
Is
that
it.
A
Somehow
I
don't
know
docs
concept
security,
but
okay
cool,
so
anyways
thanks
everybody
for
for
helping
us
get
through
this.
So
so
there's
two
caps
here,
though,
that
that
are
worth
talking
about.
So
we've
got
this
one
and
we've
got
we've
got
this
one
from
ravi.
He
was
also
for
over
from
red
hat
and
identifying
a
pod
during
admission
and
then
there's
there's
the.
A
A
A
A
It
looks
like
it's
mostly
api
stuff,
though.
If
I
look
at
oh
here,
we
go
so
in
the
kubelet.
Okay,
so
inside
the
kubelet
there's
logic
for
it.
So
there's
an
allow
list
and
the
kubelet
looks
like
it
actually
goes,
and
this
these
are
cis
ctls
that
the
kubelet
enforces.
So
so
these
are
actually
enforced
by
the
kublet,
and
then
it
allows
certain
types
of
behaviors.
I
guess,
based
on
the
existing
okay.
A
So
I
wonder
how
this
gets
passed
down
to
the
run.
Does
the
it
must
be
the
container
runtime
that
has
to
has
to
implement
this,
though
oh
wow
they
have
an
app
armor
validator.
So
that
means
they
have
an
se
linux,
one
two
in
here
right,
so
they
have
okay,
so
they've
got
sc.
Linux
and
they've
got
app
armor,
and
I
guess
they.
If
I'm,
if
I'm
having
to
guess,
then
maybe
what
they're
doing
is.
E
A
Yeah
they're
on
the
outside,
okay,
so
there's
a
lot
of
coupling
here
between
the
operating
system,
the
implementation,
because
you
can
do
app
armor
or
sc
linux
or
whatever
so
anyways.
Back
to
the
original
cap,
pod
security,
admission
control
policy
enforcement
is
controlled
at
the
name
space
level
through
labels,
policies
can
be
applied
in
three
modes.
Multiple
modes
can
apply
to
a
single
name.
Space.
A
Enforcing
audit
warning
optional,
promo
dry
run
of
namespace
updates
is
supported
to
test
enforcing
policy
changes.
Motivation,
psps
are
deprecated
121,
there's
a
policy
auth
model,
there's
rollout
challenges.
Psp
fails
closed
in
the
absence
of
a
policy
feature
can
never
be
enabled
by
default,
need
100
coverage
for
rolling,
at
least
since
I
don't.
I
don't
understand
the
rollout.
What
they
mean
by
that
inconsistent
and
unbounded
api
can
lead
to
confusion
and
errors.
I
think
this
is
what
sanjiv
was
talking
about.
E
A
Like
on
the
node,
you
mean
oh
interest,
yeah,
okay,
yeah,
so
there
wasn't
any
way
to
so.
You
could
basically
completely
your
cluster
if
you
put
the
wrong
security
policy
in
place
like
to
the
point
where
the
the
kubrick,
the
kubler
couldn't,
do
anything
okay.
So
that's
a
good
reason
to
get
rid
of
these
all
right,
so
replace
pod
security
policy
without
compromising
the
ability
for
kubernetes
to
limit
escalation
out
of
the
box.
A
A
Is
gonna
have
to
be
another
tgik
and
we're
kind
of
getting
kind
of
laid
in
here,
but
so
we
had
so
many
wonderful
guests
today
that
towards
the
end,
we
kind
of
missed
out
on
being
able
to
really
dig
into
this,
but
I
think
the
takeaway
is
right.
Now
we
have
psps
implemented
inside
the
kubelet
they're
gonna
unwind,
all
that
and
then
they've
got
this
cap.
A
It's
two
five,
seven
nine,
which
is
the
psp
replacement
cap,
and
I
guess
the
idea
here
is
they're
gonna
chase
the
following
pod
field:
they're,
gonna,
okay,
so
we're
gonna
update
the
api
from
all
they're
gonna
have
spot
security.
It
doesn't
say
anything
about
the
implementation,
though
much
I'm
still
curious.
A
It
looks
like
they're
still
going
to
somehow
delegate
some
stuff
and
the
good
news
is.
We
still
have
windows
support
so
this
time
or
we
will
have
windows
support
this
time,
so
privileges
baseline
do
not
require
any
os
specific
fields
to
be
set.
The
restricted
level,
crest
fields
that
are
linux,
specific,
which
may
prevent
windows
pods
from
running
or
require
windows
kubelets
to
ignore
those
fields
and
mexico's
windows,
specific
exemptions
or
requirements,
and
the
restricted
profiles
described
in
the
future
work.
So
at
least
they're
they're
leaving
some
openness
for
for
more
windows,
friendliness.
A
A
A
Yeah,
I
mean-
I
guess
it's
still
going
to
be
processed
by
the
kubrick,
because
they're
saying
that
that
at
least
in
the
windows
situation
they
may
have
to
ignore
it
so
they'll
be
replacing
them
and
they're
going
to
replace.
I
guess
they're
going
to
replace
the
api
with
some
other
kind
of
admission
control
and
it's
just
going
to
be
more
flexible,
but
I'm
assuming
that
there's
still
going
to
be
some
kind
of
kubelet
level
management
of
system
apis.
To
do
this.
A
Yes,
evan,
I
think
that's,
I
think,
that's
that's
that
kind
of
wraps
it
up
for
today,
so
we
got
to
kind
of
go
through
everything
and
we
we're
kind
of
at
that
over
one
and
a
half
hour
mark.
So
I
feel
like
this
is
probably
a
good
stopping
point,
so
any
any
any
any
final
thoughts
from
andrew
or
sanjeev
on
any
of
this
stuff.
Either
the
policy
network
policy
stuff
or
the
where
the
psp
stuff
is
headed
or
anything
else.
B
Just
love
to
give
a
quick
shout
out
if
you
are
interested
in
network
policy
and
kubernetes
come
to
our
upstream
sig
network
policy,
api
meetings.
We
have
a
lot
of
work
to
do
and
we're
really
all
pretty
excited
with.
What's
coming
down
the
pipe
so
always
looking
for
more
help
and
more
input,
so
yeah
you
can
find
more
info
there
on
the
main
sig
network.
Github
pages
links
those
wheat
meetings,
but
thanks
cool.