►
From YouTube: Kubernetes SIG Security Meeting 20201102
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
All
right
there,
it
is
we're
gonna
call
it
started.
Thank
you
for
coming
it's
a
weird
day.
I'm
glad
to
see
you
here
so
yeah
today.
Today
is
the
day
before
the
united
states
election,
and
that
means
that
a
lot
of
people
have
a
lot
of
things
on
their
minds,
besides
kubernetes
security,
so
to
wanted
to
lead
by
getting
that
out.
There.
B
We
didn't
cancel
today's
meeting
because
the
next
two
weeks
from
now
period
is
kubecon,
which
we
figure
people
will
also
be
super
busy.
For
that
said,
we
want
to
acknowledge
that
it
is
entirely
possible
and
understandable
that
nobody
wants
to
talk
about
or
do
anything
today,
and
if
that
is
the
case,
we
are
leaving
it
open
to
the
room
to
like
read
the
room
and
be
like.
How
are
you
all
doing?
I
know
elena
has
things
that
they
want
to
talk
about,
but
do
other
people
have
things
that
they
want
to
talk
about?
C
Yeah
not
hopefully
I
don't
know
hijacking
everybody
wanting
this
meeting
to
end,
but
I
will
promise
I'll
go
fast.
So
hi,
I'm
elena,
I'm
sig
instrumentation
one
of
the
co-chairs
and
we
are
the
hosting
sig
of
a
couple
of
caps
right
now
that
are
going
into
the
120
release
for
improvements
in
log
security.
C
So
I
just
wanted
to
because
I
saw
that
sig
security
has
been
sort
of
newly
formed
and
like
there
was
previously
the
working
group
security
audit,
but
that
kind
of
dissolved-
and
I
had
mentioned
this
to
ian-
and
they
recommended
that.
Oh,
why
don't
you
show
up
to
a
stick
security
meeting
and
mention
this?
So
this
was
the
first
one
that
I
was
able
to
make,
and
I
just
wanted
to
ensure
that
you
know
you've
got
these
links
in
your
minutes
and
the
justification
is
all
there
and
whatnot.
C
So
it
came
up
in
the
security
audit
that
I
believe
trail
of
bits
did,
that
various
components
of
kubernetes
are
potentially
vlogging
secrets
in
plain
text,
not
great,
and
I
included
an
example
that
I
ran
into
on
the
mailing
list,
where
there
was
talk
of
like
effectively
a
security
vulnerability,
because
certain
components
when
on
debug
level
were
of
leaking
secrets.
So
this
is
a
problem.
C
We
would
like
this
to
be
less
of
a
problem
in
the
future,
and
so
we
are
currently
looking
into
a
two-pronged
approach
for
improving
this
so
because
sig
instrumentation
is
the
sig
that
owns
logging
in
kubernetes.
C
We
are
hosting
this
effort
and
the
two-pronged
approach
is:
we
are
going
to
do
both
like
runtime
level
sanitization,
but
also
try
to
catch
things
in
advance
with
static
analysis,
and
so
that's
why
there
are
these
two
different
kepts
that
are
sort
of
two
parts
of
the
same
piece
and
the
dynamic
log.
Sanitization
is
currently,
I
think,
being
implemented
on
sort
of
an
opt-in
basis.
So
you
can
like
turn
it
on.
I
think
it's
behind
a
feature
flag
in
120
saying
like
yes,
I
want
my
law.
C
I
want
it
to
attempt
to
redact
my
logs
if
it
sees
any
secrets
and
as
well
there's
also
a
static
analysis
target,
so
I
believe
we're
adding
this
to
the
verified
job
and
it
will
flag
if
potentially
it's
going
to
be
an
optional
thing.
C
So
if
it
fails
initially,
you
know
it's
not
going
to
block
merges,
but
the
the
hope
is
that
when
we
see
people
trying
to
log
various
secrets
or
passwords
or
things
like
that,
that
will
be
caught
at
review
time
and
we
can
take
that
out
and
eventually
make
that
a
gating
job.
So
that's
sort
of
the
overview
of
those
things.
I
just
wanted
to
make
sure
that
people
were
aware
of
them
and
give
you
an
opportunity
to
ask
me
questions
and
that
kind
of
thing.
C
D
B
B
C
So
I
would
recommend,
based
on
my
experience,
like
collaborating
between
sigs
in
the
past,
so
there's
always
like
a
hosting
sig
and
then
there's
like
affected
or
related
cigs,
so
sig
security
did
not
exist.
When
this
cap
was
written,
I
would
suggest
that
we
add
sig
security
as
like
one
of
those
like
related
sigs
to
the
cap,
like
we
can
do
that,
even
though
it's
in
implementable
state
ensure
that
all
the
labels
are
correctly
applied.
C
So
you
have
the
visibility
on
these
things
and
then
that
way
we
can
ensure
that
folks,
from
this
sig
are
able
to
both
have
visibility
and
get
involved
cool.
I
suspect
you
know,
like
you
know,
did
like
if
security
existed
say
like
I
don't
know
six
months
ago,
and
somebody
was
proposing
this.
I
think
that
sig
instrumentation
would
probably
still
be
the
right
sig
to
host
this
potential,
at
least
for
the
like
the
dynamic
log
sanitization,
the
stuff.
C
Yeah
because
they're
in
our
code,
the
static
analysis
and
ci
that
honestly,
like
it's
it's
right
now,
it's
awesome,
seek
testing
and
like
there's
very
little
instrumentation
stuff
work
happening
there.
It's
mostly
just
us
being
like
this
looks.
Legit
sig
testing
is
this
okay,
so
perhaps
you
know
that
could
have
lived
with
sig
security
rather
than
sig
instrumentation,
since
it
doesn't
actually
require
any
instrumentation
changes.
It's
all
in
ci.
E
E
Well,
I
was
just
gonna
say
so:
I'm
the
1933
proposer
for
static
analysis,
but
it
came
up
on
the
current
implementation,
pr
like
for
configuration
of
like
what
gets
identified
as
like
creds
and
how
configuration
of
this
analysis
tool.
Do
you
think
that
should
be
owned
by
securities
testing
if
edits
down,
the
road
are
needed
to
be
made.
C
If
you
want
my
opinion,
I
would
say
probably
sig
security
is
the
right
place
for
that
to
live
with
suggesting
signing
off
on
it,
but
yeah.
So
since
security
did
not
exist,
we're
just
in
a
sort
of
weird
legacy,
inheritance
situation
here.
F
C
Yeah,
the
the
dynamic
sanitization
is
less
straightforward
and
the
reason
that
this
actually
was
split
into
a
two-pronged
approach
was
initially
when
this
was
raised
to
the
sig
instrumentation
chairs.
It
was
just
as
like
runtime
log
redaction
and
I
think
all
of
the
chairs
and
tech
leads
were
like.
Why
don't
we
try
to
catch
this
at
like
compile
time
like
what?
What
special
thing
are
the
various
components
going
to
see
at
run
time
that
they
wouldn't
have
available
at
like
compile
time,
and
so
that's
why
this
ended
up
moving
in
that
direction.
C
But
I
guess
there
were
some
like
relatively
compelling
arguments
that,
like
we
still
may
need
the
the
runtime
redaction.
So
it's
it's
being
implemented
as
an
alpha
thing.
So
you
know
opt-in,
no,
not
being
forced
on
anybody.
So
perhaps
you
know
if
the
static
analysis
is
as
successful
as
we
would
like
it
to
be,
then
we
might
not
need
the
dynamic
sanitization,
but
it's
just
hard
to
you
know,
keep
track
of
when
you've
got
thousands
of
contributors
who
are
all
trying
to
log
secrets.
How
do
you
catch
them?.
C
G
Hi,
I'm
here
this
is
avito,
hey
hope
everyone
is
doing
good.
I
talked
a
bit
with
sick
dogs
and
they
gave
good
pointers.
I
they
gave
me
a
link
to
the
previous
think,
doc
security
agenda
on
meeting
notes
and
stuff.
I
hadn't.
I
did
not
have
time
last
week
to
review
I'm
sorry.
My
parents
are
going
to
india
and
I
had
to
do
so.
Many
stuff
get
them
current
virus
test
in
like
48
hours
it
was
just
a
mess.
So
apologies
that
I
didn't
get
anything
done.
You.
G
And
they
also
gave
a
very
good
pointer
that
when
all
the
subgroups
are
creating
a
meeting,
invite
use
these
securities
shared
calendar
so
that
the
burden
is
just
not
on
one
person.
If
they
move
on
it's
it's
easy
to
manage,
so
that's
one
pointer
that
they
gave
and.
A
If
you
need
any
help
with
that
ian-
and
I
can
both
can
both
help
with
the
you
know,
mechanics
of
making
that
happen.
G
G
And
I
think
the
first
focus
of
this
sub
project
should
be
cks
documentation
and
whatever
the
security
related
stuff
going
into
1.20
release,
like
elena
mentioned,
so
I'm
going
to
keep
an
eye
on
the
two
enhancements
and
make
sure
those
documentation
are
there
stuff
like
that.
So
this
is
what
I
think
takes
priority,
but
just
let
me
know
if
there
is
anything
else
that
needs
to
take
priority
over
these
things,
and
I
also
wanted
to
ask
one
thing
that
do
we
need
to
update
the
charter
for
the
project.
Okay,.
A
All
right
yeah,
it's
not
it's,
not
a
hair
on
fire
emergency
to
get
that
done,
but
that
is
one
of
the
things
on
the
on
the
horizon
is
to
get
the
official
documentation
to
catch
up
with
what
we
all
are
doing
here
together.
G
Awesome-
and
I
already
have
some
volunteers
who's
willing
to
work
on
the
cake
certification
they
are
willing
to
when
they
take
the
examination
or
preparing
for
the
examination
they're
going
to
go
through
the
website
and
help
with
improving
it.
So
I
got
a
couple
of
them
like
ray.
Lahanno
is
a
part
of
the
six
security
release
team
as
well,
so
he
has
volunteered.
So
I
think
that
is
a
good
progress.
That's.
F
An
underachiever
I've
done
very
little
since
the
last
meeting,
I'm
still
claiming
new
new
to
the
sig
world.
As
my
excuse,
we
did
get
the
channel
created
through
the
the
wonderful
process
there
and
honestly
between
onboarding
at
the
new
job
and
conference
talk.
I
haven't
had
time
to
really
dedicate
much
more
to
it
feeling
we.
F
A
Okay,
one
thing
that
that
I'll
bring
up
from
over
in
psc
land
is
our
person
from
hackerone,
which
is
the
the
kubernetes
bug
bounty
vendor
that
that
kubernetes
is
working
with
to
to
run
the
bug
bounty.
A
They
were
asking
whether
we
would
be
interested
in
hearing
something
from
them,
and
I
said
well
I'll:
ask
the
people
what
things
they
might
be
wondering
about
the
bug,
bounty
or
things
that
they
things
that
they
would
want
to
know
and
pass
that
along
up.
So
I
guess
tap
on
slack
and
if
you
have
thoughts
about
what
you
want
to
hear
from
them
and
then
then
I
can
kind
of
you.
D
B
Related
slightly
back
to
subgroup
report
backs,
I
swear
I
saw
micah
in
here
who
is
not
currently
in
here.
Has
anybody
heard
anything
from
the
security
audit
working
group.
H
So
there
were
a
few
problems
with
them.
I
don't
know
if
you
know
there
was
some
archiving
of
the
of
the
channel
and
it
was
recreated
recently
by
aaron
small
and
then
I
was
organizing
some
of
the
meetings
to
organize
the
all
the
project
meetings
and
then
progress
a
little
bit
more
on
that.
So
now
the
there's
a
doodle
that
has
been
shared
with
with
the
people
that
show
some
interest
in
that,
and
I
think
we
are
going
to
progress
on
that.
H
H
B
E
Yeah
aaron
also
here
I'll
link
it
on
the
notes,
but
in
the
sig
security
slack
channel
there
is
a
doodle
poll
for
a
preferred
meeting
time
for
the
security
audit
sub
group.
So
please
indicate
your
availability
and.
D
D
C
So
that's
kind
of
an
architectural
question,
so
my
understand,
like
of
the
audit
log
in
the
api
server,
is
a
totally
separate
thing
from
like
the
the
various
other
logs
that
come
from
k-log
and
the
reason
that
I
know
this
is
because
I
have
had
large
amounts
of
frustration,
because
the
audit
log
has
always
supported
structured
logging
and
the
rest
of
the
components
and
knowledge
do
not.
Although
that
is
currently
in
progress,
this
release
as
well
we're
finally
going
to
be
introducing
structured
logging
for
all
the
things.
C
Like
two
years
in
the
making
on
that
one
so
yeah,
I
have
not
taken
a
look
at
this
cap
in
quite
a
while.
So,
and
I
was
not
one
of
the
authors-
and
I
was,
I
think,
only
sort
of
a
very
like
brief
reviewer,
like
I
don't
think
just
one
of
the
reviewers
on
this
one.
So
I
would
not
be
yeah,
I
think,
oh
technically,
I'm
listed
as
a
reviewer,
but
not
an
approver.
So
I've
looked
at
this
one.
It's
been
a
while.
C
So
I,
if
you
have
any
like
specific
questions
about
the
cap,
especially
this
one
where
I
think
merrick
is
doing
a
lot
of
the
implementation
work.
I
strongly
suggest
that
you
drop
by
in
a
sing
instrumentation
meeting,
throw
it
on
the
agenda.
Okay,
that's
it
yeah!
Our
meetings
are
bi-weekly
on
thursdays,
so
the
next
one
will
be
on
the
12th.
A
B
To
be
super
super
clear,
we
really
want
to
keep
the
energy
of
this
thing
up
and-
and
we
are
not
trying
to
like
throw
everybody
out
of
this
meeting.
We
are
excited
to
all
be
here
and
I'll,
be
working
together
and
to
be
making
kubernetes
more
secure
and
more
awesome.
We
are
just
acknowledging
that
it's
a
rough
week,
so
I
hope
that
this
week
goes
as
well
as
it
can
for
everybody
and
yeah
are
we.
We
are
not
meeting
during
kubecon,
we
decided
right,
which
is,
I
guess
technically.
B
B
Sub
groups
meet
at
different
times
too,
so,
if
you're
meeting
in
between
feel
free
to
holler
at
us,
on
the
slack
or
wherever
else
in
the
meantime,
too
yeah
all
right.
Thanks.