►
From YouTube: Kubernetes SIG Security Meeting 20210325
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
So
let's
get
started,
it
is
oh
seven
how's
it
going.
Everybody.
B
B
B
A
A
Okay,
kristin's
gonna
take
notes
through
the
half
hour
and
then
sevis
is
gonna.
Take
over
yeah.
Okay,
so
are
we
doing
subgroup
reports?
First.
B
Yeah,
okay,
so
looks
like
with
ray
not
here
I
can.
I
can
report
that
it's
it's
fairly
simple.
We
have
extended
the
dates
for
the
rfp
in
order
to
gather
more
responses
from
more
vendors
and
now
that
the
new
date
is
after
the
1.21
release
date.
That
has
also
been
updated
on
the
rfp
dock,
just
for
the
sake
of
clarification,
because
it
would
be
a
pity
to
get
a
good
quality.
B
So
I
believe
that
that
is
the
only
new
news
from
rfp
those
of
you
who
have
opinions
about
third-party
auditing
firms.
You
know
please
like
reach
out
to
ones
that
you
have
had
good
experiences
with
in
order
to
help
us
to
get
more
rfp
responses.
C
Hi
this
is
robert
cicada.
I
was
I've
been
on
a
couple
of
those
calls,
and
I
did
mention
on
the
last
call.
I
think
it
was
last
week
I
have
spoken
to
cure53,
but
their
feedback
was
that
they
went
through
this
process
last
year
and
found
it
fairly
onerous
and
then,
of
course,
at
the
end
of
the
day,
they
they
didn't
do
the
audit,
so
they
felt
it
was
kind
of
for
this
year
kind
of
the
roi
to
go
through
the
effort.
Again
wasn't
quite
there
now.
B
And
sort
of
to
sort
of
to
expand
from
that,
perhaps
that
could
be
a
a
cause
of
lower
than
ideal
response.
If,
if
vendors,
who
responded
last
year
and
weren't
picked,
are
you
know,
scared
off
of
the
effort
required
to
to
respond
to
the
rfp?
B
That's
that
that's
a
that's
a
fair
point
and
I'm
glad
that
you
brought
it
up.
A
D
D
I'm
just
wondering
if
there's
a
larger
thing
that
needs
to
be
addressed,
do.
A
E
E
I
didn't
hear
at
least
I
don't
remember
hearing
anything
specifically
about
like
process
issues,
so
this
is
maybe
the
first
process
issue
that
I've
heard
a
complaint
about
that.
I
can
remember.
F
One
one
other
piece
of
feedback
I
had
I
reached
out
to
some
uk
boutiques
and
I
got
one
piece
of
feedback,
which
was
that
one
of
them
felt
they
didn't
already
have
a
strong
kubernetes
experience
in-house
and
because
the
report
was
public,
they
didn't
feel
confident
in
doing
that
as
like
their
first
piece
of
work.
F
The
only
potential
thing
I
thought
about
that
was,
as
more
companies
got
to
do-
maybe
some
of
the
smaller
cncf
audits
that
might
help
them
build
up
confidence
towards
this,
which
is
a
very
large
piece,
and
I
can
understand
why
a
boutique
doesn't
want
to
take
this
one
as
their
first
like
cncf
public
audit.
F
So
I
don't
know
whether
that
might
be
something
we
can
do.
Kind
of
going
forward
is
trying
to
expand
that
pool
of
companies.
Who've
done
work
in
this.
D
Area,
it's
a
pretty
high
bar,
that's
set
in
that.
I
think
it's
a
good
bar,
but
it's
a
high
bar
set
in
that
in
the
rfp.
Just
a
high
flute
general
talk,
maybe
for
a
future.
D
Is
there
something
that
either
cncf
or
kubernetes
community
could
do
to
sort
of
help
those
vendors
get
up
to
speed.
G
B
Yeah,
I
was
actually
just
kind
of
wondering
something
like
that
like
to
address
the.
We
worry
about
our
expertise
there,
like
I,
I
wonder
if
sigs,
who
are
particularly
interested
in
having
some
of
their
code,
getting
good
attention
during
an
audit
would
be
able
to
to
participate
in
that
with
the
vendor,
like
helping
like
having
an
onboarding
session
to
their
part
of
the
code
base
with
the
vendor
to
help
the
vendor
get.
B
D
I
was
thinking
almost
bigger
like,
but
I
don't
know
what
like
could
we
offer
training
or
because
yeah
it's
exactly
if
you're
doing
an
audit
and
there's
someone
in
the
room
who's
able
to
point
you
out,
that's
a
godsend,
but
you
know
something
like
kubernetes.
Is
such
a
large
beast?
If
you
don't
have
experience
with
that,
I
mean
I've
walked
into
code
reviews
before
where
I
didn't
know
anything
about
the
product.
D
A
I
can
imagine
it
being
daunting,
I
mean
I
say
this
with
my
sig
chair
hat,
firmly
off,
to
be
clear.
Like
there's
a
part
of
me
that
is
like
well,
but
if
you
don't
have
a
lot
of
kubernetes
expertise
and
we're
the
ones
who
have
to
train
you,
then
I
worry
about
the
results
of
the
audit,
like
I
kind
of
want
the
people
who
are
going
to
be
auditing
us
to
be
there's.
H
C
F
C
Doing
code,
review
of
particular
sections
you
know,
especially
if
it's
a
crypto
related,
might
be
beneficial
to
have
someone
who's,
not
a
kubernetes
expert,
but
a
crypto
expert
right.
Just
I'm
just
brainstorming
random
thoughts
here
versus.
If
we're.
If
we're
specifically
auditing
the
code
around
you
know
the
kubernetes
api
xyz
then
sure
having
context
there
is
probably
more
important
than
having
you
know,
basic
principle
coding
knowledge.
If
you
will.
F
Yeah
I'd
agree.
I
think
that
idea
may
be
of
something
like
I
I
I
you
say
you
want
someone
with
expertise,
but
the
hard
part
is:
how
do
we
make
poor
people
like
that?
How
can
we
essentially
help
the
pen
test
industry
get
point
where
there's
a
wider
scope,
otherwise,
we'll
end
up
with,
like
one
view
from
one
or
two
companies,
maybe
and
yeah,
that
is
a
yeah
breaking
it
down
or
training,
or
the
the
smaller
cncf
audits.
All
sound
like
things
that
might
help
expand.
That
pool.
F
H
C
The
best
won't
come
for
money,
the
best
will
come
for
you
know
for
the
principal.
If
you
will,
is
there
a
way
to
expand
this
more
into
the
community?
You
know,
and
maybe
academic
or
practitioners,
but
is
there
a
way
that
we
can?
You
know,
there's
some
expertise,
that
is
certainly
organized
around
commercial
auditors
and
and
they
cultivate
and
invest
in
that
and
that's
totally
appropriate.
But
maybe
there
are
parts
that
we
can
can
layer
out.
A
I
mean,
I
think,
that's
what
we
try.
That's
what
we're
trying
to
do
here
in
real
time.
I
think
that's
like
one
of
the
reasons
why
we're
doing
the
things
that
we're
doing
I'll
say
that
at
least
from
my
experience
with
the
open
ssf
governing
board,
my
understanding
of
how
lf
cncf
does
these
kinds
of
highfalutin
auditor
things
is
less
flat
and
community
oriented
than
I
would
be
inclined
to
set
up
personally
like
it
is
a
more
sort
of
commercial
process.
A
I
think
in
terms
of
how
they
contract
with
vendors
than
like
the
kind
of
like
collective.
You
know,
chaos,
anarchy,
thing
that
I
would
personally
prefer
to
do,
and
I
don't
know
exactly
what
that
scope
looks
like,
but
I
I
do
think
it's
a
thing
in
the
world.
B
And
like
that
kind
of
gets
back
to
the
previous
point
about
kubernetes
is
as
large,
probably
as
all
the
rest
of
the
cncf
projects
put
together,
at
least
in
like
lines
of
code,
and
so
you
know
that
that
more
that
more
commercialized
kind
of
procedure
may
be
something
that
that
the
commercial
pen
testing
industry
is
more
ready
to
take
on
for
smaller
things
that
don't
have
as
much
of
a
spotlight
on
them.
As
the
kubernetes
audit.
A
A
B
E
E
Okay,
we
solicited
from
a
couple
others,
but
they
bowed
out
for
reasons
similar
to
what
rory
mentioned
the
boutique
vendors,
some
of
the
smaller
vendors
thought
it
was
more
than
they'd
like
to
take
on
publicly.
I
Is
is
there
a?
Is
it
a
concern
of
complexity?
Is
it
time,
is
it
expertise,
or
I
guess,
is
it
all
the
above,
probably
working
against
them.
E
Yeah-
I
don't
remember
I
I
only
was
I
only
reached
out
to
one
of
those
that
I
mentioned
and
they
specifically
said
they
were
too
busy
and
they
didn't
think
they
could
get
it
done
in
the
timelines
that
we
outlined,
probably
because
they
were,
you
know
small
and
busy.
At
the
same
time,
sure.
C
I
will
say
having
doing
this
in
a
number
of
commercial
contexts
for
products
reaching
out
to
these
vendors.
All
of
them
are
booked
right
now,
through
june,
more
or
less
so
they're,
not
even
taking
new
projects
on
commercially
for
non-kubernetes.
A
I
A
When
you
divide
up
the
work
that
way,
I'm
going
to
say
strongly
in
my
professional
experience,
you
end
up
into
trouble
that
way.
It's.
B
I
mean
a
question
about
this,
though,
like
to
jump
off
of
the
everybody's
booking
in
in
the
summer.
Like
I
guess
we
could
get
more
data
from
this
by
reaching
out
to
some
of
those
disappointed,
vendors
and
seeing
what
they
have
to
say,
but
I
wonder
if
those
timelines
are
off-putting
like
if
it's
instead,
if
it
was
instead
and
tell
us
when
you
would
be
available,
and
we
can
take
your
availability
into
consideration
among
the
other
things
that
we're
considering
like
you
know,
maybe
the
rfp
is
too
prescriptive.
B
J
A
J
A
As
a
time
check,
it's
11
23
and
I
think
this
conversation
is
good
and
productive,
but
I
also
do
want
to
make
sure
that
we
have
time
and
space
to
talk
about
the
other
things
on
the
list.
So
I
am
not
cutting
it
off,
but
I
am
just
pointing
out
what
time
it
is.
B
I
My
thoughts
on
this
to
sort
of
close
out,
the
last
things
I
would
say
is
if
we
have
a
set
of
two
or
three
questions
that
we'd
want
to
ask,
and
if
we
have
the
interpersonal
connections
where
one
of
the
members
that
knows
one
of
the
prior
submitting
vendors
asks
the
same
two
or
three
questions
like.
Is
it
a
matter
of
this?
A
A
I
I
B
And
and
to
the
to
your
point
of
of
needing
to
find
out
the
answers
to
these
questions
like
as
I
am
reviewing
the
rfp
again,
all
of
the
concerns
that
we
have
brought
up
here
are
actually
already
addressed.
The
timeline
in
the
rfp
is
open.
The
rfp
already
includes
an
offer
to
connect
the
vendor
with
required,
subject
matter,
experts
as
needed,
like
all
of
these
things,
are
there,
but
it
is
very
dense
and
intimidating
looking
so
so,
the
communication
really
does
seem
like
the
next
step.
B
C
F
F
E
B
B
Shall
we
then
move
on
sure,
okay,
there's
a
couple
of
of
caps
that
are
that
are
pretty
exciting
that
I
wanted
to
call
to
everybody's
attention.
There
is
a
cap
now
for
psp
replacement.
B
Thank
you
all
so
much
to
everybody
who
has
been
coming
to
those
separate
meetings
and
contributing
to
the
great
discussions
there
you
can.
You
can
click
on
the
link
to
see
the
to
see
the
pr
for
that
cap,
but
those
meetings
are
are
still
ongoing.
We
had
one
earlier
this
week
we're
going
to
have
one
two
weeks
from
now
and
in
the
meantime,
it's
a
cup.
It's
like
designed
for
being
able
to
be.
You
know
addressed
in
a
in
an
asynchronous
fashion,
and
so
you
know
please
please
go
and
help
with
that.
B
All
I
I
mean
we
can
very
briefly
the
the
the
very
brief
tldr
of
of
what
this
cap
is.
Is
a
built-in
admission
controller
with
optional
web
hook,
replacement
that
looks
for
certain
labels
on
namespaces
in
order
to
indicate
that
that
namespace,
which
is
to
have
admission
control
or
warning
or
auditing
like
auditing
onto
pods
and
warning
back
to
the
user,
using
the
new
warning
mechanism
for
various
hard-coded
levels
of
enforcement
that
correspond
to
what's
listed
in
the
pod
security
standards
document.
B
And
so
you
know
the
the
details
are
all
in
the
cap
and
being
worked
out
in
the
cap.
But
the
overall
goal
of
it
is
to
be
as
simple
as
reasonably
possible
while,
while
having
enough
flexibility
that
people
could
live
with
it,
but
not
providing
enough
flexibility
that
it
becomes
a
problem,
and
so
it's
a
it's
a
it's
a
real
hybrid
of
the
two
of
the
two
previous
proposals
that
have
been
discussed
here
and
in
other
places,
I'm.
I
am
super
super
happy
with
it.
A
J
B
Anybody
has
anything
they
want
to.
They
want
to
bring
up
about
that
one
or
otherwise
I'll
point
it
another
one.
K
A
Might
be
under
sig
off
it,
they
may
or
may
not
have
listed
it
in
their
agenda,
but
it
is
every
other
wednesday
at
3
central
time
and
it
is
officially
a
sig
off
project
and,
like
I
think,
those
meeting
recordings
go
under
their
meeting
recordings.
So
I
would
look
at
the
basics.
A
For
where
that
information
would
be.
B
No,
no,
no,
I
think
I
think
community
resources
is
the
term
that
we
would
use
cube,
adm
control
plane.
This
one
is
this
one
is,
is
pretty
interesting,
it's
very
active
and
I
think
we
all
agree
that
it's
a
good
idea
and
the
the
number
of
of
little
corner
cases
that
needs
to
be
addressed
to
make
it
happen
is
huge.
A
A
H
H
Yeah,
it's
basically
I've
been
focused
on
running
the
control
plane
in
cube
up
as
non-root,
and
now
that's
done.
We
wanted
to
also
extend
it
to
cubadium,
which
was
an
idea
that
benjamin
elder
pitched
to
me-
and
I
was
like
oh
yeah.
This
makes
a
lot
of
sense.
I
want
to
run
everything
it's
not
rude
if
possible,
so
yeah
I
this
is
my
first
time
writing
a
capsule
most
of
the
comments
which
were
like
74.
H
The
last
time
I
checked
were
because,
like
I
missed
some
sections
in
it,
but
that
being
said,
I
also
feel
like
there's
something
that
we
should
just
do
and
not
wait
for
the
cap,
which
is
like
second
profile,
but
I
think,
there's
like
very
little
risk
to
like
adding
that
to
the
control
playing
things,
but
yeah,
please
hit
the
cap
I'd
love
to
hear
your
comments
on
it.
I'm
not
an
expert
in
youtube
admin
as
well,
but
I
am
going
through
the
code
and
trying
to
become
one
in
writing.
H
This
gap
yeah.
B
B
All
right,
joel,
do
you
want
to
do
you
want
to
talk
about
handling
of
of
low
unfixed
cves.
E
Yeah,
so
this
is
something
that
the
product
security
committee
is
thinking
about,
we're
evaluating
different
options,
but
we
wanted
to
solicit
input
from
this
body,
so
the
the
the
problem
is
there
are
we
sometimes
have
we?
E
You
know
whether
we
discover
them
or
people
report
them
to
us
low
security
issues
which
were
kind
of
tracking
behind
the
scenes,
but
maybe
will
take
a
long
time
for
us
to
fix,
because
maybe
it's
something
architecturally
or
it
might
be
just
a
priori
priority
thing,
and
so
the
the
problem
is:
what
do
we
do
with
those
where
they're
low?
We
think?
Maybe
it
would
be
okay
for
us
to
make
them
public?
E
In
fact,
some
of
them
are
public
already,
just
like
in
github
issues
and
whatnot,
but
I
guess
the
question
is:
should
what
do
we?
What
do
we
think
we
should
do
about
tracking
them
with
cve?
Should
we
assign
them
cves,
even
though
we
don't
have
a
solution
for
them
and
just
kind
of
have
a
place
to
track
cves
that
we're
tracking
that
are
unfixed
and
public,
or
is
that
going
to
like
cause
a
lot
of
headaches
for
kind
of
downstream
users
of
kubernetes?
E
Who
will
then
panic
because
hey
there
are
unfixed
cves
in
kubernetes,
even
though
really
the
only
difference
is
we've
labeled
it
with
a
cve
number,
but
the
bug
was
there
all
along
right?
Does
that.
E
Yeah,
so
I
guess
what
we're
trying
to
figure
out
is
a
process
to
handle
these
things.
So
if
we
make
them
public,
if
we
sign
them
as
cve,
do
we
need
a
place
to
track
open?
Unfixed
cves
is
just
having
a
github
issue
with
cve
such
and
such
as
the
start
of
the
the
issue
title.
Is
that
sufficient
anyway?
That's
the
kind
of
thing
we're
interested
in
hearing
about.
A
His
ian
chair,
it's
two
thoughts
on
this
off
the
top
one
is
like
really
sick,
hat
firmly
off.
I
think
there
is
some.
A
I
don't
think
this
is
a
blocker
of
any
kind,
but
just
to
put
it
out
into
the
world.
I
think
there
is
some
ambient
low-level
mild
consternation
among
people
who
have
been
messing
with
kubernetes
for
a
long
long
time
about
the
fact
that
there
are
things
that
have
been
long
known
that
are
now
being
declared
cves
and
sort
of
give
it
out.
A
You
know-
and
I
don't
know
what
to
do
about
that
really,
except
to
just
note
that
it
is
a
thing
in
the
world
and
and
and
more
sort
of,
I'm
not
sure
about
actionably,
but
at
least
he's
I
don't
know,
while
I'm
thinking
out
loud
it
would
it
cause
panic
to
have
here
is
our
list
of
unfixed
cves.
A
F
I
think
no
and
I'll
say
why
so
last
year's
the
2019
security
audit
there
are
highs
from
that
that
are
still
unfixed
and
there
has
not
been
a
huge
outcry
and
a
lot
of
people
saying
hey
this.
This
is
a
high
and
it
was
raised
in
2019.
What's
going
on
and
to
my
surprise,
to
be
honest,
the
good
one
would
be
certificate,
revocation
the
lack
of
support
for
certificate,
revocation,
I'm
not
seeing
a
big
push
from
user
organizations
to
fix
that,
but
it's
a
high
and
it's
been
open,
for
I
mean.
E
Is
not
so
I
suspect
that
you
are
right
that
if,
if
we
had
assigned
a
cve
to
that
issue
that
there
would
be
a
lot
more
panic
and
a
lot
more,
you
know
it
would
be
a
lot
more
noticeable
to
end
users
and
we
would
get
a
lot
more.
You
know
people
saying
why
isn't
this
fixed,
why
isn't
this
fixed.
H
A
J
In
for
for
the
customers
I
talk
to,
if
it's
you
know,
I'm
sorry,
I
get.
What
is
it
critical
and
important
are
those
the
nvd
ratings.
I
get
them
mixed
up
with
red
hat
ratings.
Unfortunately,
but
the
two
are
the
most
important:
if
they're
below
those
two
top
priority
items,
it
does
not
necessarily
start
a
clock.
J
I
agree,
it
depends
on
the
customer
and
in
the
environment,
some
of
them,
you
know,
say
every
cbe
should
be
fixed,
which
is
not
realistic
in
my
opinion,
but
but
it's
really,
you
know
the
ones
that
are
that
are
critical
or
important,
assuming
I've
gotten
the
terminology
right
and-
and
so
the
question
I
would
have
is:
are
we
willing
to
commit
to
those,
and-
and
would
you
disagree
about
my
assessment
too?
Do
you
run
into
other
customers.
E
So
this
is
discussion
I
think
it's
good
to
have
generally,
but
we're
specifically
wondering
about
low
typically
for
criticals
and
highs.
We
will
handle
those
behind
the
scenes
under
embargo,
but
mediums
and
lows,
depending
on
depending
on
the
issue,
may
be
handled
publicly.
So
that's
why
we're
bringing
it
up
specifically
in
the
context
of
love
that
makes
sense.
F
I'd
say
that
even
if
they
don't
get
a
cds
assigned
to
stop
talk,
clocks
ticking
having
them
publicly
would
be
a
great
benefit.
If,
for
no
other
reason,
then
you're
going
to
really
annoy
bug
bounty
participants,
if
you
keep
them
secret
and
then
all
the
bug
made
people
go
yeah,
it's
a
jew
and
you're
like
yeah.
We
know
it's
a
jew
and
they're
like
we
couldn't
have
known
that.
F
So
I've
wasted,
like
you,
know
two
weeks
finding
this
for
you
and
now
you're
just
going
to
tell
me
it's
a
dupe,
but
I
know
that's
a
great
source
of
frustration
amongst
that
class
of
people.
So
even
if
we
say
right
we're
not
going
to
put
cvs
on
these
yet,
but
here's
a
list
of
things
we
know
about
that
are
kind
of
you
know
on
a
backlog
somewhere,
and
we
can
point
people
out
and
say
before
you
go
digging
around.
This
is
the
stuff
we
already
know
about.
E
Yeah,
that's
an
interesting
idea,
so
basically
have
a
place
where
we
list
them
all,
but
have
them
have.
Maybe
we
can
have
a
cve
number
and
just
have
it
marked
unassigned
for
the
ones
that
we're
not
quite
ready
to
move
on.
F
B
L
I
have
one
question
so
the
idea
of
listing
it
are
we
going
to
ask
the
community
to
participate
and
try
fixing
things,
or
is
it
just
for
the
purpose
of
listing
it
out
that
okay,
hey?
We
do
have
certain
low
and
the
medium
vulnerabilities.
We
want
to
list
it
out.
E
I
think
both
so
I
think
we
would
love
it.
So
the
idea
is
with
these
low
ones,
since
it's
okay
for
them
to
be
made
public,
because
because
the
impact
isn't
high
or
you
know
for
all
the
reasons
things
are
marked
low,
then
yes,
we
can
make
it
public
and
that
that
allows
you
know
any
contributor
to
pitch
in
and
help
with
the
fix,
but
also
raises
awareness.
So
I
think
I
think
both
goals
are
good
goals.
E
I'm
not
sure
if
they
are,
but
kubernetes
is
so
we
we
are,
we
are
cna
and
have
numbers
reserved,
so
we
can
assign
them
as
soon
as
we're
ready
to.
We
just
you
know,
are
worried
about
assigning
assigning
things
and
causing
problems
for
end
users.
We're
really
no
problem
exists.
B
This
this
comes
up
a
lot
on
like
oss
sec
as
well
of
like
there
is
an
issue
which
can
be
considered
by
some
to
be
a
security
issue.
B
Is
it
a
net
overall
good
to
the
community
to
issue
a
cve
for
it
or
not
and
like
based
on
the
fact
that
a
lot
of
different
folks
seem
to
be
having
that
same
kind
of
argument?
I
I
love
the
idea
of
separating
out
these
two
discussions
of
like
getting
issues
that
we
know
about
public
separate
from.
Do
we
try
to
issue
cves
aggressively
or
not.
E
Yeah,
I
I
think
they
really
are
two
separate
issues
and
we
were
kind
of
thinking
of
it
as
one
like.
We
need
to
make
this
public
and
assign
a
cvi.
I
guess
we
don't
really
need
to
do
those
two
things
in
tandem.
We
can
delay
the
issuance
of
cv.
A
Like
as
again
sig
cat
six
security,
chair
hat
off,
like
as
a
researcher
I
like
getting
cds,
you
know
like
it's
nice
to
have
them
assigned
as
an
end
user
who
has
to
deal
with
other
people's
issued
cves.
You
know
like
on
a
security
team
once
those
numbers
start
getting
assigned,
then
everybody
is
like.
Oh
there's
a
number.
We
have
to
go
fix
this
right
now
and,
like
you
know,
everybody
starts
running
around
with
their
hair
on
fire
and-
and
I
worry
about
places
that
have
mandatory
slas
upon
cbe
assignation
running
into
trouble.
A
If
we
start
having,
if
we
start
assigning
cves
for
things
that
we
don't
have
on
the
roadmap
to
fix
within
sla,
you
know,
because
if,
if
security
teams
start
routinely
running
into
you
have
60
90,
whatever
your
company's
number
is
days
to
patch
this
thing
and
we're
like
won't
fix
or
whatever
then
like.
A
J
D
E
Got
these
it's
both,
so
some
of
them
have
been
known
for
years,
and-
and
we
would
just
kind
of
like
to
well
so
I'll-
give
you
an
example,
so
node
disk
denial
of
service
there's
a
lot
a
lot
of
issues,
a
lot
of
ways
that
a
malicious
container
can
basically
run
the
node
out
of
disk,
and
so
some
of
those
were
reported
and
were
new
to
us
and
we
handled
them
through
the
bug
bounty
program.
E
Despite
the
fact
that
there
are
already
known
other
ways
of
doing
the
same
exact
thing,
I
mean
the
same
exact
attack.
You
know
different
different
way
of
running
the
node
out
of
disk,
and
so
we
would
like
to
track
some
of
those
older
ones
as
security
issues.
Now
too,
because
that's
something
we've
decided
is
is
worth
fixing
and
then
even
even
more
recently,
we've
found
even
a
couple
other
ways
of
doing
it
that
were
new,
so
some
new,
some
old
and
we
just
want.
E
We
want
to
kind
of
be
consistent
in
how
we
handle
those,
because,
as
ian
mentioned
in
the
past,
we
had.
We
have
ignored
a
lot
of
these
things
and
said
it's
not
something
we
care
about
so
now
that
we've
started
caring
about
certain
classes
of
bugs.
We
just
want
a
way
to
track
them.
A
Fair
enough,
I
wonder
if
I
am
annoyed
at
myself
for
coming
up
with
this
idea,
while
being
in
the
middle
of
writing
a
kubernetes
blog
post.
I
wonder
if
it
would
be
worth
putting
out
some
sort
of
communication
at
some
not
doesn't
have
to
be
immediate
point
about,
because
I
think
that
is
a
thing
I
see
people
wondering
of
like.
Why
is
this
considered
a
cve?
A
And
have
changed
our
posture,
yeah
or
just
like,
as
as
kubernetes
has
evolved,
our
threat
model
has
evolved
and
here's
how
we're
thinking
about
this
and
here's
how
our
thoughts
are
evolving
like
I,
I
think
that
might
be
useful
for
people
as
a
like
doesn't
have
to
happen
right
this
minute,
but
like
especially
if
it
is
connected
with
something
like
the
release
of
a
like
here
are
things
that
we're
aware
of
list.
I
think
that
communication
would
be
good
for
people.
B
A
Also
that,
although
I
wasn't
immediately
thinking
in
that
direction,
but
yeah,
I
think
you
know
also
whether
if
you
have
a
pile
of
cve
numbers
that
have
suddenly
appeared,
people
will
freak
out.
If
you
have
a
pile
of
heroes
or
won't
fix
backlog,
I
think
people
will
freak
out.
So
probably
there's
you
know
some
amount
of
like
comms
stuff
here,
but
I
would
I
I
cannot
believe
I
am
volunteering
for
this
right
now.
I
would
be
happy
to
help
with
that.
I
think
that
seems
really
important.
B
A
Yeah,
but
I
I
think
I
think
that
we
could
do
it
well.
I
think
there's
lots
of
ways
that
that
could
go
wrong,
but
I
don't
think
it
has
to
and
that's
not
priority
right
now
and
we
have-
I
have
a
blog
post
to
finish
about
pine
isolation
policies,
but
putting
putting
myself
out
there
as
like
a.
I
think
this
might
be
good
to
do
at
some
point
later.
E
Yeah,
that
sounds
great.
I
did
want
to
circle
back
on
one
thing,
so
we
we
do
try
to
give
attribution
to
whoever
found
the
issue
and
reported
it
to
us
originally,
even
if
there's
a
delay
and
given
the
cve.
So
if
if
people
could
put
on
their
researchers
hat,
how
frustrating
is
it
to
you
if
you
find
something
and
there's
a
long
delay
before
we
assign
a
cve?
E
E
Not
necessarily
like,
if,
let's
say
we
have
a
tracker
that
says
here
are
the
issues
that
we're
tracking
and
maybe
some
of
them
are
unassigned,
some
not
assign,
and
we
can
certainly
give
attribution
while
it's
in
either
state,
but
certainly
by
the
time
we
get
a
cve.
We
want
to
have
an
an
attribution.
I
I'd
say
you
know,
time
is
a
little
bit
less
important
than
just
having
the
attribution
at
some
point.
You
know
whenever
it
becomes
public.
The
attribution
is
there,
I
think
that's
the
the
best
you
can
do
if
it's
taken
too
long
to
get
the
assignment,
and
you
know
at
least
you
you
reached
out
to
the
researcher
and
said:
is
it
okay
to
use
your
your
name
or
this
and
give
you
attribution
if
they
say
yes
as
long
as
when
it
goes
public
I'd
say
you
have
that
alongside
it?
A
This
is
probably
going
to
depend
on
the
person
like
some
people,
I
think,
are
much
more
aggressive
about
timelines
than
others,
and
I've
definitely
seen
some
security
research
who
get
like
super
aggro
about
it
in
a
way
that,
like
I
personally
wouldn't
I
think
communication
to
me
seems
like
the
important
part
like
if
it
is
like
you
know,
if
it's
gonna
be
a
year,
one
and
you
know,
and
the
project
is
like
hey,
you
know
right
now,
we're
like
working
on
our
you
know,
backlog
threat,
model
stuff
and
you
know
acknowledged-
and
you
know
seen-
and
you
know
that's
like
here's-
where
we're
at
and
are
just
you
know
like
open
about
that
and
communicating
it
like
I'm
cool
with
it
being
longer.
A
If
I
don't
hear
back
from
them
for
a
year,
then
it's
like
what
the
heck
is
happening
here.
You
know
like
like
that
I
think
is
bad
behavior,
and
so
as
long
as
as
long
as
transparency
and
communication
are
happening
like
I'm
still
with
it,
but
I
cannot
say
that
every
researcher
on
earth
is
still
with
it.
I.
B
B
G
So
I
put
the
item
for
capabilities
for
non-root
containers
and
I
was
enchanting
it
as
sort
of
a
discussion
item.
So
eight
minutes
might
not
be
enough.
I'm
fine
with
pushing
it
to
the
next
meeting.
If,
if
needed,.
K
My
clipline
about
convincing
h1
cred
logs
are
bad
kind
of
fits
in
with
this
cve
discussion,
so
whenever
credentials
appear
in
logs,
those
tend
to
be
either
low
or
medium
as
like
an
escalation
path
for
an
attacker
who
might
have
access
to
logs
to
obfuscate
their
identity
and
in
in
the
context
of
potentially
doing
some
of
this
more
in
the
open
like
it
is
a
question
of
how
we
should
disclose
those
if
we
should
be
going
through
h1
or
hacker
one
in
the
bug,
bounty
program
or
not,
because
usually
by
the
time
we've
identified,
a
possible
credential
log
site
like
the
fix,
is
trivial
and
we
know
what
we
need
to
do.
K
But
yeah
we've.
I
know
it's
it's
a
colleague
of
ours
that
has
bumped
into
this,
of
maybe
finding
a
site
didn't
have
a
full
reproduction
at
the
time
and
there
seems
to
be
some
pushback
from
the
hacker
one
triage
I
as
to
whether
or
not
this
is
like
an
actual
issue.
So
yeah
it's
more
about
just
like
administrative.
If
we
need
to
like
talk
to
whoever
triages
those
things
actually
accepting
the
plain
text
logging
of
creds
is
bad.
L
K
A
Actual
question
I
don't
know
the
answer
to
this:
is
that
hacker
one
wide
policy
or
is
it
that
individual
vendors
get
to
decide
what
seems
bad
for
individual
vendors?
Because
do
you
want.
A
E
It's
it's
the
letter
ian
we
so
we
lay
forth
a
policy
of
what
we
consider.
You
know
we
have
different
tiers
of
of
things
like
we'll
say.
If
it's,
if
it's
in
the
core,
then
it's
tier
one
and
so
on
and
so
forth
anyway.
E
So
we
lay
that
out
in
the
hacker
one
kind
of
organization
document,
but
as
as
to
the
triage
process,
I
I
can
kind
of
speak
from
the
other
side,
so
hacker
one
yeah,
they
do
like
a
triage,
and
that
saves
us
from
getting
like
six
mil
having
to
handle
six
million
reports
of
your
dmarc
record
is
missing
and
you're
subjectively
jacking
and
all
those
kind
of
like
no
op
reports.
So,
yes,
there
is
a
delay
between
something
getting
reported
and
making
it
through
the
triage
process.
E
A
lot
of
that
is
just
because
hackerone
triage
folks
are
not
kubernetes
experts
and
they're
kind
of
having
to
learn
over
time.
What
are
and
aren't
issues
frequently
they'll
send
us
things
that
make
it
through
triage
that
are
definitely
not
issues
they're
like
intended
product
behavior
and
that's
okay.
We
don't
expect
them
to
know
everything
but
yeah.
E
It
does
introduce
a
delay,
and
so
that's
maybe
something
that
the
psc
can
do
better
at
it
kind
of
like
keeping
an
eye
on
those
things
that
are
in
the
process
of
being
triaged,
but
it
you
know
it's
hard
to
find
the
right
balance
of
having
them
help
us
ignore
the
things
that
aren't
important,
while
not
introducing
too
much
delay
into
the
process
for
the
things
that
really
are
important,
and
this
may
be
a
class.
E
You
know
if
there
are
specific
classes
of
bugs
where
we
can
work
with
them
to
you
know,
increase
their
ability
to
accurately
triage
it,
and
certainly
we
can
provide
them
with
that
feedback,
but
yeah
it's
a
hard
problem.
It's
a
hard
problem
to
solve,
and
I
I'm
sure
there's
more
that
can
be
done
to
get
get
it
right.
B
A
B
E
Just
one
other
thing
I
want
to
throw
out
there
for
specific
issues.
We
would
prefer
that
those
would
be
handled
directly
with
the
psc
just
in
case
just
in
case
the
psc
thinks
it's
more
serious
than
you
think
it
is.
We
certainly
don't
want.
You
know
we
want.
We
want
to
encourage
responsible
disclosures
where
I'm
headed
with
this.
So
as
long
as
these.
E
Yeah,
so
we
just
want
to
give
the
psc
a
chance
to
handle
specific
issues
in
private
if
possible,
but
certainly
for
general
case.
Like
you
know,
in
the
case
of
this
class
of
bugs,
we
think
the
psc
is
overrating
or
underrating
the
security.
You
know
those
kinds
of
conversations
are
great
to
have
and
we
can
have
those
in
public
but
yeah.
I
think
ultimately,
the
psc
will
take
that
feedback
and
make
a
decision.
K
Yeah,
so
is
there
like
for
specifically
like
what
kept
1753
that
michael
and
I
have
been
working
on
flying
to
like?
Is
that
something
the
sorry
with
the
the
efforts
to
prevent
logging
creds?
So
there's
the
analyzer
in
1753
there's
also
filtered
logging
in
1933.,
but
is
so
I
maybe
hopped
on
these
caps
after
this
conversation
had
already
happened
with
psc,
but
just
like
that
documented
that
this
is
a
thing
according
to
just
the
kubernetes
stance.
K
E
So,
are
you
saying
like
what
once
let's
say
these
kept?
So
are
the
caps
to
add
code
to
do
log
filtering.
K
Yeah,
so
1933
adds
filtered
log
methods
that
will
automatically
redact
things
that
are
tagged
with
data
policy
tags
that
are
in
the
process
of
being
rolled
out.
Filtered
logging
is
just
as
like.
There
are
a
couple
specific
log
methods
that
would
say
run
the
filter
on
this.
1753
is
the
one
that
I'm
the
I
authored
is
a
testing
phase
that
does
some
static
analysis
to
avoid
new
potential
log
calls
being
introduced.
K
So
there
is
a
test
that
runs
during
the
you
know:
crowd
jobs.
K
But
like
the
existence
of
these
caps
demonstrates
our
stance
on
that,
and
I
guess
there
would
just
be
like
I.
Maybe
that
is
the
documentation
that,
like
this
is
the
kubernetes
stance.
Don't
log
your
creds,
the
issue
comes
down
to
like
we've
gotten
some
pushback
during
triage,
where
we
have
like
identified
a
potential
potential
issue.
This
is,
as
we've
been
doing,
some
iteration
on
the
analyzer
that
hasn't
yet
like
stabilized
to
the
point
where
we
should
pour
it
into
kubernetes,
but
like
in
reporting.
K
Some
of
these
issues
we're
getting
pushback
as
to
whether
or
not
they
are
actual
issues
from
h1.
B
K
H
K
I
mean
I'd,
we
can
take
this
to
slack
and
if
it
ends
up
being
not
great
in
a
linear
format,
we
can
just
punt
it
for
next
meeting.
Okay,.
B
Thank
you
all
so
much
for
for
your
understanding
of
that
and
for
the
great
discussion
like
if
we're
running
to
time.
It's
because
we
have
important
things
to
say
to
each
other.
So
thank
you
all
so
much
for
coming
and
for
bringing
your
thoughts
and
for
bringing
your
faces
and
for
working
to
make
kubernetes
better
and
more
secure
like
yeah.
This
is
you're
all
wonderful
and
we'll
see
you
soon.