►
From YouTube: Kubernetes SIG Security 20211021
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
Okay,
it's
two
minutes
past
nine.
I
see
some
new
faces
in
the
meeting
today,
so
maybe
rey
you
may
savita
and
others
who
are
usual
suspects
can
introduce
each
other
ourselves
and
then,
if
others
want
to
introduce
themselves,
we
can
do
a
full
round.
A
All
right,
cool,
okay,
so
hi,
I'm
your
friendly
security,
tooling
sub
project
lead
I've
been
working
in
security
for
a
few
months.
Now
I,
in
my
day
job
I
work
at
vmware,
focusing
on
sick
kubernetes
security
as
well.
D
I'll
go
next
monday,
hello,
my
name
is
ray.
I
am
the
sub
project
owner
for
the
third
party
audits.
I'm
also
the
123
release
lead
and
also
contributes
in
a
few
other
areas
of
kubernetes
as
well.
B
Hi
everyone,
my
name
is
avita
and
I
am
the
sub
project
owner
for
the
security
documentation.
So
I
am
learning
and
we
are
all
learning
here-
sharing
and
knowledge
sharing
and
learning.
So
if
you
are
interested
in
contributing
to
any
of
the
sub
projects
or
if
you
have
any
ideas,
we
are
all
here
ears
and
then
we
would
welcome
all
kinds
of
contributions
nice
to
have
you
all
here
time.
For
me.
C
Hello,
I
would
like
to
introduce
myself
too
I'm
alexa
piriva,
I'm
working
for
huawei.
As
a
software
engineer,
I'm
focusing
on
resource
management
and
security
hardening
for
a
solution
based
on
kubernetes.
C
So
I'm
here
to
discuss
some
new
scripture
hardening
features.
That's
all
from
my
side.
A
All
right,
welcome,
alexey
great
to
have
you
here
looks
like
you
have
done
a
lot
of
work
already
in
kubernetes,
so
we
definitely
need
a
lot
of
people
like
you,
as
well
as
contributors
who
are
new
to
the
community,
so
we
def,
we
should
discuss
the
topic
that
you
have.
I
think
you've
already
added
it
in
the
discussion.
So
once
we
have
the
subgroup
reports
done,
I
think
we
can
go
straight
to
your
topic
after
the
introductions.
Obviously,.
E
Hi
I'm
new
here
my
name
is
lucas,
melchior
I
am
from
minneapolis
minnesota.
I
work
for
a
company
called
flywheel.
E
We
deploy
everything
our
application
on
kubernetes,
I've
been
an
end
user
for
probably
five
years
or
so
now,
and
I've
contributed
to
some
some
smaller
projects
in
the
ecosystem
cube
spray,
some
node
exporters,
exporters
for
prometheus
stuff,
like
that
and
after
virtually
attending
kubecon.
I
thought
maybe
it's
time
I
actually
attend
a
sig
meeting.
So
this
is
my
first
one,
mostly
just
gonna
be
a
fly
on
the
wall,
but
I'm
happy
to
be
here.
A
Great
to
have
you
lucas,
I
also
started
my
upstream
journey
because
of
kubecon
couple
of
years
ago,
and
I
was
very
excited
with
what
stuff
people
do
so
great
to
have
you.
F
Thanks,
I
can
also
introduce
myself,
I'm
also
new
here.
I've
also
been
using
kubernetes
for
about
five
years.
I
work
at
a
company
called
fairwinds.
We
have
several
fairly
good
sized
open
source
projects
that
I
have
contributed
to
over
the
years
and
looking
to
get
involved
somewhere.
I've
been
in
and
out
of
different
parts
of
the
community,
but
I've
never
actually
fully
contributed
so
hopefully
to
get
a
chance
to
get
involved
here.
A
Anyone
else
completely
voluntary
introductions.
So,
if
you
are
shy,
like
me,
it's
okay,
if
you
don't
want
to
introduce
as
well
we're
just
doing
new
people
or
existing
as
well
up
to
you,
we,
I,
I
think
we
love
to
know
more
about
you
for
sure.
G
A
All
right,
cool
yep
eric
has
been
helping
a
lot
on
doing
most
of
the
tooling
stuff
and
is
always
like
the
my
biggest
cheerleader
so
great
to
have
you.
G
Well,
pj
saved
my
bacon.
I
tried
to
start
the
tooling
sub
project
early
and
you
came
in
and
you've
done
a
great
much
better
job
than
I
was
doing
so
because
I
didn't
know
what
I
was
doing.
A
Just
you're
just
being
too
kind,
I
would
say,
but
okay,
anyone
else,
oh,
let's
see,
oh
mahe,
has
introduced
hope.
I'm
pronouncing
the
name
right
on
text,
so
maybe
I'll
read
quickly
for
others
who
might
be
on
phone
hello,
everyone
I'll
introduce
myself
via
text
because
I'm
in
office
right
now
it's
super
noisy
yeah.
I've
been
there.
I
am
my
working
researching
kubernetes
security
for
quarks
lab,
for
example,
I
released
a
small
tool
a
few
weeks
ago-
kdigger,
oh
yeah.
I
remember
seeing
your
slack
post
on
this,
maybe
just
before
cube
corner
around
kubecon.
A
A
All
right,
cool
and
robert
is
also
doing
the
same
on
chat
so
co-chair
for
policy
work
group
helping
on
external
audit
and
trusted
api
self-assessment.
Yes,
robert
has
been
great
he's,
also
a
huge
member
in
tax
security,
so
all
of
his
knowledge,
coming
in
for
self-assessment,
has
been
very
instrumental.
H
Off
mute,
this
is
my
second
sig
security
meeting
that
I
joined
new
to
security,
not
new
to
the
kubernetes
community.
My
primary
role
is
a
sigdoc's
co-chair.
I'm
also
a
release
manager
associate
part
of
sig
release,
but
really
interested
in
security,
and
you
know
what
I'm
trying
to
do
right
now
is
get
plugged
into
some
of
these
areas
that
I'm
interested
to
learn
more
and
being
able
to
support
the
community
a
little
bit
better.
So
it's
awesome
to
see
everybody
and
awesome
to
meet
some
new
folks.
A
All
right
cool,
if
nothing
else,
that's
fine,
so
we'll
generally,
what
we
do
in
the
meeting
is
go
through
the
sub
group
reports
from
all
of
us
and
then,
if
we
have
something
new
to
discuss,
we
go
through
that
and
talk
about
it
a
bit
more
and
then
we
go
to
the
general
discussion
points
which
are
being
added
right
now
or
have
added
in
the
past
as
well.
So
we'll
go
straight
to
ray
for
audit.
D
Report
all
right,
mine's
gonna,
be
super
short,
but
all
I
could
say
is
that
vendor
selection
is
still
in
progress
and
I
hope
to
have
more
news
in
the
near
future.
B
B
If
you
have
anything
to
add
or
learn
from
there,
so
once
it's
so
that's
the
request,
and
once
it's
all
ready
and
it's
going
to
get
published
under
kubernetes
security
project
repository
that
we
just
have
created,
so
it
will
be
available
there
and
we
also
discussed
a
home
for
policy
white
paper
and
for
now
we
discussed
that
it's
gonna
be
living
under
kubernetes
security
repo
again.
So,
if
it's
available,
I
will
link
it
here.
B
B
I
Well,
actually,
I
have
on
the
discussion
later
down.
There's
a
pr,
so
my
co-chair,
jim
paguardia
of
the
caverno
project,
had
pr'ed
it
to
the
repo
I
think
as
as
a
pdf
file.
So
I
think
our
our
hope
was
that
we
could
get
someone
to
approve
lgtm
that
pr
and
then
it
would
be
available.
I
mean.
I
At
the
file
on
the
change
in
pr,
but
it
would
be
officially
in
the
repo.
B
Sorry,
robert,
I
didn't
even
go
through
the
discussion
to
see
it
push
my
back.
B
A
A
Okay,
so
tooling,
I
don't
really
have
any
new
update
to
discuss.
Just
one
thing
I
would
point
to
is
we
have
a
new
kubernetes
security
repo
which
was
created
about
maybe
couple
of
months
ago,
so
most
of
our
issues
that
we
are
working
on
will
be
there.
A
There
are
some
good
first
issues
that
I
created
last
evening
and
two
of
them
were
already
picked
up
by
new
new
contributors,
so
which
is
great
to
see.
So
take
a
look
at
that,
if
you
find
anything
interesting
or
if
you
want
to
suggest,
suggest
an
issue
that
might
be
useful
for
the
overall
security
of
kubernetes
go
for
it
and
we
will
find
a
way
to
see
where
that
can
land.
A
Next
one
is
security,
self-assessment
so
same
as
the
other
one,
nothing
much
new
to
update.
But
more
mostly,
we
did
one
meeting
before
kubecon
week
the
week
before
coupon
we're
gonna
start
again
next
week,
wednesday
early
morning,
eight
to
nine.
So
hopefully
that
kind
of
time
works
for
most
folks
in
us
most
folks
in
europe
and
most
folks
in
india,
and
the
idea
is
we'll
just
make
it
a
public
meeting.
A
So
we
we're
going
to
make
it
public
we'll
forward
it
into
all
the
focusing
security
and
all
the
folks
in
sick
cluster
life
cycle
and
then,
if
folks
want
to
join
people
can
join.
There
are
some
maintainers
of
cluster
api
who
will
work
with
on
this
and
from
our
side,
robert,
and
I
will
be
mostly
doing
the
talking.
A
A
So
if
you
have
a
project
or
you
know
a
project
that
is
within
the
kubernetes
umbrella,
like
cluster
api
and
you
think
it
might
benefit
from
a
security
point
of
view,
we
can
start
talking
about
it
and
maybe
I'll
leave
five
minutes
or
so
at
the
end
of
every
self-assessment
meeting
for
those
kind
of
discussions,
if
you,
if
anyone
is
interested
to
bring
it
up
there,
that's
about
it.
Robert
anything,
you
would
add,
was
the
recording
from
that
first
meeting
available
to
everyone.
I
A
Yeah,
so
I
I
added
it
in
the
sick
cluster
life
cycle
channel.
It's
on
youtube,
also
I'll
make
sure
to
maybe
bookmark
it
in
our
security
assess
cappy
channel,
so
that
people
can
look
it
up
easily.
A
C
Yes,
I
had
the
first
issue.
I
found
it's
about
verification.
C
This
verification
was
added
by
team,
but
unfortunately
he
is
not
here
or
right.
Now
I
asked
an
equation
to
him
in
a
pr,
so
I
expect
the
answer.
Also.
This
pair
are
already
good
lgtm,
but
it
was
unset
after
my
update,
so
I
expect
you
will
review
it
again,
and
so
maybe
he
somebody
here
knows
why
we
have
a
verification
check
for
cops.
This
admin
together
with
an
all
privilege
escalation.
C
So
the
case
when
we
can't
propagate
this
kind
of
capability.
Why
not
cap
model?
Because
in
this
case
we
can
move
the
kernel
model
and
replace
tasks
tracked
attributes
inside
linux
kernel.
C
C
A
A
A
A
C
D
A
D
I
do
agree
there,
I,
but
I
don't
know
which
sick
that
is.
A
Right,
I,
I
think
what
at
least
I
can
do
from
my
side
alexis.
I
need
to
read
this
a
bit
more,
because
this
is
kind
of
new
to
me
so,
and
this
looks
like
a
one
or
two
line
change,
but
probably
the
context
is
a
lot
more.
So
I'll
take
a
look
at
that.
A
Seaguar
is
also
some
some
one
sig
there,
where
tim
is
also
around
quite
a
lot.
So
that
is
another
sig.
We
can
add
in
the
pr
to
just
get
more
eyes
on
it
and
then
yeah
I'll
bring
this
to
the
co-chairs
also.
So
if,
if
we
don't
get
a
chance
to
talk
to
them
before
the
next
meeting
will
be,
we
can
bring
this
up
again
next
meeting
and
see
if
they
have
any
thoughts
on
that
as
well.
A
Does
that
sound
as
a
good
next
step
for
you?
Oh
yeah,
thank
you
very
much.
All
right,
cool,
okay,
thanks
a
lot
alexey
in.
C
Anything
else
next
topic
about
ambient
capability.
I
prepared
a
demo.
I
made
an
implementation
and
based
it
on
vinayak's.
C
Pull
regarding
container
runtime
interface
changes
for
supporting
ambient
and
board
specification.
So
why
do
we
need
to
eat?
We
are
trying
to
run
our
system
related
ports,
such
kind
of
cni,
without
a
root
permission.
For
this
case,
we
need
like
capability
to
make
some
interface
and
happy
tables
manipulations.
C
So
the
alternative
approach
is
to
keep
capability
inside
extended
attributes
of
images,
but
it
could
be
not
possible
if
we
are
checking
our
images
and
we
are
trying
to
clear
such
kind
of
attributes,
and
we
would
like
to
control
all
our
capabilities
on
the
corresponding
level
and
on
the
level
of
runtime,
but
not
in
the
images.
J
C
C
A
I'm
gonna
make
you
co-host,
which
should
allow
you
to
present.
I
think,
try
now.
A
C
C
Board
these
capabilities
and
aim
at
least
yes,
the
name
is
and
discuss
about
it.
It
was
a
long
long
discussion
about
the
new
field
name
and
it's
always
very
hard
to
modify
a
port
specification,
so
in
my
example
same
and
but
it
agreed
at
ambient,
so
we
are
requesting
net
admin
capabilities
and
what
we
are
doing.
We
just
create
an
interface.
C
C
Yes,
there,
so
it's
not
for
featured
ccnap
again,
it's
just
one
example:
let's
see
at
oci
spec
of
our
port.
C
Now
ambient
capability
should
be
there
right
before
this
page.
It
was
not
passed.
D
C
C
So
this
one
from
my
side,
this
demo
was
very
small.
I
decided
to
not
show
c9
because,
because
it's
maybe
a
complex
and
in
such
details,
it's
much
more
clear
from
my
point
of
view.
A
C
A
Right
and
so
what
does
that
mean?
This
will
work
now
with
container
d
and
some
other
runtimes,
also
or
only
containerity,
like
cryo,
for
example,.
A
K
Projects,
the
order
of
merges
is
like
listed
in
the
kept,
so
the
first
thing
we'll
do
is
we'll
update
the
cri
api
to
support
a
field
right
right.
So
so,
then,
once
that
merges,
the
next
step
would
be
to
work
with
continuity
and
crio
to
have
both
need
to
have
a
version
that
supports
it
once
that
happens,
we'll
enable
the
k8s
field
if
we
decide
to
go
with
the
gate
as
field
in
this
case,
and
that
would
be
all
the
work
we
do
for
alpha.
For
this
feature.
A
I
see
okay,
anyone
else
has
any
questions
galaxy.
What's
also
saying
something.
Sorry
I
interrupted
you.
C
Oh
sorry,
I
did
not
passed
yes,
this
came
was
introduced
by
vinayak,
so
I
I
don't
put
it
right
now.
Thanks.
A
A
I'll
probably
keep
I'll,
probably
also
encourage
everyone
to
go
through
the
kept
link
that
when
I
added
add
your
comments
later,
if
you
come
up
with
something
that
you
don't
have
now
and
yeah
really
looking
forward
to
this,
this
has
been
one
of
our
caps.
I've
been
following
since
I
joined,
and
I'm
glad
like
this
is
progressing
well.
I
Yeah
we
can.
We
talked
briefly
at
the
beginning
about
the
the
policy
work
group
has
put
together
a
white
paper.
We
had
a
panel
at
kubecon,
so
there
should
be
a
recording
there,
but
the
actual
pdf
pr
is
is
linked
in
the
agenda
and
if,
if
someone
can
review
it
and
merge
it
in
that'd
be
great.
In
addition,
just
to
give
you
a
brief
work
group
update,
we
meet
every
other
wednesday
8am
pacific,
our
call.
I
Yesterday
we
discussed
the
next
phase,
which
is
doing
a
curating,
a
policy
library
or
at
least
a
framework
for
a
policy,
library
or
libraries,
so
that
we
can
have
a
repository
of
actual
kubernetes
policies
that
would
map
to
various
frameworks
or
standards
or
even
conceptual
domains
like
supply,
chain,
security
or
xero
trust
or
things
like
that.
So
very
formative.
We
had
a
lively
discussion
yesterday
from
different
perspectives,
so
nothing
concrete
yet,
but
I'm
going
to
put
a.
I
A
What
I
added
in
the
comment
to
jim-
and
there
has
been
some
update
there,
so
I
wanted
to
share
with
everyone
so
the
initial
place,
where
everything
from
six
security
was
was
under
k,
community
and
a
security
director
inside
it,
as
we
kind
of
did
a
lot
of
a
lot
more
work,
see
contributex
folks
actually
suggested
that
k
community
should
really
be
used
to
store
the
metadata
about
six
versus,
like
the
actual
artifacts,
that
the
sick
creates,
which
resulted
in
k-6
security,
repo
itself
being
created,
and
now
there
is
an
open
issue
that
was
picked
up
last
night
from
one
of
our
newer
contributors
to
move
most
of
what
is
in
kck
community
security
directory
that
is
relevant
to
docs,
tooling
and
third
party
audit
to
the
new
repo.
A
A
The
chances
of
the
move
happening
is
early
is
now
higher,
so
we
can
either
merge
this
now
and
as
part
of
the
move,
we
can
move
this
one
as
well
to
the
new
repo
or
if,
if
there
is
no
kind
of
urgency
from
the
policy
working
group
on
merging
this
or
if
we
don't
have
any
hard
deadline,
we
can
wait
until
the
move
or
refactor
happens,
and
then,
instead
of
this
pr,
we
just
replace
this
pr
2k
community
with
a
pr
to
k6
security.
I
No
there's
no
hard
deadline,
I
mean
it's.
The
pdf
is
fairly
static.
The
underlying
github
google
doc
is
fairly
static.
At
this
point,
I
think
it's
locked
from
changes,
so
you
know
if
we,
if
we
were
to
make
new
changes,
it
would
probably
be
a
rev
too.
A
Okay,
so
in
that
case,
just
to
avoid
drive
through
lgtm
and
approve,
I
can
add
a
hole
there
if
you're,
okay
with
that
on
the
pr
so
that
we
don't
end
up
merging
it.
While
we
are
refactoring
and
then
that's
just
confusing
for
the
person
working
on
it
and
then
once
we
have
that
one
completed,
then
we'll
close
this
pr
and
create
a
new
one
for
the
new
repo,
no
problem.
Okay,
sounds
good
all
right
any
other
thoughts
from
anyone.
A
I
definitely
recommend
reading
the
paper
if
you
kind
of
dabble
in
this
domain
of
kubernetes
and
policies,
it's
a
pretty
descriptive
and
well-written
paper
and
also
kind
of
adopt
some
of
the
structure
from
cloud
native
security
white
paper
as
well.
So
take
a
look
if,
if
you
are
interested
just
to
learn
or
maybe
if
you
have
a
feedback,
I'm
sure
the
working
group
will
be
happy
to
hear
from
you.
I
Yes,
this
is
more
just
a
query
to
the
group.
If
there
is
interest
those
of
us
who
are
working
in
public
sector
government
and
to
clarify
from
savita
added
a
comment,
you
know,
I
don't
intend
this
to
be
military
or
classified
there's
a
broad
sector
of
public
government,
not
just
us
but
of
course
eu
asia,
elsewhere,
sovereign
nation.
Everyone
has
civilian
agencies.
So
commerce
to
you
know
any
well
anything.
I
So
if
those
often
have
different
cicd
requirements,
they
often
have
different
compliance
requirements.
They
often
have
different
cost
structures,
budgeting
requirements.
So
if
there's
interest,
if
there's
an
audience-
and
we
want
to
take
some
of
these
public
sector
discussions-
offline
of
the
main
group
doesn't
make
sense
to
have
that
encapsulated
in
a
slack
channel.
I
A
Yeah
my
initial
thought
robert,
is
just
to
make
the
group
more
broader
in
scope.
It
might
make
sense
to
have
it
potentially
in
the
cncf
workspace,
because
I
would
imagine
most
problems
wouldn't
be
just
kubernetes
related,
but
could
cover
other
cncf
projects
as
well.
So
having
that
there
will
allow
maybe
more
interaction
with
the
attack,
security
and
other
tags
as
well
and
we'll
be
able
to
talk
on
a
broader
scope,
not
just
kubernetes
specific
stuff.
I
Yeah,
actually
I
I
do
have
a
selection.
I
don't
have
it
there's
a
slack
channel
there
in
the
in
the
cncf
workspace
for
it
I'm
it's
fairly
light
volume,
but
we
could
certainly
talk
about
kubernetes.
I
would
just
say
that
in
my
discussions,
which
is
a
very,
very,
very
narrow,
slice
of
the
universe,
folks
are
still
coming
up
to
speed
with
you
know,
containers
and
then
kubernetes
versus
the
broader
scope
of
the
cncf
projects.
D
I
I
think
it's
it
realistically.
I
think
they're
they're,
starting
to
move
towards
kubernetes
and
it'll,
be
a
while
before
they
graduate
to
the
broader
ecosystem
of
cncf,
but
every
little
bit
helps
so
yeah.
D
I
A
Yeah
I
mean
looking
at
the
history
of
security
itself.
I
almost
think
that
cncf
tax
security
started
before
the
security
group
was
here
and
the
whole
reason
why
this
started
was
because
kubernetes
itself
had
so
many
things
to
talk
about
from
security
perspective.
We
needed
a
space
that
was
dedicated
for
it
and
I
think
similarly
like
if
the
cncf
channel
on
this
topic
blows
up,
and
there
is
a
lot
more
interaction,
a
lot
of
people
wanting
to
talk
about
things
and
maybe
like
some
huge
percentage
of
it
is
kubernetes.
A
Then
I
think
we
should
definitely
create
one,
but
until
that
happens
potentially
might
be,
might
be
wait
and
watch
approach.
In
my
opinion,
at
least.
A
All
right
any
so
now
we'll
open
it
up
for
everyone
who
may
have
joined
later
want
to
introduce
or
just
talk
about
feelings,
things
that
you
think
might
everyone
might
be
interested
in
stuff.
You
learnt
in
kubecon
anything
that
came
up
that
you
have
shared
in
the
past
and
we
haven't
had
a
chance
to
talk
about,
or
we
have
about
18
minutes.
So
we
can
talk
whatever
you
want.
H
A
H
Cool,
so
you
know,
one
of
the
things
I'm
currently
working
on
is
kind
of
the
shift
from
pod
security
policies
to
using
the
pod
security
admission
and
then
combining
that
with,
like
oppa
or
caverno,
or
you
know
some
other
policy
enforcement,
and
this
might
just
be
me
sharing
my
ignorance
in
my
journey
through
kubernetes,
but
up
until
recently,
I
always
understood
that
pod
security
policies
could
be
kind
of
like
pick
where
you
want
to
enforce
more
or
less,
and
what
I
mean
by
that
is,
if
I'm
running
a
multi-tenant
cluster-
and
I
have
some
folks
using
a
certain
name
space,
I
could
use
pod
security
policy
to
say
only
these
specific
pods
could
run
privilege.
H
Only
these
specific
pods
cannot
try
to
enforce
some
form
or
mechanism
of
enforcement
there.
I
know
there's
some
pitfalls
with
pot
security
policies.
That's
why
it's
getting
deprecated
or
moving
away,
but
when
I
started
to
talk
to
more
folks
in
the
community
around
the
security
model
of
kubernetes
and
the
posture
of
the
in
the
future
of
pot
security
admission,
it
became
very
clear
that
the
security
boundary,
the
lowest
common
denominator
for
enforcing
security
on
kubernetes,
is
at
the
name.
Space
level
and
the
idea
of
running
privileged
workloads
should
be
kind
of
like.
H
If
there's
a
namespace
and
you're
running
a
privileged
workload.
You
should
just
assume
that
anyone
who
has
the
ability
to
access
that
namespace
or
run
deployments
there
could
intentionally
run
a
privileged
workload
and
so
why
this
all
sounds
like
common
sense.
But
I
feel
like
this
is
a
big
paradigm
shift
that
really
caught
me
by
surprise,
because
with
pot
security
policies,
I
was
able
to
pick
and
choose
whether,
appropriately
or
not
appropriately
where
enforcement
happened,
and
this
model
now
has
come
to
my
attention
that
namespace
being
the
boundary
where
you
can
still
run
mixed
workloads.
H
Just
assume
that
if
you're
allowing
privilege
that
a
privilege
is
allowed
in
general,
you
know
what
I
mean,
and
so
I
think
us
as
a
community
as
an
entire
community
could
do
a
better
job.
At
least
advertising
saying
look.
Namespace
is
the
fundamental
lowest
security
boundary
in
kubernetes,
we're
not
talking
about
pods
or
containers.
Yes,
you
can
have
that
lower
level
of
granularity
of
enforcement,
but
just
basically
saying
if
you're
running
a
privileged
workload
in
a
namespace,
I
treat
it
as
ultimately
privileged
kind
of
like.
A
D
So
we
could
highlight
this
in
the
feature
blog
post
for
pod
security
mission
controller
since
going
to
beta
and
1
1.23.
D
A
Yeah,
I
I
agree.
I
and
I
think
the
whole
thing
that
you
talked
about
jim,
is
mainly
because
the
object
that
allowed
us
to
enforce
psp
was
service
account
and
our
cluster
role
tied
to
it.
But
now
it's
just
name
space
labels
or
a
cluster-wide
policy,
so
with
pp
with
photoport
security
admission,
so
that
kind
of
changes
the
whole
paradigm,
like
you
said
where
now
I
might
have
pods
that
are
lesser
privileged
than
than
what
is
available
for
the
namespace,
and
I
could
still
run
them.
A
But
I
could
als
it
doesn't
stop
me
from
running
something
more
privileged
there.
So
I
definitely
agree.
I'm
doing
sort
of
tgik
tomorrow
on
port
security,
so
I'll
try
to
tackle
that
and
see
if
it
actually
works,
where
I
have
one
privilege
pod
in
the
same
name,
space
and
a
privileged
mod,
and
if
I
apply
and
apply
a
restricted
port
security
label
and
does
the
privileged
one
fail
and
if
I
apply
a
privileged
one,
does
the
restricted
one
allow
is
allowed
and
then
what
happens?
A
If
I
start
ask
adding
more
permissions
to
the
unprivileged
one
that
it
doesn't
need,
so
that
that
will
be
very
interesting
for
sure,
but
I
agree
with
the
blog
post
idea,
the
more
we
make
it
clear
that
hey
this
is
what
it
is
changing,
and
hopefully
some
folks
who
work
on
admission
controllers
that
are
gonna
do
something
similar
like
pod.
Security
can
also
share,
if
that
is
the
case,
for
their
tools
as
well
or
is
it
something
where
they
can
apply
it
at
a
pod
level,
instead
of
name
space
level?
A
So
that
will
be
some
sort
of
similarity
when
people
are
moving
to
a
different
external
admission
controller
where
they
can
say?
Okay,
I
don't
have
service
account
based
enforcement,
but
I
can
still
do
it
by
pod
using
this
particular
feature.
In
this
admission,
controller.
J
That
is
very
interesting
because
I've
always
thought
of
namespaces
as
like
clusters
of
pods
kind
of
the
equivalent
of
a
cluster
in
in
in
a
physical
sense,
and
I
didn't
realize
they
were
going
to
do
it
on
a
on
a
namespace
level
like
that.
A
J
J
A
That
was
not
intentional,
but
I'm
happy
to
have
more
folks
learn
stuff
with
each
other.
G
A
Yeah
definitely-
and
I
think
one
thing
I
always
suggest
everyone
is,
if
you
really
are
interested
in
of
the
workloads
in
your
cluster,
you
should
just
run
it
in
another
cluster.
So
that's
the
best
boundary.
We
can
get
another
thing
that
I
found
useful
learning
through
the
pod
security
admission.
Was
this
block
push
from
one
of
our
community
members
lackey?
Who
did
a
keynote
last
week
on
port
security
admission,
and
it
has
two
shout
outs
for
jim.
A
So
I
think
this
blog
is
also
very
useful
if
you
want
to
just
play
around
and
see
hands-on
how
it
works
so
definitely
recommend
for
folks
who
want
to
try
it
out
and
see
what
what
would
work
it
and
good
thing
is
psa
works
on
kind.
So
you
really
don't
need
a
real
kubernetes
cluster
to
just
check
out.
H
Thank
you
yeah,
and
I
don't
really
have
an
answer
to
the
problem.
I
really
just
wanted
to
raise
awareness
but
er
to
your
point,
just
kind
of
example.
Where
this
this
model
comes
to
light
is
let's
say
I
had
a
multi-tenant
cluster,
where
users
were
restricted
in
what
they
could
deploy,
what
they
could
run,
but
we
still
allowed
them
to
exec
into
pods
or
do
whatever
and
I'm
just
totally
hypothetical
theoretical.
Here
now,
let's
say
you
deploy
something
like
cube
flow
or
something
in
the
cluster.
H
That
is
an
operator
that
deploys
pods
into
multi-tenant,
name,
spaces
or
other
name
spaces.
Let's
say
whatever
reason.
Whatever
business
justification,
you
had
to
run
that
pod
is
privileged
and
you
wanted
to
do
so
cloud
security
policies
previously
allowed
you
to
do
that
where
you
could
actually
bind
it
to
the
deployment
controller
or
the
actual
account
doing
the
deployment
or
managing
those
those
pods
there.
H
That
inherently,
is
a
bad
thing
by
default,
it's
exploitable
it's
vulnerable
and
those
people
now
have
access
to
be
able
to
kind
of
circumvent
that
security
model
and
that's
where
it
comes
back
to
being
that
namespace
boundary.
So
like
what
I'm
getting
at
is
like
a
sane
operator,
developer
would
say:
okay,
it
makes
sense
we're
going
to
lock
down
this
multi-tenant
namespace
for
all,
like
the
real
people
quote-unquote
in
this
box
or
this
bubble
of
policy.
H
But
now
this
operator
can
run
a
privilege
pod.
That
makes
sense
from
a
pod
security
policy
model
and,
I
say,
make
sense
with
like
air
quotes,
because
we
know
that
there's
some
risk
there
or
some
reasoning
behind
that
that
doesn't
necessarily
make
sense.
So
the
shift
to
the
namespace
segmentation
being
the
lowest
level
of
enforcement
makes
a
lot
of
sense
to
me.
A
Yeah,
I
I
think
the
crux
here
is:
if
you
have
name
spaces
where
you
have
pods
that
are
privileged
and
unprivileged,
you
may
want
to
reconsider
that,
because
now
you're
going
to
have
to
give
the
highest
privilege
for
that
name
space.
Even
if
some
ports
don't
need
it
and
then
does
that
mean
you
move
the
parts
to
a
different
name
space
so
that
all
your
privileged
stuff
works
in
one
name,
space
and
others
and
unprivileged.
J
Well,
that,
and
that
impacts
other
things.
I
imagine
network
security
too,
so
geez.
A
All
right,
good
nice
discussion
and
thank
you
jim
for
bringing
this
up
anything
else
from
anyone.
We
have
about
five
minutes
more.
A
All
right,
if
not,
it
was
great
having
all
of
you.
Thank
you
ray
savita
for
posting
with
me,
we'll
put
the
link
on
the
meeting
notes
once
it's
available
for
the
recording,
especially
and
see
when
see
you
all
in
a
couple
of
weeks.