►
From YouTube: SIG Chairs and TLs Monthly Meeting for 20220111
Description
SIG Chairs and TLs Monthly Meeting for 20220111
C
B
We're
here
today,
because
we
got
invited
to
talk
about
the
security
response
committee
and
sig
security
and
what
those
respective
groups
do
when
it
is
appropriate
to
interface
with
either
or
both
of
them
and,
generally
speaking,
what
the
similarities
and
differences
are
to
help
clarify
kind
of
the
different
security
apparatuses
within
the
project
to
tears.
Ntls,
who
are
interested
in
figuring
out
how
to
work
with
us
to
improve
the
security
of
the
project.
C
So
the
security
response
committee
has
a
fairly
small
and
clearly
defined
scope.
We
handle
reported
vulnerabilities
in
kubernetes
and
security
incidents
that
affect
the
project.
We
issue
the
like
formal
public
notifications
of
kubernetes
vulnerabilities,
like
we
issue
the
cves,
but
nearly
everything
else
that
we
do
is
private
to
help
to
help
to
protect
the
project
and
to
protect
our
users.
B
Security,
on
the
other
hand,
has
a
wider
scope
and
we
do
things
in
public
security
works
in
community
to
improve
the
security
of
the
kubernetes
project
as
a
whole.
We
engage
internally
within
the
project
by
helping
facilitate
collaboration
across
cigs
on
security,
related
topics
and
maintaining
project-wide
security,
tooling,
to
make
all
of
our
security
lives
easier.
B
We
also
engage
externally
by
working
on
security,
relevant
documentation
for
users,
engaging
with
the
larger
security
community
and
doing
outward-facing
public
comms
sig
security
does
things
a
little
bit
differently
than
a
lot
of
other
cigs,
and
I
want
to
speak
to
that
for
a
second
sig.
Security
has
cultivated
a
culture
of
doing
things
in
community
as
a
community,
and
we've
done
that
on
purpose,
we
make
decisions
by
community
consensus
and
we
work
really
closely
together
with
our
subgroup
leads
and
with
community
members.
We
don't
have
a
listed
sig
membership.
B
The
members
of
the
sig
are
who
comes
to
meetings
and
who
brings
their
ideas
and
what
they
have
to
say
so,
but
as
an
organizational
structure
such
that
we
have
one,
although
we
tend
to
do
things
a
little
bit
more
informally,
we
do
have
subgroups
and
subgroup
leads.
So
our
our
three
sub
projects
are
sig
security,
tooling,
sig
security,
docs
and
and
the
third
party
audit.
B
B
B
Another
thing
that
sig
security
does
is
we
have
public
meetings
every
two
weeks
that
are
an
open
forum
for
discussion
on
security
topics
and
work
gets
done
in
these
meetings
as
such,
among
other
things,
one
thing
that
sig
security
does.
Is
we
help
coordinate
and
draft
caps
for
security
improvements
that
often
involve
working
with
and
collaborating
with
other
sigs,
because
you
know
we
are
all
together
as
one
larger
project,
and
so
people
are
going
to
have
to
work
together
on
the
different
bits
of
the
things
relevant
to
those
caps.
B
We
also
triage
security
related
issues
as
a
group
together.
So
if,
if
sig
security
is
tagged
in
things,
it
isn't
just
me
and
tabby
holding
up
in
somebody's
basement,
it
is
working
on
that
on
a
community-wide
basis
and
in
general,
people
bring
what
they
have
to
say
if
they
have
specific
security
concerns,
if
they
have
things
that
they
have
thoughts
on,
if
they're
really
burning
to
have
something
that
they
really
want
to
improve,
we
can
help
them
figure
out.
B
B
This
is
an
inflow
for
folks
from
the
external
community
to
come
and
interact
with
the
kubernetes
project
and
security
relevant
interests,
and
it
is
also
a
way
for
people
within
the
project
to
come
and
talk
about
the
things
that
are
affecting
their
work,
that
are
security
relevant
and
get
help
and
communicate
about
those.
The
way
that
sig
security
does
things
on
a
community
basis
and
the
environment
that
we've
created
around
that
helps,
encourage
new
contributors,
grow
new
leaders
and
raise
awareness
of
kubernetes
security
among
the
larger
community.
C
The
security
response
committee,
unsurprisingly
for
a
small
organization
that
works
in
private,
does
quite
a
bit
less
to
bring
in
new
contributors
and
and
that
sort
of
thing,
because
we
have
very
specific
jobs
that
are
almost
always
handling.
You
know:
radioactively
sensitive
information
in
the
appropriate
ways
to
the
appropriate
people
at
the
appropriate
times.
C
C
So
if
there
is
a
security
incident
affecting
kubernetes
like
I
don't
know,
for
example,
if
if
some
of
the
ci
infrastructure
were
were
harmed,
then
we
would
be
sort
of
the
first
point
of
contact
there
for
for
coordinating
incident
response
for
those
sorts
of
things,
and
we
take
in
vulnerability
notifications
from
a
couple
of
different
areas.
We
run
the
kubernetes
bug
bounty
program
through
hacker
one,
where
folks,
outside
of
kubernetes
community,
can
bring
issues
that
they
have
discovered
through.
C
C
We
handle
the
security
at
kubernetes,
dot,
io
email,
which
is
another
way
that
you
can
notify
us
of
an
issue
or
of
a
potential
issue,
and
then
we
track
those
internally
coordinate
the
appropriate
follow-ups.
So
you
know
assemble
teams
to
fix
the
teams
to
fix
the
issues
or
whatever
and
and
see
those
through
until
they're
released
so
yeah.
A
lot
of
a
lot
of
this
data
is
necessarily
quite
private.
C
So
sometimes
those
fixes
are
done
purely
in
private,
in
close
coordination
with
the
appropriate
release
teams.
Sometimes
those
fixes
are
of
of
a
certain
flavor
so
that
rather
they
can
have
the
fix
put
in
place
in
in
public
and
then
announced
at
an
appropriate
time
as
being
a
fix
for
a
security
issue,
and
sometimes
certain
kinds
of
low
severity
issues
are
simply
moved
into
public
github
issues
and
fixed.
Like
any
other
bug,
and
and
generally
we
coordinate
all
of
those.
C
First,
we
will
be
more
than
happy
to
handle
it
through
our
private
procedures,
if
that's
necessary,
we're
also
more
than
happy
to
say
you
know
that
sounds
like
it
would
be
a
good
topic
to
bring
up
at
the
sig
security
meeting,
or
that
sounds
like
like
it
would
be
a
fine
thing
to
file
a
normal
public,
github
issue
on
or
whatever
we're
more
than
happy
to
help
you
figure
out
sort
of
what
is
the
severity
and
privateness
of
something
that
you
have
on
your
mind.
You
want
to
talk
about
a
couple
of
examples.
Ian.
B
Zoom
is
hard,
so
here
are
some
examples
of
you
know
who
you
might
want
to
call
upon
in
specific
situations,
because
part
of
the
reason
why
we're
doing
this
thing
here
is
that
we
realize
that
it
might
not
always
be
100
clear.
So
we
came
up
with
a
few.
One
of
them
is
if
a
kubernetes
core
feature
is
letting
you
do
something
that
it
obviously
shouldn't
so
like
you.
If
you
find
a
flaming
security
bug
holler
at
the
src
file,
a
bug
on
hackerone.com
kubernetes,
if
you're
comfortable
doing
that.
C
C
B
If
you
want
to
know
who
else
is
working
on
or
thinking
about
a
given
kubernetes
security
problem
security
is
a
great
place
to
go
on
that
or,
if,
generally
speaking,
you
have
kind
of
ideas
about
collaboration
around
security.
Relevant
topics
with
your
sig
or
something
that
you
think
should
be
happening
across
security
is
a
great
place
to
bring
that
to.
B
We
have
a
very
active
slack
channel
where
discussions
happen
or
come
say
hello
to
us
at
a
meeting,
because
discussions
happen
there
too,
and
are
often
reflected
on
slack
as
well.
Our
meetings
purposely
have
very
loose
agendas
and
because
that's
how
we
roll-
and
if
you
see
not
particularly
an
agenda
on
the
meeting,
that
does
not
mean
that
nothing
is
happening.
It
just
means
that
people
are
going
to
bring
what
they're
going
to
bring.
C
And
to
sort
of
jump
off
from
and
amplify
that
the
sig
security
meeting
agenda
document
is
something
that
you
can
edit,
and
so,
if
there
is
something
that
is
important
to
you,
that
you
really
wish
to
bring
to
the
attention
of
the
folks
who
come
to
the
sig
security
meeting,
you
know
feel
free
to
put
that
on
the
agenda
document.
It
is,
it
is
our
space
for
us
to
share
and
work
together,
and
you
are
part
of
us.
C
So,
to
kind
of
wrap
this
up
sort
of
the
key
takeaways
here,
one
that
is
really
helpful
for
both
groups
is
make
sure
to
keep
your
owner's
files
and
security
contacts
files
up
to
date,
especially
for
the
src,
where
there
are
very
fine
grained
owners
over
different
specific
parts
of
the
code
base.
When
we
are
triaging
vulnerability
reports,
we
usually
have
enough
familiarity
with
the
code
to
know
vaguely
in
the
code
where
the
kinds
of
issues
would
be,
but
we're
we're
clearly
not
experts
on
everything.
C
We
can't
tell
how
to
fix
everything,
and
so
the
the
security
contacts
and
the
code
owners
files
are
very,
very
helpful
for
the
src
for
that
for
sig
security,
usually
it's
more
a
matter
of
knowing
which
other
sig
to
talk
to
so
they
are
not
quite
as
critical
for
sig
security,
but
they
are
for
the
same
reasons
as
the
src
another
valuable
piece
of
information
that
we
can
chase
down
to
find
out.
Who
knows
about
a
thing
who
can
talk?
Who
can
talk
to
somebody
about
a
thing?
C
Other
important
takeaway
when
the
security
response
committee
comes
calling?
Please
help
us
try
to
staff
the
fixed
teams
for
bugs
when,
when
we're,
when
we
are
coming
to
to
report
something
that's
because
we
have
learned
about
it
and
and
it's
scary
and
it
has
the
ability
to
affect
or
potentially
harm
our
users
and
our
users
are.
Are
why
we're
all
here?
And
so
you
know,
we
will,
when
necessary,
come
and
ask
for
ask
for
help.
Putting
the
group
together.
A
B
But
I
think
what
we
are
looking
for
is.
We
are
looking
for
folks
to
collaborate
with.
So
when
sig
security
comes
hollering
at
you
or
really
to
you,
we're
trying
to
find
people
to
collaborate
with
us
or
with
another
sig
that
is
looking
for
help
getting
on
blocks
on
working
across
sigs
with
other
folks
on
the
some
security
relevant
issues.
So
you
know
we
are
here
to
try
to
help
facilitate
working
together
and
people
working
across
different
parts
of
the
project.