►
From YouTube: Kubernetes SIG Security 20220421
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Great
looks
like
we
have
people
in
short
attendance
today,
but
that's
good.
Maybe
people
are
enjoying
their
breaks.
A
Yeah,
I
hope
that
I
hope
that
folks
are
are
having
are
having
a
good
time.
I
bring
best
wishes
for
everyone
from
ian
who
is
not
able
to
attend
today,
but
I
was,
I
was
told,
literally
share
share
my
best
with
everyone.
So
so,
even
though
they
are
not
here,
we
know
that
kubernetes
security
is
in
their
heart
at
the
moment,
since
it
seems
that
we
are
going
to
be
since
this
is
our
group
for
today,
should
we
jump
into
it
all
right,
so
we're
going
to
be
officially
calling
it
started.
A
Welcome
to
another
kubernetes
sig
security.
It
is
awesome
to
see
everybody.
We've
got
some
things
on
the
on
the
list
today,
given
the
attendance
that
we
have.
I
will
take
notes
this
time.
C
So
the
audit
third
party
security
audit
tend
to
be
starts
on
may
9th,
we'll
be
using
version
124,
which
has
been
delayed
to
may
3,
and
it
is
scheduled
to
tentatively
finish
around
mid-june.
We
we,
it
is
in
the
works
to
have
a
kickoff
meeting
next
week,
so
update
the
sig
when
that
is
scheduled.
C
I
will
also
make
an
announcement
on
today's
monthly
community
kubernetes
community
meeting,
since
I'm
also
the
host
of
hosts
of
that
that
we
are
having
at
their
party
security
audits
this
year.
That
is,
should
be
a
good
general
community
interest
topic.
A
A
All
right
then
docs
sounds
like
sounds
like
checklist
is
in
progress.
That
sounds
awesome.
D
Yeah
hi
everyone.
Yes,
so
last
week
we
discussed
about
generalizing
generalizing.
This
checklist
not
have
like
specific
tool
or
links
specified,
so
I
took
the
feedback
back
and
the
team
is
actually
working
on
making
the
list
to
be
generic.
We
should
have
something
probably
next
time
I
I
know
I
told
this
last
time,
but
I
think
a
lot
of
work
came
during
this
time
and
couldn't
concentrate
on
getting
the
checklist
out.
So
we
should
have
something
by
next
week.
Next
meeting.
D
Yeah,
I'm
not
gonna
like
push
everyone,
but
if
it
happens,
it's
a
good
thing.
If
it,
if
it
gets
delayed,
then
we'll
highlight
it
in
north
america
cube
console.
B
D
That
it's
all
for
me,
I
see
ray
adding
something.
Oh
that's
the
oh.
C
C
For
our
back
good
practice,
guide
for
on
dot,
io
so
pasted
the
link
and
that
pull
request
is
open
and
under
review.
D
B
It's
happened,
oh
I
I
like
how
one
of
our
community
members
put
it.
We
are
incrementally
progressing
in
securing
our
supply
chain.
So
it's
it's
not
done
and
it
will
not
be
done
anytime
soon,
but
we
are
making
progress
there.
B
Basically,
the
current
status
is
a
all
new
kubernetes
releases
will
have
signed
images,
and
now
there
is
a
script
and
an
official
task
page
on
since
124.
That
will
explain
folks
how
to
manually
verify
it
on
their
side
when
they
are
trying
to
come
up,
bring
up
a
cluster.
So
that's
where
things
are
right
now,
which
which
is
also
good
in
the
overall
salsa
journey.
B
B
Next
one
is
usual
learning
session
update,
so
for
this
month
we
had
christoph
from
datadog
who
was
invited
guest
for
a
learning
session
on
a
tool
that
they've
been
working
on
called
stratus
red
team.
B
I
really
found
it
interesting
and
I
almost
felt
like
it
was
sort
of
home
delivery
of
setting
up
your
red
team
environment
instead
of
you
trying
to
cook
up
something
by
yourself
and
then
trying
to
do
some
things,
so
I
really
enjoyed
it.
The
slides
are
linked
in
the
meeting
minutes
and
there
is
a
similar
talk
on
this
topic
by
christoph
in
the
upcoming
cloud
native
security
con
in
case
you
want
to
meet
him
or
talk
to
him
live
at
that
time.
B
That's
it
on
tooling
I'll,
be
wait
until
we
move
to
self
assistance
for
any
questions.
D
I
just
have
a
shout
out
to
you
for
putting
that
little
demo
together.
It
was
so
nice
to
see
it
in
action,
and
I
think
it's
linked
in
that.
If
anyone's
interested,
please
feel
free
to
take
a
look
at
it.
It
was
like
first
for
someone
I
I
didn't
have
time
to
try
it,
so
I
could
just
visually
see
it
and
I
felt
like
so
happy
seeing
it.
You
know
a
little
little.
B
A
B
Yeah
I'll
do
a
short
update
and
allow,
if
you
have
anything
else
to
add,
go
for
it
be
for
cluster
api
self
assessment,
vr
review
still
in
progress.
I
was
able
to
knock
many
of
the
comments
from
cluster
life
cycle,
so
my
hope
is
in
the
couple
of
weeks
until
we
meet
next
time.
The
status
of
the
pr
would
change
from
draft
to
ready
for
review.
Assuming
like
we
get
everything
resolved
in
the
comments
and
then
we'll
see
after
that,
if
anything
else
needs
to
be
done.
E
E
I
am,
I
still
need
to
add
myself
to
the
members
file
and
just
want
to
shout
out
to
pushkar
for
being
so
helpful,
with
getting
myself
organized
to
officially
be
as
a
project
lead
and
also
wanted
to
update
that
my
boss,
tasha
drew
who
is
head
of
the
multi-tenancy
working
group,
shared
some
benchmarks
that
that
group
did
in
terms
of
making
sure
that
clusters
are
properly
configured
for
multi-tenancy
and
I'm
curious
to
kind
of
dig
into
that
and
see.
E
If
we
can
add
in
you
know,
just
get
some
cross-sig
vibes
going
and
you
know
probably
exploring
what
what
other
cigs
are
doing
in
terms
of
like
benchmarking,
for
configuration
and
going
from
there
so
yeah.
That's.
A
It
that's
that's
fabulous,
that's
exactly
the
that's
exactly
what
we
want
to
be
doing
here
like
if
somebody
is
doing
something
cool,
then
we
want
to
go
and
see
whether
it's
possible
that
we
can
help
them
to
push
it
forward
and
yeah.
Thank
you
for
thank
you
for
bringing
that
here
share
what
share
whatever
you
have.
If
there's
links
or
whatever
and
and
then
we
can
have
a
look
at
it.
A
Pusher,
do
you
want
to
tell
us
about?
Do
you
want
to
tell
us
about
the
the
private
triage
of
of
embargoed
vulnerability
information?
I
know
this.
B
Has
been
a
difficult
one
over
time,
yeah
so
with
some
context
here
so
sam
fowler
is
a
member
in
src
and
he's
been
working
with
tim,
all
clear
on
figuring
out
how
to
solve
one
problem.
So
the
problem
is,
let's
say
I
am
an
src
member
and
I
get
an
email
or
a
something
which
says
that
this
particular
sub
project
is
vulnerable
and
we
want
you
to
find
those
people
and
help
fix
it.
B
So
today
the
problem
is,
there
is
no
private
means
of
communication
to
figure
out
how
to
connect
with
the
sub
project
owners.
So
what
sam
was
telling
me
is
typically,
if
this
happens
and
tabby
you
can
add,
based
on
your
experience
is
we
have
to
find
first
github
ids
of
people
who
are
maintainers
of
a
sub
project
then
go
maybe
on
slack
and
ask
them
hey.
We
want
to
talk
about
something
on
src
related
to
src.
B
Can
you
send
like
an
email
address
we
can
reach
out
to,
and
then
we
start
that
conversation
and
that
takes
quite
a
lot
of
cycles
out
of
src
and
then
it
becomes
like
the
whole
process
of
triage
to
remediation
becomes
longer
and
more
more
or
less
manual.
So
we
were
thinking
about
like
what
potential
things
we
could
do.
The
hackmd
is
barely.
B
Does
it
barely
has
any
structure
but
they're
basically
notes
from
our
discussion,
so
it
it
really
boils
down
to
two
things
we
wanted
to
discuss
and
share.
So
sam
said
he's
gonna
share
it
with
src
members
as
well
and
I'll
do
the
same.
I
promised
in
this
meeting,
so
we
can
get
feedback
from
the
community.
B
So
the
first
phase
that
he
started
sort
of
getting
some
making
some
progress
was
we
have
a
security
context
file
today
and
an
owner's
file.
So
what
happens
in
case
of
that
is
both
the
files
have
github
ids,
but
there
are
some
problems
where
sometimes
people
reach
out
to
security
contacts
instead
of
src.
If
they
find
something
and
then
it
becomes
inconvenient
and
they
can't
really
involve
src
from
the
beginning-
and
one
thing
I
think
he
also
mentioned
was
sometimes
security.
Contacts
is
a
repo
level
thing,
whereas
owners
can
be
directory
level
thing.
B
B
So
one
suggestion
there,
which
I
wanted
to
get
feedback
was
maybe
we
could
make
the
security
contacts
field
as
optional,
so
that
and
the
assumption
behind
that
is,
anyone
who
is
owner
of
that
piece
of
code
would
typically
also
be
somebody
we
would
reach
out
to
for
security
related
issues,
because
they
would
know
the
best
of
whether
this
is
actually
vulnerable
or
intentional
or
maybe
benign,
and
that
also
reduces
any
manual
work
of
people
having
to
add
names
in
security
contacts.
B
If
we
make
it
optional
and
then
it
can
default
to
existing
approvers
and
reviewers,
so
that
was
phase
one.
There
is
another
phase,
two
discussion,
but
I
wanted
to
pause
and
get
some
thoughts
on
this
first.
A
I
mean
my
my
first
thoughts
on
that.
Are
that
imagine
the
circumstance
where
there
are
security
contacts,
but
perhaps
they
are
unresponsive,
then
the
like
next
recourse
would
be
to
go
to
the
folks
from
the
owner's
file
and
say
hey.
We
need
to
contact
someone
about
a
potential
security
issue.
Who
do
you
recommend
that
we
contact
about
that
and
so
making
that.
A
Explicit
seems
good
just
on
the
face
of
it
like,
if
that's
how
it's
going
to
have
to
be
anyway,
then
having
that
written
down
is,
is
better
than
having
it
be
sort
of
implicit
knowledge
and
the
other.
The
other
first
thing
that
I
think
about
that
is,
I
wonder
how
much
overlap
there
is
in
the
existing
repos
and
directories
between
the
security
contacts
file
folks
and
the
approvers
folks
in
owner's
files
and
like
that,
feels
like
a
like
an
opportunity,
if
somebody,
if
somebody
has
fun,
writing
shell
scripts.
A
That
feels
like
that
feels
like
a
nasty
shell
one-liner
that
could
pull
those
things
out
of
there
with
some
with
some
awk
and
said
and
compare
them.
So
if
somebody
wants
to
do
that,
a
I
encourage
you
and
b
if
you
get
stuck.
I
absolutely
love
writing
terrible,
like
write
only
code,
shell
one-liners
so
like.
If
somebody
wants
to
try
that-
and
you
get
stuck
reach
out
to
me,
because
I
would
be
super
excited
to
to
help
somebody
with
doing
that.
B
Yeah
I
agree
100
that
would
be
fun.
One
basically
seems
like
if
we
could
find
that
the
diff
is
really
small
between
owners
and
security
contacts,
then
it
would
make
more
sense
like
as
another
data
point
to
say,
security
contracts
could
be
optional
because
they
are
going
to
be
the
same
people
anyway.
So
yeah.
A
Then
that
reinforces
the
idea
that
okay
made
separate,
separate
security
contacts
is
important
and,
and
we
should
keep
pushing
on
the
bringing
the
automation
together
and
making
it
an
owner's
field
rather
than
continuing
to
be
a
separate,
separate
file,
and
until
then
we
just
have
intuition
and
we'll
use
our
intuition.
If
that's
all,
we
have
because
it's
better
than
nothing
but
but
it
would
be
cool
to
do
the
math
yeah.
B
Agree
so
if
no
more
thoughts,
the
second
piece
of
this
was,
we
still
don't
solve
the
problem
of
how
to
have
a
private
communication
channel
here,
because
it's
still
github
ids
and
we
still
need
to
talk
up
to
people
and
figure
out
where
to
continue
the
discussion.
B
B
So
the
idea
was
maybe,
and
also
the
other
thing
which
is
good
for
us.
Is
we
now
have
a
google
domain
for
creating
private
and
public
groups
called
kubernetes
dot
io.
B
So
once
we
have
that
mailing
list
in
place
and
because
the
naming
convention
would
be
simple,
it
would
be
easy
to
figure
out
which
mailing
list
belongs,
to
which
sig
or
for
this
sig.
What
would
be
the
private
mailing
list
address
so
once
that
is
in
place,
we
also
have
a
file
which
is
maintained,
obviously
in
yaml
called
six
dot
yaml,
where
we
have
a
list
of
six
and
a
list
of
sub
projects
that
they
own.
B
So
the
idea
was
what,
if
we
could
build
a
query
engine
with
maybe
a
very
simple
one
where
we
say
I
know
this
is
a
project
yeah.
B
Yeah
yeah
exactly
it
would
a
glorified
shell
script,
but
almost
like
a
queer
engine.
I
agree
yeah
and
then
we
could
say
I
want
to
know
what's
the
mailing
list
I
should
reach
out
to
for
this
sub
project
and
then
it
will
spit
out
a
mailing
list
address
like
let's
say
c
cluster
life
cycle
private,
and
then
we
share
that
from
src
side
like
hey,
we
found
this.
B
B
B
So
if
we
tell
them,
you
know
you're
sick,
the
best
you
know
your
sub
project
is
the
best
tell
us
which
people
need
to
be
added
or
you
add
it
yourself
and
continue
the
conversation,
and
the
second
benefit
of
this
would
be
people
might
move
on,
and
maybe
some
triages
take
months.
Sometimes
so
we
will
be
able
to
still
find
and
make
chairs
aware
that
this
is
still
open
and
they
can
maybe
help
prioritize
among
all
the
other
sick
activities
going
on
compared
to
what
is
expected
from
src.
B
So
that
was
a
second
kind
of
phase
two
which
will
solve
the
private
triage
problem
not
entirely,
but
it
will
make
it
life
easier
for
src
and
we'll
have
probably
better
visibility
from
chairs
overall
on
these
things,
so
thoughts.
C
I
was
going
to
say
that
there's
some
automation
in
place
already
on,
I
don't
know
my
creative
main,
creating
mailing
list
for
kubernetes.I,
oh
because
I've
recently
faced
or
it
where
you
would
run
a
script.
I
think
it
actually
is
a
shell
script.
I
want
to
actually
modify
the
files
for
you
which,
where
you
have
to
add
yourself,
so
I
think
we
have
some
sort
of
automation
place,
but
yeah
I'll
look
into
it.
B
Yeah,
my
from
what
I
remember
is
the
up:
if,
if
you
don't
have
permissions
to
create
groups,
you
can
request
a
github
issue
on
or
grepo,
I
think
on
kubernetes
and
that
will
trigger
like
people
getting
involved
and
discussing.
Why
do
you
need
this
so
on
and
so
forth,
but
I
agree
like
to
scale
it
for
all
the
six.
It
might
make
sense
to
kind
of
get
involved
and
get
all
of
them
together
in
one
issue.
If
we
decide
to
do
this.
A
Something
that
you
are
thinking
of
anyway,
or
is
that
like,
if
the
assumption
that
there
is
a
ton
of
overlap
between
owners
and
security
contacts,
is
true
or
like?
Are
you
imagining
this,
as
as
moving
beyond
having
security
contacts
and
then
like
essentially
establishing
security
contacts
on
an
ad
hoc
basis
through
the
sig
chairs?
For
each
time
there
is
a
report
where
it'd
be
like
okay,
you
know,
sig
fu
owns
the
area
of
code
where
this
potential
problem
is
sigfu.
Who
should
we
talk
to
this
time?.
B
Yeah,
the
for
the
I,
the
first
part
of
like
whether
security
contacts
file
itself
would
be
useful
anymore.
If
we
have
the
mailing
list,
maybe
it
would
be,
but
not
until
we
have
triaged
the
issue
and
we
know
how
to
fix
it.
So
when,
let's
say
we
need
reviewers,
we
could
ask
the
security
contacts,
people
and
maybe
the
owners
saying
this-
is
what
we
need,
or
people
can
actually
create
prs
to
fix
it,
because
sometimes
src
doesn't
have
enough
knowledge
about
that
piece
of
code.
B
A
A
That,
if,
if
this
is
if
this
is
a
way
forward
like
if
this
feels
like
a
good
way
forward
for
everybody,
then
in
the
future,
the
way
that
the
triage
would
work
would
be
like
a
report
comes
in
like
via
hacker
one
or
or
via
the
security
list,
and
then
src
does
some
initial,
like
consistency,
checking
on
it
like
like
making
sure
that
it
that
it
seems
like
it
is
valid,
and
then,
when
it
passes
that,
whereas
now
we
find
the
sub-project
that
it's
that
it's
affected,
and
then
you
know
figure
out
how
to
get
a
hold
of
the
security
contacts.
A
Instead,
we
could
email
the
the
private
list
for
that
sig
yeah,
like
for
those
sick
chairs
and
and
triage
by
asking
them
for
help
like
hey.
This
is
a
you
know.
This
is
a
potential
vulnerability
that
we
think
is
in
you
know,
code
from
your
subproject
foo,
then,
who
shall
we
like?
Who
shall
we
talk
to
at.
A
B
Exactly
and
I
think
the
other
pieces,
if,
if
we
folks
are
familiar
with
racy
model,
responsible,
accountable
consulted
and
informed
yeah,
the
sick
chairs
could
in
this
case,
be
accountable
for
triage
to
be
complete.
But
they
are
not.
A
Because,
like
in
the
in
in
the
case
where
we
can't
find
maintainers
or
we
can't
find
a
good
security
contact
for
something,
then
then
we
would
go
to
the
sig
chairs
and
we
would
say,
hey
sig,
chair,
please
help
we
are
having
this
problem
with
not
being
able
to
find
somebody.
So
please
help
us
find
somebody
or
if
nobody
can
be
found,
you
are
the
person
who
really
knows
yeah.
Sorry
we
are
like
underwater
like
sigfoo,
can't
can't
handle
this
right
now
and
then
we
say
all
right
cool.
A
Let's
you
know,
let's
see
what
we
can
do
to
help
with
that.
You
know.
Maybe
maybe
steering
can
can
talk
to
some.
You
know
can
talk
to
some
contributor
companies
or
something
and
and
encourage,
encourage
them
to
encourage
folks
to
be
able
to
work
on
sigfu's
stuff
when
they're
on
the
clock
or
whatever
yeah
exactly.
B
Exactly
that's,
that's
the
whole
intent,
and
I
think
I've
also
heard
from
some
src
members
that
some
triages
take
forever,
because
vp
people
are
not
great
at
follow-ups
or
people
are
busy
and
doing
other
things
or
people
move
on
to
different
roles.
So
as
long
because
the
chairs
are
always
going
to
be
there,
even
if
the
actual
chair
person
is
going
to
be
different,
we'll
always
have
somebody
who's
accountable
and
can
kind
of
keep
the
thread
going
and
maybe
allow
us
to
have
shorten
our
overall
triage
time.
This
is.
A
Again,
this
is
an
interesting
idea.
I
wonder
if,
if
the
intent
is
to
do
it
through
chairs,
specifically
as
opposed
to
like
through
security
contacts
that
may
or
may
not
be
chairs,
then
in
that
case,
I
wonder
if
we
could
do
that
through
the
pre-existing.
A
Kubernetes
dash
sig
dash
foo
dash
leads
lists
which
are
part
of
sig
governance,
like
the
creation
of
a
sig
involves
creating
that
list
anyway.
My
understanding
is
that
those
lists
are
not
currently
very
actively
used
like
that.
They
are
mostly
used
as
a
repository
for
permissions
right.
You
know
like
things
that
need
to
be
having
a
continuity
of
ownership.
A
As
you
know,
different
folks
come
in
and
leave
as
sick
chairs
so
like
like,
like
the
zoom
account,
for
example,
or
you
know,
google
docs-
that
need
to
be
owned
by
the
sig
or
whatever,
but
it
is
not
my
impression
that
those
are
are
heavily
used
for
like
sending
emails
like
actually
for
communicating,
and
so
if
the
intent
is
for
it
to
be
the
chairs,
then
maybe
those
could
be.
Maybe
those
could
be
used
because
they're
already
there.
A
That
mailing
list
exists
and
it's,
and
it
is
my
impression
that
it
is
mostly
used
like
as
an
iam
tool.
You
know
right
right,
like
that
you
can
that
way
you
can
assign
ownership
of
things
to
that
list,
but
where
you
can
grant
permissions
to
to
members
of
that
list,
that's
yeah!
That's
interesting.
I
assume
that
I
will
hear
from
sam,
like
when
I
have
my
src
head
on
next.
B
Yeah,
I
think
that's
the
biggest
thing
we
need
to
figure
out
like
we
have.
We
need
to
maybe
have
some
sort
of
pulse
check
like
this
is,
I
know
already.
Everyone
is
overburdened
and
under
the
water,
but
this
is
sort
of
important,
but
still
an
extra
responsibility
for
you.
What
are
your
concerns?
Yeah.
A
A
What
would
you
all
think
if
we
started
what
would
y'all
think
if
we
started
coming
to
you
with
with
with
asking
for
for
triage
help
on
potential
issues.
A
C
A
Because,
like
I
know
there
has
been
a
lot
of
discussion
of
it,
but
I
don't
see
a
lot
of
lgtms
on
the
on
the
github
pr
and
that's
sort
of
the
that's
sort
of
the
easy
to
reference
thing
forever
and
ever
to
be.
Like
did
a
lot
of
people
look
at
this
and
if
you
see
there's
a
lot
of
lgtms
than
that,
then
that
is
a
nice
sense
of
security
in
the
future.
So
anybody
who
wants
to
lgtm
that
last
call
otherwise.
A
Otherwise,
if
there's
things
that
you
think
of
that
really
need
to
be
addressed.
Obviously
please
bring
those
up
as
well.
Kubernetes
community
meeting
is
coming
up,
ray
has
dropped
to
to
prep.
For
that
he's
going
to
shout
out.
The
work
with
the
audit
kubernetes
community
meeting
is
always
is
always
a
good
time.
Let's
see
what
are
the
topics
for
this?
One
enhancements:
freeze,
renaming
kk
master
branch
to
maine
yeah
a
lot
of
a
lot
of
nice
things
here
in
this
topic.
A
So
if
you
were
interested
hop
on
that
last
thing,
which
I
think
I
will
end
up
pushing
to
the
next
time,
so
that
it
can
have
a
little
more
a
little
more
attention
since
we're
a
small
group
today,
but
some
folks
are
starting
to
look
at
what
it
would
take
to
do
container
image,
signature
verification
in
container
d
I
was,
I
was
helping
them
with
some
of
that
initial
work
at
at
my
day,
job
and
we
were
looking
at
doing
signature
verification
in
a
admission
web
hook,
and
that
has
both
good
and
bad
properties.
A
It's
easy
to
it's
easy
to
get
into
place,
but
you
know,
there's
the
there's
the
concern
about
the
fact
that
the
signature
verification
is
is
kind
of
difficult
and
in
a
large
cluster.
Then
there
could
be
a
significant
amount
of
load
due
to
doing
that.
Image.
Verification-
and
you
know,
there's
things
about
about
the
last
mile
aspect
of
that
like
if
you
do,
if
you
do
admit
it
with
image
verification.
A
You
know,
I
was
imagining
say,
mutating
the
image
reference
to
isharef
and
then
adding
something
else
to
the
pod
to
indicate
that
it
had
had
its
signature
verified,
but
that
isn't
that
isn't
great,
like,
I
think,
that's
an
okay
idea,
but
there
could.
It
could
be
done
better
and
so
then
folks
said
well,
you
know
what,
if,
instead,
what
if?
B
A
And
especially
with
especially
with
us,
starting
to
sign
the
official
release,
containers
and
with
things
like
kuba
m
running,
most
of
the
control
plane
out
of
the
official
release.
Containers
yeah
then
like
kube
dm
clusters
that
are
using
container
d
as
a
runtime
could,
in
the
future,
be
doing
signature,
verification
on
the
control,
plane,
images,
and
that
would
be
super
neat.