►
From YouTube: Kubernetes SIG Security Meeting 20210114
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
Thank
you
so
much
for
coming
to
the
first
kubernetes
sig
security
meeting
at
the
new
time
and
day
and
during
a
really
wild
and
distracting
time.
So
I'm
super
grateful
that
y'all
have
have
taken
the
time
and
effort
to
be
here
so
that
we
can
talk
about
kubernetes
security.
A
We've
got
a
few
things
here
on
the
agenda
and,
of
course,
as
always,
this
is
this
is
our
time
and
space.
So
we
can,
we
can
add
anything
else
that
we
want
or
need.
It
looks
like
we
have
a
subgroup
report
from
zavita
about
docs.
A
C
So
the
last
time
we
met,
we
had
some
good
discussions
on
what
to
get
started
and
we
had
two
outcomes
ellen
volunteered
that
they
would
be
willing
to
write
a
our
bag
guide,
which
is
a
which,
which
is
I
fee.
I
find
that
useful
because
I
have
to
go
all
over
the
place
to
find
the
right.
C
Our
bag
tutorials
whenever
I
am
working
on
something
related
to
it
and
michael,
is
working
on
security,
checklist
roadmap
and
I
have
created
two
document
separately
to
brainstorm
and
come
up
with
ideas
and
it's
linked
in
the
security
documentation.
C
Meeting
notes
probably
will
today
get
to
discuss
about
the
meeting
week,
so
we
meet
in
the
same
day
as
social
security
meeting
like
today.
We
have
a
meeting,
so
it
might
be
overwhelming
for
folks
to
attend
to
six
security
meetings
on
the
same
day.
So
probably
I'm
gonna
ask
if
they
would
be
willing
to
alternate
like
if
I,
the
six
security
dogs
could
go
the
next
week.
So
it's
on
the
alternating
weeks,
it's
not
on
the
same
week.
C
A
D
Yeah,
so
I
added
in
the
request
for
rfp
is
pretty
much
done.
Chris
small
is
going
to
check
with
the
linux
foundation
or
the
cncf
about
about
funding.
The
rfp
will
be
open
from
on
january
25th
to
the
to
february
26th.
I
put
the
additional
dates
on
the
notes
as
well.
We
do
have
a
question,
a
google
form
for
for
questions
as
well,
and
these
questions
will
be
answered
on
the
rfp
then,
on
march
9th
the
group
will
announce
the
vendor.
A
D
Thank
you,
and
I
do
have
one
question
for
the
group
so
from
my
company's
perspective,
we've
seen
a
growing
number
of
windows
users
as
well.
Currently,
this
is
not
in
scope
for
this
security
audit.
This
is
third
party
security
audits,
but
it
might
be
something
we
have
to
think
about
down
the
road
in
the
future,
because
that
will
increase
the
scope
and
that
will
probably
increase
the
cost
as
well.
So.
A
Yeah
yeah
and
like
similarly
the
pod
security
standards
document
has
a
little
note
at
the
end.
That's
like
all
of
this
discussion
is
based
on
the
assumptions
of
the
technical
particulars
of
linux
containers.
So
if
we're
talking
about
some
kind
of
isolating
runtime
or
if
we're
talking
about
windows,
that's
all
a
completely
separate
concern
for
which
there
is
no
guidance.
A
E
A
Yeah
yeah,
I
wonder
if,
like
I
wonder,
if
sig
node
knows
any
information
about
that,
if
that's
a,
if
that's
a
thing
that
that
people
are
interested
in,
I
would
be
happy
to
ask
around
and
find
out
who
may
know
about
that.
D
Yeah,
that
would
be
great
because
I
I
tried
looking
into
if
there
was
like
an
end
user
group
that
might
have
some
info
or
we
could
do
a
a
very
informal
poll
with
the
some
kind
of
one,
the
end
user
groups,
but
I'm
not
too
familiar
with
them.
I
couldn't.
B
D
B
A
A
A
All
right
with
that
being
the
the
reports
from
subgroups,
it
looks
like
the
first
thing
that
we
have
here
is
michael
would
like
to
talk
to
us
about
a
cap.
F
That's
right:
thanks,
tabitha
hi
everyone,
I'm
michael,
I'm
working
on
cap
1933
with
my
colleague,
patrick
romberg,
who's,
been
spearheading
the
effort.
I
believe
this
cap
has
been
discussed.
Maybe
a
little
bit
in
this
meeting
in
the
past.
Is
that
a
case.
A
I
think
in
a
very
in
a
very
broad
way,
so
I
think
we
could
all
benefit
from
a
from
a
quick
review
of
what's
going
on
with
it,
because
I
know
that
it's
pretty
complicated.
F
Right,
yeah
I'll.
I
can
certainly
give
a
quick
overview
like
the
details
are
complicated,
but
the
overview
won't
be
complicated.
So
the
title
of
the
cap
is
defend
against
logging
secrets
via
static
analysis,
and
the
idea
is,
I'm
sure,
you've
heard
back.
In
october
of
last
year,
there
were
four
cves
involving
credentials
leaks
in
kubernetes
and
in
2019
in
the
security
audit,
three
of
the
items
involved
secrets
being
logged
in
clear
text.
F
So
the
goal
of
the
cap
is
to
prevent
the
introduction
of
code
that
could
log
credentials
or
other
sensitive
information
and
the
way
we
are
proposing
to
do
that
is
with
a
static
analyzer
that
we've
been
developing
and
very
broadly.
What
it
does
is
the
users.
So
in
this
case
the
the
configuration
was
provided
by
another
kep.
That
does
dynamic
analysis
I'll
touch
briefly
upon
that
later.
But
basically
we
just
need
annotations
on
structs.
F
That
say
this
is
a
secret.
This
is
credentials
so,
for
example,
the
core
slash
v1
secret.
We
would
tag
the
data
field
on
that
as
being
a
secret
and
our
analyzer
will
detect
uses
of
the
secret
in
the
code
base
and
we'll
sort
of
trace
where
the
values
could
get
to
make
sure
that
the
secret
can't
reach
a
call
to
klogg.info,
for
example.
F
So
the
state
that
a
cap
is
in
right
now
we
have
it
running
in
prow,
but
it's
non-blocking,
so
developers
could
see,
for
example
like
if
a
developer.
This
is
probably
not
going
to
be
very
common.
But
if
a
developer
introduces
a
new
piece
of
unsafe
code
that
could
leak
credentials,
the
test
will
fail,
but
it
will
not
block
the
pr
and
we
are
iterating
quite
quickly
on
this
tool
and
we
need
to
make
fairly
irregular
updates
to
the
configuration
or
to
the
version
of
the
tool
because
we're
making
improvements.
A
Okay,
what
kind
of
what
kind
of
reviews
would
you
be
hoping
to
get
there.
F
Right
so
I
put
a
link
to
a
pr
in
the
discussion
item
and
that
pr
is
asking
specifically
to
transfer
ownership
of
a
directory
where
we
have
our
configuration
data.
So,
like
specifically,
it's
I
think
right
now.
It's
one
file
where
we
have
a
listing
of
what
are
the
types
that
contain
credentials
like
the
identification
of
the
type
these
types
and
also,
what
are
what
we
call
syncs,
which
basically
are
logging
functions.
F
So
we
have
klog.info
in
there
and
we
also
have
some
explosions
because,
as
we
improve
the
analyzer,
we
we
get
new
true
positives,
but
we
can
also
get
false
positives
where
the
analyzer.
It's
it's
a
static
analysis.
So
it
can't
know,
for
example,
that
a
piece
of
code
won't
actually
run
so
it
might
produce
a
report
that
is
not
actually
concerning
and
we
need
a
way
to
suppress
those
reports.
F
So
that's
also
included
in
the
configuration.
So
really
the
kind
of
reviews
that
we're
going
to
need
are
just
making
sure
that,
like
when
we
make
the
these
changes.
Having
someone
take
a
second
look
and
confirm
that
that
the
changes
are
all
right,
I
guess.
A
Like
in
the
like,
in
the
sense
that
that
the
the
the
changes
to
this
file
seem
sane
like
like
sniff,.
D
A
Kind
of
review
on
it
because
it
like.
A
I
really
I
really
like
the
idea
of
y'all
having
another
separate
group
to
like
check
your
work
for
you.
But
the
immediate
thing
that
I
would
be
worried
about
would
be
that.
A
Understanding
for
sure
whether
or
not
one
of
these
things
is
correct
has
more
to
do
with
a
deep
familiarity
with
the
parts
of
code
that
are
using
like
a
particular
type
that
you
would
that
you
would
want
to
add,
and-
and
so
I
feel
like
the
folks
in
this
room-
and
I
would
absolutely
love
to
hear
from
the
rest
of
the
folks
in
this
room
since
I
am
currently
speculating
about
you.
A
But
I
I
feel,
like
the
I
feel
like
the
folks
in
this
room,
would
have
a
good
sense
of
of
of
like
generally,
whether
something
makes
sense,
but
not
necessarily
deep
familiarity
with
any
particular
section
of
code
that
might
be
using
that,
and
so
like
on
one
hand,
it
seems
to
me
off
the
cuff
that
that
having
us
as
a
as
like
a
like,
a
second
opinion
for
things
that
you
want
to
merge
into
this
file
is
like
structurally
obvious
from
the
from
the
organizational
perspective.
A
But
I
also
worry
about
how
much
extra
value
we
could
specifically
provide
to
you
in
in
the
case
of
individual
prs
so
like
like
it
may
be.
It
may
be
better
for
individual
prs
to
at
least
also
have
somebody
from
sigs
that
own
parts
of
the
code
that
a
particular
config
change
to
this
would
impact
also
look
at
it,
since
they
would
have
more
intimate
knowledge
of
that
particular
code.
G
If
I
can
interject
real
quick
just
for
clarification,
the
actual
the
dimension
for
field
tags
that
are
gonna
identify
things
that
shouldn't
be
logged.
That
is
part
of
another
cap
which
is
referenced
in
1933.,
but
there
are
pr's
from
merrick
that
are
adding
those
to
all
the
respective
types
that
we
have
right
now.
G
So
I
don't
disagree
that
maybe
having
individual
prs
like
tag
respective
component
owners
if
we
want
to
like
confirm
an
exclusion,
but
as
for
as
for
like
actually
identifying
sources
identifying
things
we
shouldn't
log
that
has
already
been
roping
in
people
that
have
domain
expertise.
A
Okay,
so
then,
so
then,
under
under
this
proposal
that
we
take
ownership
of
this
file,
really
we're
there
just
to
just
to
ensure
that
there's
always
at
least
one
other
set
of
eyes
outside
of
outside
of
instrumentation,
to
reduce
the
chance.
That
there's
something
that's
obvious
to
someone,
but
not
obvious
to
someone
else,
and
it
slips
through.
F
F
But
I
think
most
changes
are
going
to
be
us
rolling
over
the
version
of
the
analyzer
to
get
new
new
improvements
and
also
adding
exclusions.
Where,
like
I
mentioned,
sometimes
there
might
be
false
positives.
So
in
those
cases
we
might
want
to
include
the
owners
to
make
sure
that
there
really
is
no
issue
with
the
code
being
excluded.
A
Okay,
I
think
I
think
that
makes
sense.
I
mean,
as
far
as
my
opinion,
matters,
which
I
mean
here,
I
am
like
to
whatever
extent
my
opinion
matters.
The
the
only
other
concern
that
I
would
have
about
this
immediately
is
that
we
don't
have
an
existing
sub
project
that,
like
naturally,
would
be
concerned
about
this
kind
of
thing,
but
I
think
it's
I
think.
Overall,
it
seems
like
a
good
idea,
and
so
I
think
it
would
be
sensible
for
us
to.
A
You
know,
have
a
little
bit
more
of
a
of
a
conversation
offline
like
maybe
do
a
lazy
consensus
on
the
on
the
list
serve
and
and
slack
and
go
from
there
like.
I
think
I
I
think
I
think
the
idea
has
merit,
and
I
don't
want
to
say
yes
or
no
on
behalf
of
a
pretty
diverse
group,
that
is,
that
is
lightly
organized
like
right
here
right
now,
but
but
I
think
it
I
think
it
seems
like
a
thing
we
should.
We
should
talk
about
and
get
you
an
answer
for.
F
Great
yeah
that
sounds
great
to
me,
and
I
think
that
makes
a
lot
of
sense.
I
think
maybe
the
tooling
subgroup
could
be
a
fit
for
this,
and
also
I
just
want
to
briefly
mention
that
we
would
absolutely
be
interested
in
having
a
conversation
about
the
tool.
If
people
are
interested
in
learning
about
how
it
works,
we
could
definitely
like.
We
would
definitely
be
interested
in
sharing
knowledge
in
that
area
and
also
the
project
itself,
like
the
actual
tool,
is
called
goflow
levy.
F
It
is
open
source
and
we
are
welcome
if
you
want
to
contribute
to
the
tool.
If
you
want
to
look
at
the
code,
you
are
very
welcome
to
do
so.
A
That's
that's
awesome
did,
did
you
all
write
the
tool
or
did
you
adapt
it
from
some
other
place.
F
Yeah
we
wrote
it,
but
we're
heavily
relying
on
libraries
that
are
already
existing
in
the
extended
go
standard
library,
so
there's
a
library
for
writing
static
analyzers.
That
was
pretty
useful.
A
E
A
Awesome
well
we'll
we'll
take
it
to
the
we'll,
take
it
to
the
listserv.
Then
let
me
make
sure
that
I
don't
forget
to
start
that
conversation.
A
All
right,
the
next
thing
that
the
next
thing
that
we
have
on
the
list
was
a
a
question
that
patrick
brought
up
about
the
owners
lists
in
k
community,
and
I
think
it's
a
really
good
question.
The
the
way
that
it
got.
The
way
it
is
right
now
is
that
the
the
six.yaml
there,
where
you
list
owners
is
lis,
is
a
list
of
existing
owners
files
and
so
for
a
domain
specific
sig,
where
they
primarily
exist
to
own
code
and
they
own
code
through
the
activities
of
subgroups.
A
Then
the
code
has
to
live
somewhere,
which
means
the
code
lives
in
a
directory
and
there
needs
to
be
an
owner's
file
in
the
directory
with
the
code
and
so
therefore
there's
a
very
natural
fit
to
then
put
those
on
our
owner's
files
there.
As
a
horizontal
sig
that
doesn't
own
code,
though
we
haven't
had
that
natural,
obvious
creation
of
directory
structure,
and
so
therefore,
since
the
the
working
groups
that
are
currently
doing
things,
don't
have
like
a
working
directory
somewhere
in
one
of
these
repos.
A
Yet
there
is
no
obvious
place
to
put
that
owner's
file
and
therefore
there
hasn't
been
an
owner's
file
link,
and
so
I
would
say,
like
savita
as
a
as
as
a
subgroup
as
a
subgroup
lead
here,
do
y'all
have
a
need
for
a
directory
like
perhaps
under
under
k,
community
security,
docs
or
something
like
that
to
keep
work
in
progress
or
or
anything
like
that
or
alternately.
C
So
I
don't,
I
don't
think
there
should
be
an
owner's
file
just
for
the
sake
of
a
folder
just
for
the
sake
of
having
the
owners
file.
But
I
do
like
the
idea
of
having
a
place
where
we
can
track
like
a
in
the
future.
C
If
you
want
to
track
quality
goals
or
like
how
some
of
these
things
do,
that
they
have
quarterly
meeting
and
they
prioritize
stuff,
and
if
we
need
a
place
for
each
sub
projects,
and
if
we
want
to
track
keep
track
of
things
that
we
are
working
on.
I
think
that
will
be
useful.
A
Okay,
that
that
totally
makes
sense,
do
you
want
to
put
in
a
pr
to
create
that
directory
in
that
owner's
file
and
then
and
then
one
of
us
can
approve
it,
or
would
you
like
us
to
to
do
that,
for
you.
C
I
can
do
that.
Do
you
want
me
to
talk
to
the
other
owners
and
also
put
all
other
directories
or
just
take
care
of
dogs
first,
and
everything
can
follow
up
after
that.
A
I
mean
whichever
you
like.
I
was
actually
just
going
to
just
going
to
suggest
that
that
the
chair
should
reach
out
to
the
other
owners,
but
if,
if
you
are
already
thinking
about
doing
it
for
your
group
and
want
to
ping
the
other
owners,
then
then
that's
wonderful
and
all
I
can
say
is
thank
you.
C
Thank
you
and
does
this
owners
file
will
help
with?
So
this
is
an
unrelated
related
question,
but
I
just
want
to
bring
it
up
like
if
we
want
to.
I
am
glad
that
I
can
go
to
you
or
ian
for
cancelling
the
meeting
or
everything,
but
then
I
felt
like
I'm
annoying
you
both
by
oh.
Can
you
just
cancel
this
meeting
from
the
calendar
like
this?
C
This
is
the
place
to
go
place
to
have
like
edit
permissions
to
the
shared
calendar,
or
is
that
going
to
be
used
for
some
other
things
where
we
can
consolidate
permissions
to
for
access
and
stuff
like
that,
for.
A
I
was
actually
just
going
to
lead
with
that
as
well.
I
think
the
shared
calendar
thing
is
is
a
little
awkward
for
all
of
us
because
of
the
way
that,
like
google
calendar
permissions
work
so
like
we're
totally
happy
to
continue
to
do
that
as
a
service
for
you.
But
if
it
is
an
annoyance
to
you
or
or
if
it
is
a
bother,
I'm
happy
to
talk
to
I'm
happy
to
talk
to
contrib
x
and
find
out
like
what
other
cigs
are
doing
about
this
problem
and
and
follow
along.
A
A
A
Next
thing:
that's
here
on
the
list
is
replacement
of
pod
security
policy,
so
things
are
actually
moving
along
here
now,
after
some
struggle
due
to
just
the
way
the
world
has
been
lately,
the
agreement
was
made
at
a
recent
sig
off
meeting
that
pod
security
policy
is
going
to
be
marked
deprecated
in
1.21,
and
the
plan
has
been
for
it
to
be
removed
in
1.25,
and
so
that
continues
to
be
the
plan
for
the
future
of
pod
security
policy,
as
it
is,
there's
been,
there's
been
back
channel
talk
to
put
together
a
couple
of
replacement
proposals
for
all,
essentially
alternate
and
alternate
implementations
of
the
same
idea
to
address
some
of
the
problems
that
has
caused
pod
security
policy
to
be
perma-beta,
and
so
in
the
interest
of
it
being
easier
to
criticize
and
improve
something
than
to
start
something
from
scratch.
A
We
figured
that
we
should
put
something
together.
That
was,
you
know,
well
enough
constructed
as
to
as
to
allow
iteration.
A
A
Folks
in
sigoth-
and
you
know
other
folks
in
the
extended
kubernetes
security
community
likely
likely
in
the
next
couple
of
days.
We
want
to
make
sure
to
get
our
different
proposals
released
together,
so
that
that
way,
it's
quite
clear
that
all
of
us
are
trying
to
serve
the
same
goal,
which
is
making
sure
that
kubernetes
as
a
project
has
a
good
answer
for
these
security
needs
for
users,
as
psp
gets
deprecated
like
to
make
it
to
make
it
obvious
that
we're
we're
not
competing
with
each
other.
D
So
I
want
to
bring
up
a
few
points
with
121
release,
since
this
is
scheduled
to
be
deprecated.
I
just
want
to
make
a
note
that
there
is
a
new
that
sig
leads.
I
believe
we're
made
aware
of
a
new
opt-in
procedure
for
any
caps
to
be
included
in
1.21,
and
I
just
want
to
put
it
out
there
that
the
enhancements
freeze
is,
I
believe,
february
9th.
A
D
G
A
Which
which
we
recognize
as
an
aggressive
goal
but
having
aggressive
goals,
is
a
good
start
to
doing
cool
things.
So
so
yeah
it's
coming
right
up
and
thank
you
so
much
for
for
pointing
it
out
to
us
yeah
more
on
that
more
on
that
pretty
soon.
A
Think
the
the
last
thing
that
we
have
here
was
just
something
that
I
had
been
involved
in
personally,
but
it
feels
like
something
that
that
you
all
may
also
be
interested
in.
So
I
wanted
to
share
it,
which
is
going
back
to
cve
2020
8558.
A
The
initial
fix
for
that
cve
was
done
by
adding
an
iptables
rule
in
the
kublet.
So
when
the
kublet
starts
up,
it
puts
an
iptables
rule
that
blocks
inappropriate
packets.
That
would
be
taking
advantage
of
that
configuration
such
that
it
was
still
useful
for
the
one
niche
use
case
that
needed
it,
but
was
not
useful
for
attackers.
Like
me,
I'll
put
a
link
in
the
notes
to
the
like
proof
of
concept
that
I
wrote
for
how
you
can
how
you
can
exploit
that
from
inside
of
pod.
A
But
I
was,
I
happened
to
work
with
lauren
bernai.
Who
is
one
of
the
folks
who
has
done
a
lot
of
work
on
cube
proxy
over
the
years
and
he
thought
and-
and
I
came
to
agree
with
him-
that
it
would
have
been
better
to
have
fixed
this
cve
by
modifying
coupe
proxy.
A
There's
reasons
why
it
got
fixed
in
the
kublet,
but
right
now
it
feels
awkward
that
coupe
proxy
makes
a
problem,
and
then
the
kubelet
solves
that
problem
so
like
it
says
in
the
in
the
notes,
there's
a
link
to
a
pr,
a
a
pr
of
or
almost
recently
got
merged,
so
that
when
coupe
proxy
is
running
in
ipvs
mode,
it
doesn't
set
that
cis
ctl
and
the
reason
that
that
was
able
to
be
done.
Non-Controversially
is
that
that
ctl
is
set
for
a
particular
use
case,
where
I
believe
it's.
A
So
right
now
to
get
the
pr
merged
and
at
least
mean
that
in
ipvs
mode,
coupe
proxy
is
no
longer
contributing
to
this
problem.
The
scope
of
the
fix
that
got
merged
was
reduced
down
to
only
in
ipvs
mode,
but
now
there's
still
the
question
of:
wouldn't
it
be
cool
if
nip
tables
mode.
Coupe
proxy
could
stop
causing
this
issue
so
laurel,
and
I
and
andrew
psykim
have
been
talking
about
this
in
the
pr
that
got
merged.
A
So
so
you
can
see
some
of
the
discussion
that
has
already
happened
by
looking
in
the
comments
thread
on
that
pr,
but
I
wanted
to
just
bring
this
attempt
bring
this
to
the
attention
of
all
of
y'all
because,
like
I'm,
I'm
involved
in
it
by
coincidence
of
proximity
to
the
folks
who
are
originally
involved,
but
it
seems
like
a
thing
that
might
also
be
relevant
to
your
interests.
So
I
wanted
to
share
it
with
you
and
if
you
think
it's
cool,
then
you
know
come
and
come
and
talk
to
us
on
slack.