►
From YouTube: Kubernetes SIG Security 20210211
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
Hi,
everyone
hope
everyone's
doing
good,
so
we
have
two
new
items
that
got
added
last
week.
B
One
of
it
is
rory
is,
I
think,
he's
on
the
call
he's
working
on
kubernetes
hardening
guide,
so
good
progress
is
being
made
there
and
the
other
one
is
that
a
few
folks
volunteered
to
write
a
follow-up
blog
post
on
the
psp
deprecation,
so
they
would
bring
their
own
perspective
on
what
could
be
the
alternatives
and
just
it
would
be
all
about
their
own
perspective,
so
it's
not
advocating,
but
it's
just
putting
out
what
is
available
like
a
replacement
right
now
and
stuff
like
that.
B
So
these
are
the
two
things
that's
in
progress
right
now
and
john
osborne
presented
a
spreadsheet
full
of
security,
readings
and
vulnerabilities,
and
it
was
like
a
whole
sheet
of
what's
actionable.
What's
not
actionable
so
for
now
we
decided
not
to
add
it
to
the
website,
because
we
don't
want
to
have
third-party
content
in
the
website.
A
Awesome
so
for
the
for
the
hardening
guide
that
rory
is
working
on.
Is
it
currently
in
a
state
where,
where
rory
is
it
currently
in
a
state
where
you
want
to
continue
working
on
an
initial
draft
of
it
by
yourself
and
then
and
then
ask
for
you
know
community
input
on
it
or
or
would
you
like?
Would
you
like
people
to
jump
in
on
it
now?
Oh
so.
C
Yeah
hi
all
so
yeah
at
the
moment,
it's
mainly
kind
of
a
brainstorming
document,
so
just
kind
of
trying
to
flesh
out
what
it
should
do,
what
it
should
cover
and
what
it
shouldn't
cover
as
much
as
what
it
should
cover
right
to
try
and
get
a
decent
scope.
So
that's
quite
focused
to
begin
with.
I've
already
had
some
great
feedback
from
tim
bannister,
but
if
anyone
else
would
like
to
feedback
on
it
suggest,
changes
or-
or
you
know,
provide
some
opinions.
C
That'd
be
fantastic
and
it's
linked
out
of
the
out
of
the
minutes.
For
the
sake
security,
docs
meeting.
A
A
I'll
come
back
to
this
after
the
meeting
and
and
fill
in
the
link
there.
Thank
you
so
much.
That's
that's
going
to
be
awesome.
I'd
like
to
ask
about
the
follow-up
blog
post.
Is
this
separate
from
and
a
follow-up
to
the
draft
blog
post
that
is
coming
together
right
now
and
let
me
try
and
find
the
let
me
try
and
find
the
link
to
that
which
is
in
slack
somewhere.
A
Yeah
is
that
is
that
separate
from
the
one
that
is
in.
B
Progress
yeah:
it's
it's
one
in
progress
by
the
six
country,
books,
yeah,
it's
a
separate
one.
It's
going
to
be
a
follow
up
on
just
to
talk
about
what
are
all
the
available
replacements
and
user
perspective.
So.
A
Okay,
and
is
that,
is
that
then,
going
to
be
written
from
a
what
is
available
as
a
replacement
right
now
perspective,
or
does
that
include?
A
B
A
Let's
make
sure
that
we,
let's
make
sure
that
we
talk
about
that,
because
I
think
the
idea
of
this
blog
post
sounds
wonderful,
but
I
am
also
afraid
if
it
goes
out
from
a
assumption
that
kubernetes
is
just
simply
dropping
psp,
with
no
replacement
that
people
will
think
that
we
are
dropping
psp
with
no
replacement,
so
so
yeah.
Let's,
let's
make
sure
that
we
that
we
have
a
conversation
about
that
if
you'd
like
I'd,
be
happy
to
catch
you
up
on,
what's
going
on
with
psp
replacement.
A
Actually,
that's
that's
a
thing
that
that
I
was
hoping
to
to
share
a
little
bit
later,
but
that
that
sounds
that
sounds
good,
especially
the
like
collecting
of
various
of
various
perspectives.
Is
there?
Is
there
any
public
document
where
that
is
getting
started
yet.
B
No,
it's
it's
not
it.
We!
It
was
at
the
end
of
the
meeting
last
time,
so
we
just
threw
out
some
other
points
and
I
think
rory
is
one
of
the
volunteers.
So
I'll
let
him
speak
if
he
has
anything
to
add
and
if
I
got
anything
wrong
captured
anything
wrong.
So
I
could
definitely
bring
it
up
in
the
next
meeting
and
talk
more
about
it
and
I'd
love
to
hear
more
about
psp.
B
I
can
check
in
with
you
offline,
I'm
gonna
catch
up
on
the
some
notes
or
something
to
familiarize
myself,
and
I
can
check
back
in
later
with
yeah.
A
If
you
look
in
the
sig
off
meeting
notes
the
we
had
a
meeting
about
psp
replacement
and
ad
hoc
meeting
about
it
yesterday
and
also
spent
quite
a
bit
of
time
discussing
it
at
the
the
most
recent
sig
off.
So
if
you
look
at
the
sig
off
meeting
notes
you
can
you
can
find
a
lot
of
that
discussion
there
and
yeah
totally
happy
to
to
to
you
know
help
you
get
caught
up
in
any
in
any
other
way
that
I
can.
B
That's
wonderful
so
for
now
we'll
continue
to
brainstorm
on
this,
but
and
we'll
park
the
idea
that
we
will
publish
something
before
we
have
something
solid.
So
we
I
would
like
to
continue
having
this
conversation
in
the
other
meeting,
but
it
will
not
be
published
unless
and
until
everyone
is
on
the
same
page.
So.
A
Plus
one
to
all
of
that,
I
I
I'm
going
to
put
on
my
hat
of
I
promise
to
come
and
represent
the
third
party
security
audit.
Folks
to
let
everybody
know
that
we
have
published
a
request
for
proposal
for
kubernetes
code
audit
by
a
third
party
auditing
firm,
there's,
a
link
to
it
here
in
the
notes-
and
it
is,
it
is
live
third
parties
can
respond
to
it
now.
A
So,
if
you
want
to
spread
the
word
about
that
and
try
to
increase
the
number
of
of
consulting
firms
that
might
consider
responding
to
it,
that
would
be.
That
would
be
lovely
if
you,
if
that's
a
thing
that
you
want
to
be
involved
in
the
the
link,
is
here,
and
I
think
that
we'll
have
fun
results
out
of
it
again
like
we
did
last
year.
A
Alana,
do
you
do
not
talk
about
prr.
D
Yes,
hi
everyone
for
those
who
have
not
met
me,
because
I
don't
normally
attend
six
security
meetings.
I'm
alana
hashman,
I'm
chair
of
sig
instrumentation
and
involved
in
signod,
but
this
is
has
nothing
to
do
with
instrumentation
or
sig
node
tabby
and
ian,
and
I
talked
a
little
bit
about
like
some
of
the
security
considerations
of
various
caps
that
were
being
raised,
and
one
of
my
concerns
is
that,
right
now
in
the
sort
of
cap
review
process,
there
isn't
really
like
a
security
review
stage.
D
It's
kind
of
expected
to
fall
to
the
chairs
of
each
sig
to
like
think
through
that
stuff,
but
there
may
be
varying
levels
of
you
know,
familiarity
with
security
analysis
amongst
chairs
and
whatnot
I
mean
that's.
Not
the
only
job
of
a
chair
chairs
have
many
jobs,
and
so
one
of
the
things
that
I
looked
into
and
asked
question
about
was
well.
D
We
have
this
production
readiness
review
now
and
those
folks
are
responsible
for
reviewing
things,
for
you
know
something
to
be
ready
to
go
to
production,
and
so
would
they
be
able
to,
for
example,
like
incorporate
some
security
review
into
their
reviews.
D
So
I
asked
the
question
at
their
meeting
yesterday
and
I
am
hopefully
joining
that
team
as
well,
and
the
response
that
I
got
was
basically
that's
not
the
focus
of
those
reviews,
they're
they're,
trying
to
catch
sort
of
like
how
do
I
run
this
thing
in
production
and
how
do
I
turn
this
feature
on
and
off
and
ensure
that
it
doesn't
like
you
know,
take
out
a
running
cluster
and
that
kind
of
thing
that
I
can
mitigate
damage
like
from
you
know
something
gone
awry
which
is
totally
reasonable,
but
basically
their
their
thought
was
that
prr
is
not
really
a
place
for
security
review.
D
That
should
really
be
done
by
the
chairs
or
maybe,
if,
like
security
has
opinions,
perhaps
they
can.
You
know
weigh
in
so
given
that
I
am
now
here.
That
is
the
the
word
from
prr.
I
don't
know
if,
like
obviously
we're
mostly
done
the
the
cap
reviews
for
this
cycle,
so
this
is
more
of
a
future
releases
sort
of
thing.
D
But
I
don't
know
if
anybody
has
thoughts
in
terms
of
how
to
ensure
that
you
know
various
caps
that
may
have
security
considerations
in
terms
of
the
functionality
they
add,
get
proper
security
reviews
before
we
go
ahead
and
add
the
features
and
we're
not
just
catching
things
like
retroactively
in
third-party.
E
E
We
have
a
this,
is
I'm
a
tech
lead
for
sig
docs,
and
we
have
a
related
challenge
in
sig
docs,
which
two
related
challenges,
which
is
one
when
a
feature
graduates?
How
do
we
make
sure
it's
documented
and
the
one
that's
relevant
to
security
is:
how
do
we
make
sure
it's
documented
on
how
to
deploy
this
securely
and
things
do
do
reach
stable
without
having
having
that
in.
D
Place
yeah,
I
guess
right
now
we
do,
I
think,
we're
doing
better
as
a
project
in
terms
of
the
doc's
work.
Like
definitely
now,
I'm
at
the
point
where
you
know
I've
done
a
few
of
these
cycles
and
nowadays
enhancements
team
will
say
you
cannot
graduate
without
doc
vr.
So
that's
that's
been
a
great
great
improvement
there,
but
yeah.
We
really
don't
have
anything
like
that
for
security
right.
D
A
Yeah
that
that
feels
like
a
service
that
we
could
provide
to
the
rest
of
kubernetes,
but
it
would
would
require
a
a
critical
mass
of
people
who
wanted
to
provide
that
service
and
and
a
way
of
of
sort
of
rolling
up
utilization
of
that
service
like
right.
Now,
I
guess
merely
by
existing.
We
have
a
bit
of
an
opt-in
model
because
you
know
we
do
have.
We
do
have
folks
who
will
tag
sig
security
on
caps
or
on
issues.
A
You
know
not,
because
we
have
to
bless
something
before
it
can
go
forward,
but
because
by
putting
sig
security
on
a
cap
or
on
an
issue,
you
know
it.
It
brings
it
to
the
attention
of
this
group
and
it
makes
it
likely
to
show
up
on
the
meeting
agenda
so
that
we
can
so
that
we
can
show
it
to
the
to
the
folks
here
in
the
community,
but
like
for
for
the
docs
review.
How
did
that
evolve?
Historically?
A
Was
that
a
was
that
a
process
where
you
said
we
want
to
insert
ourselves
as
a
as
a
hard
stop
in
the
in
the
release
process,
or
was
that
a
thing
where.
D
D
D
Yes,
please,
it
started.
A
A
Or
how
did
you
evolve
that
over
time,
like
from
a
opt-in
thing
like
did
it
turn
into
more
of
an
aggressively
helpful
kind
of
thing
until
eventually
others
clamored
to
have
you
inserted
in
a
mandatory.
A
A
E
I
would
say
that
I
don't
think
zigdocs
is
actually
involved
in
prs
or
if
it
is,
I
haven't.
I
haven't
seen
that
we're
involved
yeah
yeah.
E
Yeah,
forcing
people
to
open
a
documentation,
pr
nudges
them
to
fill
it
in,
because
people
don't
like
having
an
empty
commit.
I
guess
that's
that's
the
strength
of
it
really.
A
E
Sig
release
has
been
basically
sig.
Release
has
ended
up
doing
a
lot
of
stuff
that
I
think,
is
really
outside
their
roommate.
Oh
no,
that's
like
very
min,
as
in
I'm
happy
with
it,
but
we
have
we
and
sig
docs.
Have
bennett
benefited
from
sig
release
being
really
helpful
and
insisting
on
things
that
nudge
people
to
do
what
what's
good
for
the
community.
A
Okay
and
so
like
right
now,
a
lot
of
the
a
lot
of
that
documentation,
improvement
in
in
things
when
they
get
merged
comes
from
sig
releases,
insistence
that
there
be
a
documentation
pr
associated
and
then
either
they
fill
in
that
documentation
or
they
come
to
sig
release
and
ask
for
help.
E
Yeah,
so
some
examples
of
things
that
have
slipped
through
is
that
stuff
has
graduated
and
still
been
marked,
as
beta
in
all
the
documentation.
E
Stuff
has
been
documented
as
the
beta
feature,
and
you
know
the
graduation
to
be
too
stable,
hasn't
has
rounded
off
some
stuff,
and
that's
not
mentioned,
but
overall,
like
I
think
before
that
started
to
happen,
things
were
graduating
to
from
alpha
to
beta
and
not
being
documented
at
all,
and
it
was
getting.
This
process
has
meant
that
more
stuff
gets
caught
and
the
people
writing
golang
code
are
being
nudged
to
tell
people
how
to
use.
A
It
to
what
to
what
extent
has
has
docs
been
involved
in
that
then
like
like
do
do.
Do
they
come
to
you
to
ask
for
help
sometimes
like
we're,
we're
not
really
sure
what
to
do
about
writing
this
or
or
do
you
just
kind
of
watch,
it
happen.
E
E
Yeah
and
as
soon
as
you
know
that
there's
a
placeholder
pr
for
something
like
something
something
say:
someone
was
adding
pod
security
policy
and,
and
there
was
a
placeholder
pr
for
it,
you
can
go
look
at
the
code.
It's
it's
signposts
that
help
might
be
needed.
A
A
D
About
doc's,
no
craig
said
in
the
chat:
we'd
have
to
have
significant
resources
to
do
per
feature
security
reviews.
I
just
wanted
to
touch
on
that
briefly,
like
the,
for
example,
with
the
production
readiness
reviews
they're,
not
like
an
in-depth
or
analyzing,
like
all
of
the
possible
scalability
concerns,
they're
more
of
just
kind
of
a
first
pass
and
trying
to
make
sure
that
the
authors
are
thinking
about
the
right
things.
I
think
that
we
would
not
have
to
do
like
an
in-depth,
like
security
analysis
of
each
feature
or
anything
like
that.
D
But,
for
example,
like
one
of
the
things
that
came
up
in
sig
node
was
folks
wanted
to
add,
like
a
flag
to
the
cubelet,
to
take
an
argument
which
was
a
path
to
an
arbitrary
binary
for
the
cubelet
to
exec,
and
I
said
you
know
this
could
go
horribly
wrong
in
many
ways
like.
Let
me
talk
about
them.
You
know,
you've
got
a
c
and
a
v
and
I
could
be
the
e.
D
But
like
that
sort
of
thing
is,
you
know
it's
definitely
discussed
by
chairs,
but
sometimes
there's
like
oh
well,
but
we
have
precedent
of
having
things
like
that
in
cube
already,
we
don't
really
have
like
a
high
level
review
of
that
sort
of
thing
happening,
and
so
you
know
it's
great
that
we
catch
a
lot
of
the
stuff
in
the
third-party
security
reviews.
But
again
that's
that's
retroactively
like
how
do
we
move
this
conversation
a
little
earlier?
So
it's
not
just
like,
oh
well.
C
I
think
that
there's
definitely
scope
for
having
something
which
is
like
a
list
of
you
know.
Does
your
feature
do
these
some
of
these
things?
Does
it
work
in
some
of
these
areas?
If
it
does,
you
might
need
to
consider
talking
to
someone
you
know:
do
you
exact
arbitrary
boundaries
right?
You
probably
want
to
have
a
conversation
with
some
people
about
how
that
works.
Yeah.
That
might
be
because
there
would
be
something
for
people
to
look
at
and
they
could
say.
Okay,
you
know,
do
we
do
these
things?
G
Yeah,
I'm
a
bit
of
a
newcomer,
so
I
don't
want
to
go
away
out
of
my
comfort
area
and
suggest
anything,
that's
crazy,
but
flagging
certain
files,
you
know
containing
certain
information,
certain
sensitive
security
implications
and
and
going
in
depth
to
review
those
and
flagging
others.
As
you
know,
not
necessarily
so
critical
and
doing
initial
passes
on
those
so
that
way,
resource
security
review
resources
are
allocated
properly
could
be
a
good
approach.
B
So
I
have
a
question:
where
do
you
see
these
getting
captured
like
during
the
cap
review
process
or
when
the
idea
is
pitched
to
various
chairs
or
the
sick
themes
like?
Where
would
this
be
captured
so
that
it
can
be
referred
back
later
if
needed,
or
would
it
go
on
the
enhancement
proposal.
D
D
I
don't
think
we're
obviously
going
to
come
to
any
sort
of
overarching
solution
in
the
context
of
this
meeting,
and
I
don't
want
to
take
up
too
much
of
your
time,
but
I'm
thinking
like
it
might
be
good
to
add
something
at
the
the
point
where
a
feature
is
proposed,
that
we
ensure
that
we're
doing
some
sort
of
review
to
make
sure
that
it's
sensible
and
that
the
authors
are
thinking
about
the
right
things
like.
E
So
the
point
where
stigdox
gets
interested
is
is
the
graduation
from
alpha
to
beta,
because
that's
where
it
gets
the
stuff
gets
enabled
by
default,
and
actually
I
don't
mind
if
alpha
features
are
undocumented,
like
they're
alpha
like
I
prefer
them
to
have
at
least
a
page,
but
if
someone
puts
in
a
pr
to
document
an
alpha
feature
and
it's
not
great
I'll
ship
it,
you
know,
and
I'm
the
same
with
like
something
that
security
features
if
you've
got
a
like
dangerous
exec
and
it's
an
alpha
feature
behind
a
feature
gate.
E
Well,
you
know
if
you
like
to
live
dangerously,
go
ahead,
but
when
stuff
goes
beta,
big
difference-
and
that
is
where
I
would
look
at.
Essentially,
a
release
has
just
happened.
What
just
went
alpha
that
sig
security
needs
to
know
about,
and
how
do
we
find
that
stuff.
B
So
the
the
one
of
the
reason
that
I
asked
this
because
for
docs
at
least
in
the
release
we
we
asked
the
owners
that
hey
do
you
have
anything
related
to
documentation.
B
You
want
to
update
or
something
so
that's
how
we
start
tracking
it,
and
we
can
nudge
the
authors
that
okay,
you
need
to
create
a
placeholder
pr,
something
like
that
and
then
sick
dogs
comes
in
a
play
after
that,
and
it's
very
helpful
and
reviews
and
all
those
things
happen
after
we
at
least
know
that
these
people,
these
owners
are
at
least
going
to
create
a
dock
or
not,
and
there
are
many
that
slip
through
that
who
doesn't
even
whose
feature
doesn't
even
get
tracked
in
the
release,
and
they
just
have
documentation
or
they
don't
update
the
documentation.
B
But
there
is
an
ongoing
process
that
sig
releases
are
trying
to
fix
with
the
new
kept
process.
The
reason
I
asked
is
that
if
we
want
to
add
one
other
column
to
the
sig
release
process,
hey
do
you
need
any
seek
security
review
or
like
I
could
bring
this
back.
Bring
this
to
see,
release
and
ask
like
we
started
a
conversation
like
this
and
how
do
you
feel
about
adding
another
column.
A
I
yeah
I
I
would
have.
I
would
have
some
pretty
deep
concerns
about
like
inserting
ourselves
as
a
mandatory
hard
stop
in
any
kind
of
thing,
but
I
would,
I
would
feel
pretty
good
about
having
a
hey.
You
can
talk
to
this
group
of
people
and
and
and
they
will
be
happy
to
help
you
if
you
think
that
you
need
it,
I
would.
I
would
be
totally
in
favor
of
that,
like
certainly
as
a
first
step
just
like
advertising,
there's
a
group
of
people
here
they
care
about
this
subject.
B
That
sounds
good
to
me.
It's
one
less
question
for
the
owner:
it's
already,
they
are
all
they.
I
feel
like
the
the
cap
owners
and
teachers
and
the
reviewers
are
already
burdened
with
too
many
processes
and
too
many
questions
to
answer
we
can
advertise
and
but
the
onus
where
the
owners
would
lie
like
with
the
caponer
or
the
the
sick.
That's
sponsoring
the
cap.
B
When
these
questions
can
come
later,
we
can
always
brainstorm
these
questions
and
ask
them
later,
but
I
just
want
to
throw
that
out,
and
I
don't
want
to
take
a
lot
of
time
on
this.
A
A
Yeah
yeah,
I
think
I
I
I
like
that
idea.
I
don't
know
if
you
want
to
talk
about
that
next
time,
you're
talking
to
release
or
if
we
want
to
follow
up
like
with
a
slack
thread
about
how
do
we?
How
do
we
want
to
move
forward
with
this
but
yeah?
I
I
like
the
idea
of
trying
to
go
forward
with
something.
That's
that's
super
lightweight
and
it's
just
like
hey.
A
We,
we
exist,
we're
happy
to
help
you
if
you
want
help,
because
because
then
we
can,
then
we
can
help
without
hindering
and
that
that's
a
thing
that
I'm
really
concerned
about,
like.
I
think
all
of
us
want
to
help,
but
it's
important
not
to
hurt,
while
we're
doing
that.
B
Either
one
sounds
good
to
me:
I
can
just
let
them
know
that
hey,
we
are
there
and
ask
their
opinion
on
how
they
feel
about
it,
and
I
can
just
bring
it
back
and
we
can
also
have
a
slack
thread
and
then
pull
everyone
in
and
have
a
conversation
there.
A
I
guess
we'll
we'll
move
on
to.
There
was
a
couple
of
things
that
I
just
wanted
to
announce
to
share
with.
Everybody
should
be
pretty
quick
pot
security
policy
replacement
discussions
are
continuing
and
we
we
have
taken
over
a
fair
amount
of
security
meetings
and
we
have
taken
over
a
fair
amount
of
sig
off
meetings,
and
so
now
we
have
moved
to
a
couple
of
ad
hoc
meetings.
There
was
one
that
happened
yesterday.
The
notes
from
that
are
in
the
sig
off
meeting
notes,
there's
one
that
will
be
happening
again.
A
A
The
other
thing
that
I
wanted
to
just
advertise
to
the
group
here
is
the
kepp
2168,
which
was
put
in
a
little
while
ago.
That's
proposing
adding
some
feature
to
yell
at
users
in
a
way
when
containers
are
running
as
root,
because,
ultimately
a
lot
of
us
are
saying
don't
run.
A
Containers
is
root,
but
unless
you
are
building
all
of
your
container
images
yourself,
starting
from
the
plan
of
not
running
them
as
root
just
being
yelled
at
don't
run,
containers
as
root
is
not
actually
helpful,
because
you
know,
if
you're,
using
a
container
that
somebody
else
has
built.
That's
on
the
assumption
that
it
runs
as
root.
Then
you
start
running
it
as
some
non-root
user,
and
you
know
everything
breaks
because
of
file
permissions
problems
or
or
whatever
so
so,
yeah.
A
That's
it's
a
it's
a
challenge
and
I
think
the
the
only
perfect
solution
is
to
address
it
at
the
very
root
by
discouraging
the
use
of
doctor
files
that
don't
have
user
and
some
user
in
them.
A
H
All
right
cool,
I
just
wanted
to
stir
the
pot
on
that
also
just
to
be
clear,
like
as
as
a
person,
I'm
happy
if,
like
me-
and
I
know
michael
levski,
dion
is
also
working
with
me
on
it,
like,
as
people
were
happy
to
be
the
people
who
own
it.
It's
more.
Just
like
the
bureaucratic
concern
of
yeah.
A
H
Okay,
cool
glad
to
not.
I
I
Yeah
we've
released
1.2
today,
and
I
saw
that
there
was
a
sick
security
meeting
today.
So
I
I
came,
I
think
most
of
the
sig
security
or
oath
meetings
are
really
late
in
the
day
in
europe,
but
this
one
was
quite
like
it
is
six
here
in
france.
So
it's
fine.
A
A
You
know
if
you've,
if
you've
got
everyone's
attention
for
a
couple
of
minutes.
What
would
you
like
to
tell
us
about
cert
manager.
I
I
Yeah
but
sir
I've
been
I've
been
joining
as
a
third
manager.
Member
okay.
A
I
A
Thank
you.
Do
I
remember
correctly
that
that
that
kube
adm
generates
certs
using
cert
manager
or
or
am
I
incorrect
about
that.
H
I
I
Maybe
some
companies
they
want
to
use
yeah
I
could.
I
could
go
on
with
many
things
but
yeah
and
we
are
working
on
integrating
so
right
now
we
have
the
certificates,
signing
request
that
is
in
kubernetes
and
allows
new
nodes
to
join
the
cluster,
so
the
cubelet
is
going
to
create
the
csr
and
it
gets
approved.
But
the
thing
is
it
gets
approved
manually,
so
you
have
to
do.
Keep
cuddle
certificate
approve
and
it's
not
great
and
that's
something
we
we
are
trying
to
do
right
now.
I
We're
trying
to
have
such
manager
use
this
api
and
be
able
to
approve
the
css
yeah.
A
A
Well,
all
right
with
with
all
of
us
here
is
there.
Is
there
any
last
fun
thing
that
anybody
would
like
to
bring
up
to
the
group.
J
I
will
mention
a
quick
thing
that
I
learned
yesterday,
I'm
I
have
a
caveat
on
this,
but
I
learned
that
the
most
popular
container
that
is
being
run
anywhere
is
nginx.
J
Which
is
which
says,
first
of
all,
that
you
know
kept
about
warning
about
it,
that's
a
great
idea,
and
secondly,
it's
one
of
the
reasons
why
I'm
a
bit
concerned
about
this
inability
to
punch
holes
in
a
security
policy
for
whatever
replaces
psp.
I
worry
that
any
namespace
that
runs
nginx
is
going
to
have
a
loose
security
policy
or.
A
So
like
it's,
it's
frustrating
that
we
have
I'm.
This
is
all
totally
my
opinion,
not
like
official
zig
security
stance
or
anything
just
to
be
clear,
but
like
it's
unfortunate
that
we
have
so
many
years
of
docker
defaulting
things
to
root
and
doing
so
many
good
things
to
defang
what
it
means
to
run
as
root,
because
that
has
made
things
better,
but
also
has
made
it
really
hard
to
do
what
is
in
some
sense
the
most
basic
unix
security
thing
and
stop
running
as
root.
A
Yes,
yeah
yeah,
so
like
any
namespace
that
wants
to
run
this
nginx
container
has
to
at
least
allow
containers
to
run
as
root
like.
I
hope
that
it
will
still
prevent
containers
running
you
know
with
privileged.
You
know
prevent
containers
running
in
host
pid,
prevent
containers
running
in
host
ipc
like
all
of
all
of
those
real
bad
things,
but.
J
Do
you
know
where
there
is
the
plan
is
to
allow
it
to
mount,
or
will
it
have
any
rules
around
what
can
be
mounted
from
the
host.
A
Like
like,
as
far
as
as
far
as
the
in-host
path
yeah,
I
I
don't
actually
recall
offhand
how
one
configures
that
in
psp
today,
yeah
the
the
bare
minimum
pod
security
proposal
doesn't
address
it
at
all,
because.
A
I
H
C
That
you
can
put,
I
saw
it
the
other
day,
actually,
bizarrely,
on
a
test.
You
can
specify
a
path
because
I
thought
they'd
allowed
host
path
volumes
and
I
went
oh,
you
can
specify
parts
in
there.
I
had
no
idea,
so
you
could
say
you
allow
host
path
volumes,
but
then
only
these
paths
they'd
let
they
allowed
like
devnet.
I
think
it
was
for
some
reason.
J
Mid,
oh,
I
can't
tell
if
she's
frozen
again,
I
think
she's
still.
F
A
A
I
mean
it's
anyway,
the
the
the
name
escapes
me
so
yeah,
like.
A
If
you
want
to,
if
you
want
to
run
nginx-
and
you
don't
want
to
run
it
as
root,
then
you're
building
your
own
nginx
container
and
like
that's
good,
if
you're,
that
particular
about
what
you're
going
to
be
doing,
but
also
a
lot
of
the
sales
pitch
of
docker
as
a
tool
to
make
operations
easier.
Was
you
don't
have
to
build
all
of
your
own
containers?
You
can
use
official
containers
and
things
will
be
great,
so.
A
I
I
just
want
to
register
for
those
who
are
who
are
listening,
that
craig
has
made
a
face
about
the
idea
of
you
can
just
grab
your
random
containers
off
of
off
of
docker
hub
yeah.
It's
it's
such
a
mixed
bag
right.
A
So
yeah,
that's
that's
a
that's
a
great
thing
to
to
point
out
liz.
Thank
you
like
if,
if
we
want
to,
if
we
want
to
push
towards
helping
people
have
like
the
the
minimum
sort
of
admission
control
on
things,
we
can
do
that
without
solving
the
root
problem,
but
but
also
solving
the
root
problem
is
a
good
additional
goal
to
have
in
mind
and
so
yeah.
That's
why?
A
I
that's
why
I
like
this
this
cap,
I
don't
know
exactly
how
it
could
shake
out
as
a
feature,
but
just
like
making
something
a
little
more
obvious,
hey
you're
doing
this
thing,
maybe
you
don't
realize
it
and
it's
not
the
worst
possible
thing
you
could
be
doing,
but
it
would
be
good
to.
It
would
be
good
to
take
steps
to
stop.
J
E
E
Yes,
tim,
I
mean
just
just
shout
out
like
I
have
a
thought
off
the
top
of
my
head
and
I
think
that
it's
going
to
horrify
different
people
in
different
ways.
What
I
now
realize
is
that
the
future
of
pod
security
policy
or
of
policy
in
this
area
might
actually
tie
into
image
signing,
and
you
might
say
I
don't
want
anything
to
run
as
a
route.
Here
are
some
signatures
of
the
exceptions,
and
I
didn't
realize
until
really
what
liz
pointed
out
today,
how
valuable
that
might
be.
A
It's
a
it's
a
thing
that
it's
a
thing
that
I've
thought
about
a
lot
too,
and
I
really
wanted
to
propose
it
in
in
you
know
the
the
work
that
I
was
doing
toward
the
toward
the
psp
plus
plus
proposal,
but
we
don't
have
the
other
features
there.
Yet
you
know
so
like
right
now,
that's
a
thing
that
you
could
do
say
with
with
gatekeeper.
A
A
You
know
like
it
would
not
necessarily
be
hard
to
do
with
gatekeeper,
something
like
you
can
admit
these
pods
with
these
particular
elevated
settings,
but
only
if
they're
specified
only
if
the
container
images
are
specified
by
shaw,
hash
and
the
shaw
hash
is
on
this
list
of
shaw
hashes
like
that,
isn't
totally
waterproof,
but
it
does
greatly
restrict
the
amount
of
of
the
amount
of
attack
surface
that
you're
giving
to
people.
A
You
know
you
can
still
potentially
do
bad
things
with
them,
but
but
at
least
it
is
a
it's
at
least
a
start,
but
also
the
operational
burden
around
that,
unless
you
have
other
automation
could
really
hurt
like
if,
like
if
you,
if
you
ever
want
to
run
an
updated
pod
so
that
you
can
have
updated
face
images
so
that
you
aren't
just
carrying
around
old
cves
in
code
that
you
don't
really
care
about.
J
J
H
J
A
Yeah
yeah
and
like
my
nightmare
with
that,
is
putting
some
kind
of
policy
engine
in
place
that
is
actually
more
of
a
burden
on
the
people
doing
operations
legitimately
than
it
is
on
people
who
are
doing
operations
illegitimately,
because
what
is
a
successful
attacker?
Besides
a
system
administrator
without
permission,
but
like
it's
easy
to
accidentally
build
ham-fisted
policy
things
that
people
just
need
to
turn
off
to
get
their
jobs
done.
J
J
You
know
massive
improvements,
but
in
practice
people
end
up
just
turning
off
because
it
turned
out,
they
prevented,
couldn't
do
what
they
needed
to
do,
and
people
are
lulled
into
a
false
sense
of
security
because
they
thought
they
had
something
and
it's
actually
been
turned
off
in
order
to
get
applications
running.
A
I
mean
honestly,
I'm
a
little
bit
worried
that
that
I
may
be
coming
close
to
being,
like
perfect,
is
the
enemy
of
good,
with
respect
to
punching
holes
in
policy
for
particular
things,
because
that's
the
that's
the
use
case
that
everybody
has
as
a
as
a
counter
example
like
to
both
of
the
proposals
that
are
out
for
replacing
pod
security
policy
is.
But
how
do
you
say
this
pod
can
can
use
dangerous
features
and
none
of
the
other
pods
in
the
name.
Space
can
and-
and
I've
been
saying-
I
want
that.
A
But
on
the
other
hand,
if
people
can
solve
that
problem
by
adding
namespaces
like
if
you
have
a
namespace
that
runs
six
different
pods,
one
of
which
needs
to
run
privileged.
I
would
say
make
another
namespace
with
the
same
name
as
that
one,
but
with
privileged
at
the
end
and
move
that
one
privileged
pod
into
that
namespace.
J
A
J
People
have
all
sorts
of
sort
of
organizational
associations
with
namespaces.
You
know
people
quite
often
have
a
namespace
per
team
and
suddenly
you're
saying
oh
well.
If
that
team
uses
you
know
some
privileged
pods
they've,
actually
now
they've
got
to
have
two
namespaces
and
that
that
could
get
that
could
explode,
that
that's
yeah.
E
So
what
I
see
with
amazon
web
services
and
the
recommended
layout
for
accounts
as
a
security,
boundary
and
amazon
web
services
is
that
what
people
do
is
that
they
deploy
like
an
audit
record
and
they've,
got
a
really
secure
set
of
things,
none
of
which
run
any
workloads.
E
A
A
A
Yeah,
thank
you.
Thank
you
so
much
for
for
coming
and
and
sharing
your
thoughts,
and
you
know
you
you
too
rory.
I
appreciate,
I
know
it's.
I
know
it's
a
little
later
in
the
day
for
you
as
well,
so
you
know
for.