►
From YouTube: Kubernetes SIG Security Meeting 20210408
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
It's
it's
for
after,
and
the
number
of
folks
here
in
the
room
has
plateaued
so
I'll
say.
Thank
you
all
for
your
patience.
As
always,
and
thank
you
once
again
for
coming
to
another
kubernetes
sig
security
meeting.
Do
we
have
anybody
who
can
take.
B
A
Well
I'll
take
I'll
take
notes
for
your
topic.
All
right
sounds
good
awesome.
That
way,
I
won't
get
flustered
trying
to
take
notes
and
also
smile
at
you
all
at
the
same
time.
So
hello
first
thing
that
we
have
here
on
the
list
is.
I
will
happily
speak
on
zavita's
behalf
because
she
is
out
there
with
the
others
getting
the
1.21
release
ready
to
be
official,
but
it
sounds
like
good
progress
has
been
being
made
in
docs
with
the
hardening
guide
coming
along
actually
rory.
C
Yeah,
that's
that's
right.
It's
got
started.
If
anyone
would
like
to
participate,
we
we
have
a
document
for
that
and
yeah
we're
hoping
to
start
making
some
more
solid
progress
over
the
next
little
while.
A
That's
awesome
and
yeah
looks
like
security
checklist
is,
is
an
idea,
that's
kind
of
based
on
riffing
on
the
hardening
guide
and
kind
of
giving
it
to
giving
the
giving
an
index
into
the
content
in
a
different
way.
That
would
be
more
accessible
to
a
certain
audience
like
people
who
just
want
to
think
about
their
cluster
without
having
to
think
about
the
entire
hardening
guide
at
once.
A
B
Yeah,
so
we've
been
having
some
issues
getting
proposals.
We
have
one
proposal
and
various
members
of
the
subgroup
have
have
reached
out
and
we
reach
out
to
a
number
of
of
of
third
party
companies
for
this.
The
security
audit
just
some
thoughts.
B
I
just
want
to
get
a
temperature
check
and
just
a
feedback
and
just
on
what,
if
we
prioritize
and
and
make
this
scope
a
little
bit
smaller
for
the
for
the
audit,
we
feel
that
it
might
be
too
big,
and
I
know
a
lot
of
security
companies
are
very,
very
busy.
They've
told
us
firsthand
or
some
some
have
told
us
firsthand-
that
in
that
they
are
very
busy
and
scope
might
be
a
little
bit
too
big
to
take
up
a
lot
of
staff
members
time
as
well.
B
There's
so
do
want
to
bring
bring
up
a
few
things,
not
just
the
scope
as
well.
If
we
could
reduce
the
scope,
maybe
prioritize
what
is
important
for
for
this
year's
security
audits.
Maybe
we
could
table
some
of
those
components
until
next
year's
security.
Audit
also
gotten
some
feedback,
also
on
the
on
the
schedule
as
well,
because
a
lot
of
these
security
companies
are
very
tight
on
schedule.
If
we
could
be
more
more
relaxed
on
the
schedule,
so
do
want
to
get
some
thoughts
about
those.
A
B
A
D
A
E
C
I
think
one
thing
thing
that
making
it
slightly
trickier
is
the
rpe
correctly
asks
for
named
individuals,
so
the
people
on
the
rfp
have
to
be
people
doing
the
work.
So
if
you've
got
specialist
resource
and
you're
basically
saying
yeah,
you're
gonna
have
to
block
out,
especially
these.
You
know:
you're
people
don't
have
a
lot
of
people
who
can
do
this?
In
my,
I
guess,
there's
not
a
lot
of
people
who
can
say?
Yes,
I'm
you
know,
go
code
with
your
there's,
not
a
huge
number
of
those
so
saying
we
want
these
name.
C
Resources
for
this
block
is
that
well.
That
means
you
that
person
is
out
of
the
loop
for
that
period
and
that,
I
think,
could
you
know
if
a
company
for
smaller
companies
that
that
could
be
like
a
big
commitment.
So
I
guess
is
that,
but
that
maybe
come
back
to
ray's
point
about
reducing
scope.
They
would
be
less
jumpy
because
they're
not
trying
to
book
out
like
six
weeks
of
their
key
resources,
they're
looking
at
smaller
chunks,
which
is
kind
of
more
manageable.
D
Yeah
last
time
around,
we
couldn't
get
vendors
to
commit
the
names
of
people
that
they
would
have
working
on
a
project.
For
that
very
reason
you
know
they
said
we'll
have
you
know
one
person,
that's
focused
on
crypto,
but
they
wouldn't
say
who
it
was
because
we
had
a
tight
schedule
for
them.
In
the
end,
we
let
them
pretty
much
dictate
the
schedule.
We
pushed
it
out
several
times
so,
but
one
other
thought
I
had.
D
If
we
are
reducing
the
scope,
then
maybe
that
makes
it
easier
to
do
to
start
work
on
the
next
audit
because
it
can
be,
you
know,
a
non-overlapping
scope
to
some
extent.
So
we
could
start.
You
know
soliciting
proposals
and
so
forth
for
the
for
a
follow-on
audit,
while
the
current
one
is
in
progress.
If
that's
what
the
schedule.
E
Requires
probably
something
to
think
about
on
the
third
party
product
called,
but
would
it
maybe
make
sense
to
sort
of
just
as
a
straw,
man
come
up
with
a
list
of
components
that
we
would
test
or
one
after
the
other,
to
see
what
that
looks
like.
A
It
seems
like
a
sensible
as
sensible
a
plan
as
any
rory.
I
kind
of
want
to
go
back
to
the
like
named
individuals
thing
like
that
feels
like
there's
a
lot
of
tension
there,
where
we
think
that
the
named
individuals
requirement
is
really
important
to
the
quality
that
we
want,
but
also
is
making
it
really
hard
to
get
the
the
rfps.
A
I
mean.
Obviously,
anybody
in
the
room
who
wants
to
speak
from
from
a
point
of
experience
as
a
consultant.
C
I
think
it's
that
that
is
both
right.
So
it's
it's
important
because
you
want
to
get
the
right
people,
but
it
is
where
you
have
like
special
skills
trying
to
block
out
like
six
weeks
of
a
key
specialist.
That
person
is
in
demand,
so
if
they
commit
to
that-
and
they
say-
and
I
think
if
we
have
more,
if
we
communicate
flexibility
and
schedule,
that's
going
to
help.
If
we
say
look,
you
know
we're
not
tired
on
this
being
this
particular
window.
Then
they
go
okay,
you
know.
C
A
About
that
flexibility
of
of
schedule,
like
I
feel
like
there's
two
dimensions
to
it,
there's
the
one
dimension
of
when
do
we
start
this
like
six
week
period,
but
then
there's
also
the
like.
Assuming
no
other
changes,
we
want
to
pay
for
six
weeks
worth
of
billable
hours,
but
do
we
insist
that
that
takes
place
in
real
time
like
within
a
six-week
block
or
would
there
be?
Would
there
be
reasonable
like
would
it
be
helpful
to
vendors?
A
B
So
we
on
the
rfp,
we
actually
said
we
estimated
roughly
12
weeks
which,
which
is
to
be
very
flexible,
but
I'm
just
addressing
feedback
on
what
we've
heard
from
from
reaching
out
to
other
security
companies
on
possibly
possibly
being
more
flexible,
and
I
think
you're
right
about
the
implication
of
like
the
start
date
of
like
rfp
closes
and
we
don't
necessarily
state
a
start
date.
But
it's
more
implied.
B
B
Concerns
yeah,
like
being
like.
We
could
be
very
explicit
and
say
we,
we
are
flexible
on
start
date.
We
are
flexible
on
the
on
the
amount
of
time
that
we
think
it's
going
to
take,
or
I
think
we
should
have
loose
boundaries,
no
matter
what
I
think
we
can't
be
super
flexible
and
have
to
have
the
ought
to
come
in.
You
know
one
year
later
or
but
we
should
still
have.
A
B
F
Well,
when
people
don't
show
up
for
a
meeting,
it
makes
it
easy
to
ditch
so
good.
For
me,
the
so
forgive
me
if
I
pronounce
this
rom
is
it
pushkar.
F
And
I
chatted
briefly
in
slack
a
week
and
a
half
or
so
ago,
and
he
has
generously
volunteered
to
take
my
place
as
the
quasi
owner
of
the
tooling
sub
group
raga
also
piped
up,
so
he
could
help
out
if
needed
so
I'll
still
be
around.
I
can
help
out
as
needed
too,
but
that's
really
the
the
news
is
that
I'm
passing
the
mantle.
A
That's
that's
awesome
I'll,
say
I'll
say:
welcome!
Welcome
pushkar,
like
y'all
have
the
ability
to
define
what
you're
going
to
do
based
on
where
you
think
the
needs
are
and
and
who,
who
shows
up
to
want
to
help.
So,
please
make
sure
to
you
know
reach
out
both
to
the
group
like
here
or
in
slack
and
also
specifically
to
to
reach
out
to
me
and
ian
as
co-chairs
to
tell
us.
A
You
know
anything
that
we
can
do
to
to
help
you
out
or
advise
you
and
you
know,
get
get
y'all
up
to
speed
with
making
tooling
improvements.
So
yeah
welcome
and
you
know
no,
no
pressure,
like
we'll
figure
it
out.
Yeah.
G
G
A
Thank
you
so
much,
there's
a
there's.
A
couple
of
couple
of
little
things
here
that
I
added
to
the
beginning
of
discussion,
say
once
again
happy
release
day.
1.21
is,
is
shipping
to
get
today,
so
many
people
have
done
so
much
to
make
that
happen,
and
some
of
them
are
here.
Some
of
them
can't
be
here
because
they're
actively
making
it
happen
congrats
to
all
of
you.
The
the
other
thing
is,
I
wanted
to
say
something
briefly
about
the
progress
for
psp
replacement.
A
All
right,
well,
we've
been
having
the
the
breakout
meetings
with
the
folks
from
here
and
the
folks
from
sigoth
and
and
everybody
else
who
wants
to
show
up
and
in
those
breakout
meetings,
we've
continued
to
work
through
the
unresolved
sections
of
the
draft
cap
for
the
pod
security
policy
replacement
and
we're
we're
chewing
through
them.
Like
progress
is
moderate
and
steady.
So
I
want
to
thank
tim
explicitly
for
running
those
meetings
and
and
helping
to
keep
that
moving.
A
Other
thing
that
that
I
would
like
to
say
about
that.
Is
we
published
a
blog
post
that
several
of
us
collaborated
on
writing
about
psp
deprecation
and
the
work
that's
being
done
to
replace
it
and
the
fact
that
there
are
good
alternatives?
A
I
I
tweeted
about
that
and
so
far
it's
like
46
000
views
like
650
clicks
through
to
the
blog
post,
which,
like
I
think
1.3
conversion
rate
would
be
great
on
an
advertisement,
and
since
this
was
just
like
me
saying:
hey
y'all,
we
wrote
a
thing,
I'm
I'm
feeling
pretty
excited
about
that
and
no
flames,
so
either
the
spicy
people
haven't
found
it
yet
or
we
did
a
good
job
of
telling
people
what
they
needed
to
hear.
A
So
so
that's
that's
out
there
and
if
you,
if
you
haven't,
read
it
and
have
time,
go
check
it
out,
I
I
think
we
did
a
good
job
with
it
tim
you
do.
You
have
something
that
you
want
to
add
or
no.
H
No,
I
agree
with
all
that,
thanks
for
all
your
contributions
as
well,
it
was
a
great
blog
post,
so
happy
to
see
that
out
there
and
getting
good
engagement
still
needs
a
name.
We
will
save
the
flames
for
that.
A
Yeah
yeah
I
personally
kind
of
like
the
pod
isolation
policy
name,
except
for
the
fact
that
it
makes
it
seem
like
we're
putting
kubernetes
on
a
on
a
pip
which
is
going
to
have
a
lot
of
bad
connotations
for
people
in
the
tech
industry
so
like,
even
if
you
haven't,
contributed
in
other
ways
to
this
like.
If
you
got
name
ideas.
Please
come
over
to
the
cap
because
we're
all
going
to
be
sitting
with
this
name
for
a
decade
into
the
future.
So
we
want
to
make
sure
that
we
really
like
it.
H
I
also
like
pod
isolation
policy.
We've
got
three
levels,
maybe
if
we
want
to
like
make
it
a
little
more
specific,
we
can
call
it
pod,
isolation,
policy,
three
or
pip
three.
A
Awesome
next
up,
we
have
some
discussion
about
adding
capabilities
to
containers
that
don't
run
as
root.
I
Yeah,
thank
you
for
bringing
this
up
from
last
time.
Tabitha.
I
intend
this
as
sort
of
a
discussion
item.
We've
run
into
some
problems
with
trying
to
run
containers
as
non-root
in
kubernetes
and,
like
I'm,
interested
to
hear
if
other
people
have
this
problem
and
what
kind
of
solutions
you
found.
So
maybe
a
quick
intro,
it's
a
fairly
basic
principle
of
like
container
security
that
you
should
be
running
your
stuff
as
a
not
root
user.
I
So
let's
say
that
you're
trying
to
run
a
server
and
you
need
to
bind
to
a
low
port.
Well,
if
you
want
to
run
it
as
non-root,
you
would
need
to
give
it.
The
capnet
bind
service
capability
and
your
your
container
only
needs
that
capability
to
be
able
to
do
that.
So,
if
you
do
the
sort
of
intuitive
thing
and
you
go
in
your
pods
back-
and
you
say,
okay
in
the
security
context
run
as
user,
something
that's
not
zero,
and
then
the
capabilities
capnet
bind
service
out
of
the
box.
I
This
will
not
work
because
listing
the
capability
in
the
security
context
only
puts
it
in
the
inherited
in
some
other
capability
set
capabilities.
Analytics
are
a
bit
of
a
mess,
but
if,
if
you
actually
want
to
be
able
to
use
the
capability,
then
during
the
build,
you'll
need
to
set
the
capabilities
on
the
binary
itself
using
something
like
setcap
to
get
it
into
the
effective
set.
So
that's
what
we've
been
doing
to
get
around
this
and
I'm
just
curious
to
hear
if
other
people
have
run
into
this
problem.
H
There's
an
open
issue
somewhere
that
I
can
go
and
dig
up
but
yeah.
I
think
what
we
need
to
do
is
add
support
for
ambient
capabilities,
yeah
capabilities.
Thank
you.
That
would
be.
H
I
Very
nice,
yeah
fnatic
and
myself
have
actually
been
talking
about
writing
up
a
cap
for
this.
So
it's
nice
to
see
that
there's
interest.
H
Yeah
definitely
strongly
encourage
you
to
do
so.
I'm
happy
to
help
kind
of
connect
to
some
folks
who
might
have
some
input
on
that.
If
you
yeah,
I.
A
A
Just
like
a
little
a
little
bit
of
of
additional
context
that
that
I
would
like
to
put
on
here
the
thing
about
putting
like
running
setcap
on
your
binary
when
you're
building
your
container
image,
even
that
isn't
totally
foolproof
either
because
like
if
you
are
building
your,
if
you're,
building
your
container
image
using
a
docker
daemon,
that's
configured
to
use
user
namespaces,
then
the
tarball
that
you
get
as
your
container
image
has
those
capabilities
set
in
such
a
way
that
they're
only
active
inside
the
same
usernamespace
config
that
the
docker
daemon
assigned
to
it
at
build
time
and
rather
than
being
set
for
if
you're
running
inside
the
host
username
space.
A
This
was
a
thing
that
some
of
my
teammates
at
datadog
ran
into
and
like.
Actually,
they
have
a
a
pretty
good
talk
coming
up
in
kubecon
eu
about
it
and
so
like
yeah,
the
having
an
ability
to
set
in
a
pods
spec
or
in
a
container
security
context.
Ambient
capabilities
would
make
all
of
those
problems
go
away,
and
I
would
I
would
love
to
see
it.
I
Very
nice,
okay!
Well,
thank
you
very
much
for
your
feedback
tim
thank
you
for
offering
help,
I'm
sure
that
it
will
be
needed.
Thank
you
very
much.
D
A
I
A
D
A
Yeah
yeah,
I
I
would
just
I
would
assume
that
it
does
and
since
a
lot
of
container
build
tooling
is
going
towards
rootless.
You
know
rootless
in
quotes
because,
like
you
actually
do
end
up
using
root,
but
it's
like
fake
group
through
username
spaces,
since
everybody
seems
to
be
adopting
that
approach.
I
think
this
problem
is
only
going
to
get
worse
and
so
yeah.
Maybe
now
is
the
time
to
get
a
kept
like
this
rolling
so
that,
before
this
problem
becomes
more
widespread,
kubernetes
can
have
a
decent
solution
to
it.
I
Very
nice
yeah
we'll
get
we'll
get
started
on
that.
A
I
can't
resist
sharing
my
one
of
my
favorite
little
bits
of
silly
trivia
here,
which
is
the
way
that
this
interacts
with
privileges
allow
privilege
escalation
false,
which
sets
the
no
new
privs
flag
on
the
processes
in
the
container.
D
A
So
if
you
have
a
container
that's
running
as
non-root
and
using
capnet
bind
in
the
pod
spec
and
set
on
the
binary
and
has
no
new
privs
set,
the
capnet
bind
will
work
anyway,
but
only
if
the
thing
that
needs
capnet
bind
is
the
entry
point.
If
it
is
a
child
process
of
the
entry
point
like
if
you're,
using
tiny
or
if
the,
if
the
process
forks
and
then
tries
to
bind,
then
it
won't
work,
because
no
new
privs
will
prevent
it
from
from
getting
that.
A
D
A
A
Yeah,
I
I
assume
that
there
is
some
really
deep,
docker
history
here
at
work
in
in
what
has
caused
the
exact
timing
of
when
certain
flags
are
set
on
processes
during
container
startup,
and
I
personally
wasn't
around
for
those
discussions,
and
so
I
don't.
I
don't
really
know
yeah.
If
you
do
it,
please
get
back
to
us
on
slack,
because
I
would
love
to
know
the
answer
to
that
question.
Thank
you.
Tim.
That's!
Brilliant!.
H
A
Yeah
and
for
that
reason
I
assume
that
the
answer
is
no
because,
like
I
know
many
of
the
individuals
who
were
involved
in
these
discussions-
and
I
would
expect
that
this
was
dealt
with
but
always
good-
to
verify
things.
A
Pj,
it
looks
like
we
don't
have
lori
here.
Do
we
want
to
talk
about
this
kept
liaison
opportunity.
G
Yeah,
I
can
cover
for
her
and
catch
up
with
her
later,
if
that's
okay,
so
she
shared
with
me
a
couple
of
days,
maybe
last
week
about
this,
and
maybe
you
and
her
have
had
a
chat
about
this
as
well.
Basically,
the
idea
is
for
all
the
six
that
are
involved
for
a
release
where
the
sig
needs
to
review
a
or
one
or
more
than
one
kept.
G
She
was
thinking
that
currently,
it
sort
of
defaults
to
the
co-chairs
to
figure
out
whether
that's
taken
care
of
whether
we
have
enough
feedback
from
the
sigs
etc
and
co-chairs
such
as
yourself
are
already
doing
so
many
other
things.
So
what
she
was
proposing
is
could
we
have
some
sort
of
a
liaison
between
the
release,
team
and
asic?
G
So,
in
our
case,
it
would
be
security
and
that
individual
would
be
responsible
for
either
giving
feedback
themselves
or
asking
asking
or
making
it
more
use
easier
for
others
to
give
feedback
to
a
cap
or
more
so
she
was
thinking
like
this
is
something
you
would
be
able
to
bring
up
in
the
next
weekly,
and
I
thought
might
be
worth
getting
some
thoughts
and
I
am
happy
to
do
that
until
there
are,
if
there
is
anyone
else
who
wants
to
volunteer
as
a
liaison.
G
This
is
another
thing
she
shared
is.
This
is
a
good
opportunity
for
a
volunteer
who
doesn't
necessarily
wants
to
write
code
or
doesn't
want
to
have
any
doesn't
have
maybe
any
interest
in
doing
code
related
contributions.
So
for
those
people
as
well,
this
might
be
a
good
opportunity
if
anyone
is
interested.
A
I
think
this
is
a.
I
think
this
is
a
really
cool
idea.
I
think
that
it
applies
very
well,
especially
to
a
horizontally
focused
sig
like
ours,
where
you
know
we,
we
don't
have
a
natural
ownership
of
certain
areas
based
on
who
who
reviews
code
in
those
areas,
because
we
don't
have.
We
don't
have
the
code
that
that
needs
those
kinds
of
reviews.
A
This
also,
this
also
is,
is
really
nicely
related
to
discussions
that
we've
been
having
related
to
the
annual
reports
around
how
we're
trying
to
get
get
a
good
idea
of
what
it
would
look
like
for
our
sig
to
have
one
or
more
tech
leads,
because
it
seems
like
a
natural
like
a
natural
sort
of
of
fit
for
somebody
who
has
the
the
bandwidth
and
the
interest
and
the
you
know,
desire
to
to
learn
more
and
and
grow
their
network
in
kubernetes,
with
with
a
slightly
different
level
of
commitment
than
what
you
know
we
have
as
as
co-chairs.
A
So
I
really
I
really
like
this.
Thank
you
so
much
for
for
bringing
it
up
and
we
will.
We
will
talk
about
it
amongst
ourselves
and
then
and
then
also
talk
about
it
with
everyone
else,
which
cap
is
this
now
I
mean
actually
what
what
else
I'm
so
sorry
what
what
thoughts
does
does
everybody
else
have
about
this.
B
So
I
like
the
idea
a
lot
since
I've
been
part
of
the
release
team
for
a
number
of
releases
now
and
it's
always
an
evolution
on
the
release
process
on
how
to
engage
cigs
for
pr
reviews,
either
code
based
reviews,
test
reviews,
documentation,
reviews
and
we
and
there
and
most
most
time
most
sigs
do
a
great
job
in
conducting
these
reviews.
B
But
we
do
tend
to
rely
on
those
sick
chairs,
so
it'll
be
great
to
have
another
another
person
to
to
reach
out
to
and
who
has
those
connections
within
that
say
on
who
to
delegate
a
proper
review
yeah.
So
I'm
I'm
a
big
plus
one
for
this.
G
Yeah
say
same
same
thoughts.
What
you
mentioned
as
well.
One
thing
did
come
up
in
the
thread
I
linked.
There
is
some.
Some
people
were
considering
that
this
person,
whoever
it
would
be
for
any
sake,
would
have
to
be
fairly
active
and
on
point,
because
if
the
person
who
is
responsible
for
liaison
is
themselves
not
really
available,
then
it
they
could
become
a
bottleneck
in
a
way.
A
All
right,
I
think
you
got
the
next
thing
there,
which
cup
is
which
cap
is
this?
Can
you.
G
I
think
we
have
the
cap
owner
in
the
call
as
well
vinayak,
so
this
is
the
one
for
cube,
adm
control,
plane
on
run
as
non
route.
G
This
was
one
of
sort
of
a
guinea
pig
I
used
for
this
liaison
process
to
bring
it
up
in
the
channel
and
see
if
there
is
some
interest
and
then
I
added
my
comments
as
well,
so
I
mean
like,
if
you
want
to
share
some
more
about
the
progress
on
that
kept
since
we
talked
about
it
last
week.
Last
time
we'll
go
ahead.
J
J
So
yeah
like
we
are
super
open
to
more
comments
from
like
the
wider
community
or
like
even
like
the
lies
on
us
krishna
pointed
out
before
yeah.
So
it's
been
very
helpful.
Getting
comments
on
that.
A
J
I
think
more
different
people's
points
of
view
being
represented
is
always
helpful,
but
the
since
this
is
like
my
first
time
writing
it.
So
I
really
don't
have
a
baseline
of
like
what
is
the
minimum
requirement
to
like
at
least
get
it
to
a
point
where
we
call
it
implementable
and
we
kind
of
go.
J
Do
the
work
like
some
of
the
things
that,
like
most
of
it
to
me,
is
like
security,
best
practices,
anyways
that
we're
trying
to
enforce
so
like
if
we
get
the
go
ahead
from
like
security
on
that,
then
we're
like
cool.
I
think
we
have
enough
there
to
like,
go
and
implement
it.
J
So
some
of
those
like
things
that
we
are
doing
like
creating
groups
for
like
shared
credits,
right,
like
let's
say,
cube
apis
or
we're
in
cube
control
manager,
share
a
particular
like
cert
or
something
that
they
both
mount.
Then
like
we're
creating
groups
and
then
just
just
like
verifying
our
proposal
helps
a
lot
and
gives
us
the
confidence
that
hey
we're
not
doing
something.
A
When
I
have
when
I
have
skimmed
the
comments,
it
looks
like
the
sort
of
ambient
folks
around
around
that
around
that
pr
have
been
pretty
helpful
in
navigating
the
cap
process.
Do
you
feel,
like
you,
have
all
the
support
that
you
need
there
or,
or
would
it
be
helpful
if
somebody
who
was
more
experienced
with
getting
caps
in
could
come
to
give
you
advice
specifically
about
that.
J
Yeah
any
help
would
be
like
welcome.
I
think
I'm
getting
enough
support.
J
It's
just
like
I'm
kind
of
failing
to
understand
like
at
what
point
should
we
merge
it
right
like
there's
from
my
side,
I
think
it's
like
there's
enough
information
there
for
us
to
go
and
implement
it,
because
it's
all
this
mostly
security,
best
practices
so
like
I
want
to
kind
of
transition
to
like
let's
go
to
this
stage,
but
I
think
there
are
a
few
things
that
need
to
be
like,
probably
broken
down,
which
is
like
how
we
assign
these
ids,
and
I
think,
once
that
happens,
we
should
be
able
to
merge
it.
A
I'm
I'm
I'm
glad
to
I'm
glad
to
hear
that,
and
I
guess
I
would
like
to
call
out
something
that
you
said
there
where,
where
it
sounds
like
specifically
somebody
who
has
an
interest
in
sort
of
traditional
unix
security
hardening,
like
you
know,
the
appropriate
creation
of
shared
groups
and
and
setting
setting
permissions
on
file
system
entries
according
to
those
in
ways
that
grant
the
shared
access
that's
needed
without
granting
it
too
broadly.
A
Somebody
with
that
kind
of
experience
it
sounds
like
could
be
especially
helpful
for
you
right
now.
So
if
anybody,
if
anybody
has,
has
got
that
and
and
has
got
some
bandwidth
free,
this
is
a
this
is
a
good
opportunity
to
carry
some
water.
It
might
be
worth
it
might
be
worth
making
a
post
in
sig
security
and
also
in
the
kubernetes
security
channel,
which
has
a
few
thousand
people
in
it.
A
On
slack
like
asking
specifically
for
that,
like
hey
the
the
cap
for
running
kubediam
as
non-root,
is
coming
along
fine,
we
have
a
a
specific
need
for
some
for
some
advice
and
validation
of
our
choices
around
unix
file
system
permissions.
If
anybody
with
experience
in
that
area
would
like
to
come
and
help,
please
do
like
that.
That
might
be
a
that
might
be
a
way
that
you
could
could
get
some
more
interest
and
some
more
help
in
that
way.
A
Good
luck!
Thank
you
so
much
for
continuing
to
to
share
this
with
us.
Anybody
else
have
anything
on
this.
G
One
last
thing,
maybe
I'll
say,
is
I'm
happy
to
plus
one
whenever
you
post
the
details
with
inter
why
this
some
context
on
why
this
skip
is
important
and
useful
for
security,
so
that
people
hopefully
may
get
more
excited
reading.
What
I've
written.
A
G
I
I'm
sort
of
feeling
embarrassed
like
I
have
too
many
topics
for
my
first
live
meeting,
so
I
I'm
happy
to
do
that
in
the
next
meeting.
If
others
have
any
topics
don't
want
to
like
hawk
the
meeting
time.
A
I
mean
we
can
we
could
take
a
vote
if
you
like,
but
I
I
feel
like
this
is
a
place
for
us
to
for
a
place
for
us
to
share
things
that
may
be
of
interest
to
others,
and
so
so
I
mean
I'd
I'd.
I'd
love
to
hear
about
it.
G
All
right,
okay,
so
there's
some
context
on
this.
Some
of
you
might
be
tracking.
G
This
go
team
from
google
recently
started
a
discussion
on
vulnerability
database
for
golang,
which
is
sort
of
based
on
go
modules
and
what
they
are
trying
to
do
is
create
some
sort
of
a
new
command
called
go
audit,
which
will
allow
us
to
have
a
better
signal
to
noise
ratio
on
vulnerabilities
in
dependencies
of
big
projects
like
kubernetes,
so
some
of
the
people
from
kubernetes
code
organization,
slack
channel,
which
is
a
sub
group
of
if
I'm,
not
wrong
cigar
architecture.
G
They
have
started
to
discuss
this
with
them,
and
one
of
the
things
that
might
come
up
is
as
part
of
sort
of
a
real
world
test
scenario
for
this
feature,
and
also
to
get
more
actual
feedback
or
they're
going
to
try
and
run
it
on
kubernetes
repo
itself
and
see
what
turns
out.
G
I
am
happy
to
make
introductions
happy
to
start
the
process
and
in
in
parallel
also
we
have
some
other
related
threads
to
vulnerability
management,
so
we
can
keep
keep
them
going
in
parallel
as
well.
A
That's
that's
really
cool,
and
I
I
also
love
it
as
a
as
a
good
opportunity
for
like
a
bootstrapping
project
for
for
that
for
that
subgroup
yeah.
So
so
I
I
really
love
that.
I
I
also
wonder
whether
any
of
the
psc
folks
who
aren't
here
today
might
be
interested
in
this,
so
I'll
I'll
bring
it
up
with
with
the
psc
as
well
in
case
in
case
there's
interest
over
there.
A
Well,
thank
you
all
right
now,
we've
got
now.
We've
got
like
the
open
floor.
Does
anybody?
Does
anybody
have
anything
new
that
they
would
like
to
add
that
hasn't
made
it
onto
the
meeting.
A
A
Thanks
well
then,
yeah
with
that
I'll
say
like
I
always
do
at
the
beginning
and
ending
of
these,
and
I
mean
it
every
single
time.
Thank
you
so
much
for
coming.
It's
it's
great
to
see
you
it's
great
to
to
see
all
of
our
collected
thoughts
put
together
here
and
the
ways
in
which
we're
able
to
help
out
with
making
kubernetes
better
so
happy
release
day.
Everyone.