►
From YouTube: Kubernetes SIG Security 20220210
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
A
I
love
to
hack
things
and
make
friends
and
hack
things
with
my
friends
and
being
able
to
do
that
here
and
to
help
to
make
the
help
to
make
this
space
that
we
all
share
so
that
we
can
do
the
things
that
we
do
together
to
improve.
Kubernetes
is
such
a
joy
for
me.
B
C
Okay
yeah,
I
just
realized
people
doing
like
this.
I
can't
hear
pushkar
clearly
so,
okay,
now
it
never
it's
better
I'll,
repeat
just
quickly
leadership,
security,
tooling
sub
project
and
wants
to
make
my
dreams
come
true
for
securing
kubernetes
and
everyone
else's
as
well.
D
A
E
Hello-
oh
sorry,
sorry,
hello!
I'm
like
I'm
young
here
I'm
trying
to
get
some
information
and
get
my
first
contribution
to
into
security
and
kubernetes
security.
A
F
All
right,
yeah,
I'm
jeremy,
I'm
a
security
or
secret
release
person
also
from
apple
and
I'm
here
today,
because
I'm
interested
always
in
image
signing
stuff.
So
can
we
hear
about
that
and
also
the
discussion
about
the
pre-announcements
for
vulnerabilities.
G
Hello,
my
name
is
also-
I
am
well,
usually
go
as
puerto
everywhere,
so
I
work
with
chain
guard
and
I
am
one
of
the
checklists
with
sid
release
and
I'm
currently
involved
with
phrme
and
other
folks
on
the
on
the
effort
to
sign
the
kubernetes
images,
which
I
hope
we
can
talk
a
little
bit
later
today.
H
All
right
so
yeah,
okay,
can
I
move
on
okay.
Thank
you,
hi
benjamin
here
from
germany,
I.t
security,
student
and
my
main
project,
or
I'm
currently
mostly
involved
in
confidential
kubernetes
environments,
building
them
and
yeah.
We
do
research
about
it.
I
Hey
everyone,
I'm
james,
cleverly
bronze,
I'm
a
security
engineer,
slash
consultant
at
control,
plane
second
meeting
now
so
just
hoping
to
contribute
and
push
kubernetes
security
forward.
A
J
Nice
to
meet
everyone,
I'm
tommy
mccormick,
just
I'm
here
from
datadog
as
well.
It's
tabitha
and
I'm
been
kind
of
here,
probably
over
six
or
eight
months,
and
just
trying
to
get
a
little
more
involved.
I
think
I
had
my
first
contribution
to
sig,
tooling
or
security
tooling,
so
just
trying
to
get
a
little
more
more
involved.
There.
F
Hello,
I'm
tim
all
claire,
I'm
one
of
the
members
of
the
security
response
committee,
along
with
tabitha
and
dropping
by
to
talk
about
security
pre-announcements
and
hear
what
else
is
going
on.
K
L
M
Hey
I'm
agam
I'm
from
apple
work
with
jeremy,
briefly
overlapped
with
tim
here
to
here
to
join
the
community
in
the
security
side.
I've
attended
a
few
of
these
meetings
a
couple
times
but
yeah
today,
I'm
really
interested
in
tina's
proposal
for
the
pre-announcements
and
I'll
keep
dropping
by
once
in
a
while
with
my
interest
in
security.
M
N
O
So
I'm
frederick,
I
am-
I've-
been
working
and
volunteering,
some
of
my
time
with
the
cncf
security
tag
for
for
a
while
and
decided
to
join
in
on
some
of
these
calls.
So
I
can
learn
more
about
what's
going
on.
A
All
right,
let's,
let's
get
to
some
of
these
things-
that
we've
got
on
the
list
today
I
see
tim
has
said:
can
we
can
we
talk
about
this?
This
proposal
pretty
early
and
I
think
that's,
I
think,
that's
a
reasonable
thing
to
do
tim.
Do
you
wanna?
Do
you
wanna
tell
us
what
you're
thinking
please.
F
Yeah
thanks
for
that,
I
gotta
drop
around
9
35-ish,
so
yeah.
Why
don't
I
walk
through
the
proposal
quickly
and
then
open
for
a
discussion?
Let's
see,
oh,
I
think
you.
If
you
want
me
to
present,
I
think
you
need
to.
F
Can
you
hear
me:
okay,
okay,
when
I
shared
my
screen,
it
turned
off
my
mic.
Can
you
see
the
presentation
or
the
the
document
there?
Okay,
great?
Yes,
thanks
yeah!
F
So
before
I
go
into
what
this
is,
maybe
just
a
bit
of
motivation
or
background,
so
the
the
security
response
committee-
for
I
don't
know
five
years
or
so
now
has
had
a
disclosure
process
where
kubernetes
distributors
can
sign
up
to
be
on
our
pre
kind
of
like
pre-announcement
embargoed
security
disclosure
list,
and
so
before.
We
release
a
vulnerability
to
the
public,
usually,
ideally
about
a
month
before
that,
but
the
timeline
varies
a
bit.
F
We
try
to
send
out
the
details
to
the
distributor
list,
which
includes
something
that
looks
pretty
close
to
what
we
ultimately
send
out
to
kubernetes
security
announce.
So
that
includes
the
actual
patches
to
fix
it,
the
details
of
the
vulnerability
etc.
F
And
the
goal
of
this
is
that,
when
that
announcement
goes
public,
that
all
kubernetes
users
are
able
to,
in
theory,
patch
pretty
close
to
that
date,
and
since
there's
this
kind
of
sort
of
two-layer
thing
that
has
to
happen
when
you're
using
a
distributor's
version
of
kubernetes,
that
first,
the
distributor
has
to
make
the
patch
available.
And
then
you
can
upgrade
your
cluster.
F
That's
part
of
the
motivation
for
releasing
this
to
distributors
early
another
part
of
it
is
it's
just
to
be
frank
and
the
easier
subset
of
all
users
that
we
can
coordinate
with
without
needing
to
draw
some
more
arbitrary
lines.
So
that's
kind
of
how
that
process
originated,
but
there's
there's
lots
of
companies
apple
being
one
of
them.
F
That
would
like
to
have
access
to
early
disclosures
as
well
to
help
plan
better
for
security
releases,
and
we've
taken
a
pretty
hard
line
on
this,
that,
if
you're,
not
a
distributor,
if
you
don't
meet
the
criteria
outlined
on
that
list
or
the
I
can
drop
a
link
later
or
maybe
micah.
If
you
want
to
grab
it
and
drop
it
in
chat
yeah.
So
if
you
don't
meet
the
criteria
for
that,
we've
taken
a
pretty
hard
line
on
not
letting
additional
companies
into
that
distributors
list.
F
So
that's
kind
of
the
background
for
this,
and
we
were
thinking
about
what
can
we
do
for
companies
that
don't
meet
the
criteria
for
the
distributors
list
or
end
users
or
individuals
to
help
you
better
prepare
for
a
security
vulnerability?
That's
coming
thanks,
micah
the
the
criteria
for
being
on
the
distributors
list
and
a
little
more
about
that
process
is
in
the
chat.
If
you
want
to
check
it
out.
F
So
if
I
skip
down
to
the
goals,
the
the
two
goals
that
I've
thought
of
for
this
are
one
to
give
non-distributors
or
the
general
public
advanced
warning
as
to
when
they
can
expect
a
vulnerability,
and
this
is
so
that
you
don't
have
to
always
be
like
I
don't
know
you
don't
have
to
set
up
alerts
or
pages
for
when
a
vulnerability
is
dropped.
You
can
kind
of
expect
it.
Okay,
I
should
clear
my
calendar
for
tuesday
I
should
watch
my
email.
F
This
vulnerability
is
going
to
drop
and
we
want
to
be
ready
for
it
and
then
the
second
goal
is
around
also
advanced
planning
but
being
able
to
better
adjust
release
schedules
and
plans.
So,
for
instance,
if
you
usually
roll
out
your
upgrade
your
cluster
upgrades
on
monday,
maybe
this
week
you
say
well
we're
going
to
hold
that
upgrade
process
and
not
start
it
until
tuesday,
when
we
can
grab
this
new
security
release
or
if
you
have
some
upgrades
in
process
or
some
cluster
sku.
F
Maybe
you
want
to
try
and
clean
things
up
before
then,
so
those
were
the
two
kind
of
motivating
goals
that
I
thought
of,
but
if
anyone
thinks
that
this
would
be
useful.
For
other
reasons,
I'd
really
like
to
hear
how
you
might
how
you
might
use
this.
Some
of
the
pushback
I've
gotten
actually
through
some
side
channels,
is
questioning
whether
having
an
announcement
like
this
that
doesn't
actually
isn't
actually
actionable.
It
doesn't
tell
you
how
to
mitigate
it
or
anything
like
that,
whether
that's
actually
useful.
B
I
mean
I
I've
as
an
attacker.
If
I
get
a
message
like
this,
I'm
immediately
going
to
start
poking
at
the
kuba
api
server
to
see
what
takes
out
of
it,
and
I
don't
know
that
that's
an
argument
not
to
do
it,
but
it
didn't
get
mentioned
already.
So,
like
you
know,
fyi,
this
will
totally
be
just
like
ian
catnip
for
the
week
or
so
duration.
Before
the
thing
gets
patched.
F
Yeah
definitely
so
we
we
were
thinking
about
that
and
that's
part
of
the
motivation
for
saying
that
we
will
strictly
only
do
this
if
we're
following
the
private
release
process,
so
sometimes
usually
for
medium
and
low
vulnerabilities,
but
sometimes
also
for
high
vulnerabilities.
If
we
can
get
away
with
it
rather
than
going
for
like
a
dedicated,
fully
dedicated
security
release
through
our
private
infrastructure,
which,
frankly,
is
a
pain
to
do
because
all
of
kubernetes
development
is
done
in
the
public,
and
so
it's
a
lot
easier
to
do
things
on
the
public
infrastructure.
F
What
we
do
is
we
will
release
the
patch
in
public
and
basically
try
not
to
draw
any
attention
to
the
fact
that
it's
a
security
patch
and
then
come
release
day.
We
release
the
full
cve
details,
and
this
is
a
pretty
clear
example
of
where,
if
we
said
that
hey
there's
a
security
patch
coming
on
this
date
like
okay.
Well
now
you
can
go
come
through
the
commit
logs
and
see
which
one
of
these
looks
like
it's
fixing
a
critical
security
vulnerability.
F
So
yeah,
that's
the
other
piece
of
this
is
kind
of
in
conjunction
with
that.
The
fact
that
we
would
have
to
go
through
this
private
process
for
this,
we
would
probably
reserve
this
for
critical
or
maybe
the
more
severe
end
of
high
vulnerabilities.
B
Fair
enough
again,
this
is
not
an
argument
not
to
do
it
like
like
but
like.
If,
if
this
is
reserved
for
the
most
severe
oda
vulnerabilities
is
well
we're
only
going
to
give
people
the
opportunity
to
pour
through
the
commit
logs
in
order
to
find
the
most
severe
like
critical
vulnerabilities
is
that
is
that
an
argument.
A
I
think
I
think
part
of
I
I
think
part
of
that
discussion
was
that
this
would
be
used
in
the
cases
where
the
private
development
model
is
used,
and
so
you
wouldn't
be
able
to
comb
through
the
commit
logs.
Unless
you
were
one
of
the
you
know,
small
number
of
folks
that
have
access
to
the
private
copies
of
the
repos
that
are
used
in
that
process.
B
A
A
F
A
F
F
F
This
desire
to
not
like
cue
in
the
attackers
to
this
oh
day
is
kind
of
one
of
the
top
things
that
we're
thinking
about
there
and
so
we're
trying
to
balance
like
how
much
information
can
we
provide
to
make
this
more
useful
like
knowing
whether
you're
going
to
have
to
patch
your
nodes
or
your
api
server,
is
pretty
useful.
I
think,
but
also
gives
a
little
bit
more
information
for
an
attacker
of
like
which
component
the
vulnerability
lies
in.
O
Hello,
so
is
there
a
possibility
for
if
such
a
program
comes
in
place,
to
have
some
form
of
administrative
control
like
like
an
nda
where,
like
even
if,
there's
no
significant
penalty,
we
can
put
on
a
particular
group
just
making
it
very
clear
what
the
responsibilities
are
and
getting
that
alignment
with
these
organizations,
I
think,
would
go
a
long
way
towards
towards
helping
prevent
the
spread
of
the
of
the
information
before
it's
supposed
to
be
announced.
F
Yes,
we
do
have
that
for
our
distributors
list,
there's
an
embargo
agreement
that
everyone
has
to
agree
to
and
abide
by,
that
you
can
see
in
that
link
in
chat
for
this
pre-announcement.
This
wouldn't
be
a
private
list.
This
would
be
a
public.
F
You
know
out
on
the
public
internet
kind
of
announcement,
so
I
don't
think
there's
anything
that
we
could
realistically
put
there
and
frankly,
even
if
we
made
it
a
kind
of
a
private
but
open
list.
I
think
at
that
point,
so
many
people
have
access
to
it
that
it.
K
I
see
the
structure
and
I
agree
and
and
also
from
the
like
kubernetes
organization
side.
I
don't
I
don't
know
who
or
who
could
science
co-sign
an
nda
on
kubernetes,
because
it's
a
open
source
project.
O
The
linux
foundation
easily
could,
but
it
doesn't
sound
like
the
structure,
would
work
here
anyway.
A
I
think
this
is.
I
think
this
is
an
interesting
attempt
to
balance
a
lot
of
different
concerns,
like
I'm
kind
of
feeling
this
as
being
sort
of
similar
to
the
administrative
policy
that
microsoft
patches
come
on
patch
tuesday,
like
I
know
folks
who
are
who
are
living
and
breathing
windows,
they
don't
know.
A
We're
not
putting
out
those
severity
of
patches
with
that
kind
of
frequency
to
where,
like
it's,
the
monthly
kubernetes
security
patch
release
plan
would
make
sense,
but
this
this
feels
kind
of
conceptually
similar
to
that,
except
for
the
fact
that
it
like
with
with
allowances
for
the
fact
that
it's
sporadic
like
this
thing
that
doesn't
happen
very
often
just
to
let
you
know
we're
gonna.
Do
it
is
that
is
that
kind
of
the
feeling
that
I
should
be
getting
off
of
this
proposal.
Tim.
F
Yeah
and
you
set
an
important
point
there,
which
is
that
we
don't
expect
this
to
be
very
frequent.
I
mean
I
think
I
can't
even
remember
the
last
critical
vulnerability
that
we
did
in
kubernetes.
I
expect
this
process
to
be
invoked,
maybe
on
average
about
once
a
year,
maybe
twice.
B
Although
it's
hard
to
say,
I
would
imagine,
you
know
like
that,
past
patterns
are
always
going
to
hold
for
future
patterns.
I
mean
you
know,
like
you,
have
more
of
an
embargo
idea
than
I
do,
but
you
know
for
all
we
know
five
critical
vulnerabilities
will
all
drop
at
the
same
time
in
a
month.
You
know
yeah,
of
course,
yeah
go
ahead.
F
Yeah
we
wouldn't
we
wouldn't
want
to
like,
say
that
we
will
only
do
this
once
a
year
or
or
make
that
a
hard
requirement,
or
anything
like
that.
I
just
like
kind
of
based
on
past
patterns.
That's
the
kind
of
expectation.
F
A
F
F
F
The
date
and
time
of
the
expected
release
expected
being
the
key
word
here
that,
for
various
reasons,
these
things
sometimes
slip,
but
just
to
help
with
planning
there
and
then
the
other
details
would
probably
vary
a
bit
depending
on
exactly
what
the
vulnerability
was
and
would
be
sort
of
a
judgment
call
on
the
part
of
the
src,
but
certainly
patched
versions
and
what
those
versions
are
based
off
of.
So
typically
it
would
be.
F
F
I
think
we've
done
it
once
or
twice
in
the
past
when
there
was
a
significant
refactor
in
the
code
that
was
being
patched,
although
that
I
can't
remember
why
we
did
it
that
rarely
happens
in
a
in
a
patch
release
version,
but
I
think
we
have
occasionally
gotten
it
like
merge,
conflict
and
decided
to
include
the
pat
the
base
patch
in
there.
F
But
probably
probably
we
wouldn't
do
that
a
whole
lot.
If
ever
and
then
I
added
in
this,
are
there
alternative
mitigations?
F
We
wouldn't
say
what
the
mitigations
are,
since
that
would
almost
always
point
directly
at
the
vulnerability,
but
I
think
knowing
whether
you
need
to
expect
to
patch
on
the
release
day
or
if
there's
like
you
know,
can
you
tune
your
r
back
and
mitigate
this
kind
of
thing?
In
other
words,
is
there
is
there
a
mitigation-
and
I
guess
a
non-disruptive
mitigation
that
you
can
do
without
a
full
cluster
upgrade
would
be
a
nice
thing
to
know.
A
I'll
just
put
on
my
like
internal
platform
team
at
a
large
end
user
hat
and
say
that
you
know
knowing
knowing
whether
there
is
likely
to
be
a
non-disruptive
mitigation
or
whether
it
is
get
ready
to
apply
patches
outside
of
the
normal
cadence,
on
which
you
would
apply
patches
like
that
feels.
Like
most
big
end.
Users
will
appreciate
like
that,
as
a
as
a
binary
bit
of
information.
B
As
a
binary
bit
of
information,
I
think
that
that
does
a
good
job
of
striking
a
balance
between
just
letting
people
know
whether
or
not
to
expect
something.
Disruptive
like
debbie,
said
or-
and
it
also
like
you
know,
makes
it
a
little
bit
less
enumerative
for
attackers
who
are
trying
to
take
a
look
at
it.
C
Another
point
in
favor
of
this
that
is
worth
maybe
adding
in
the
motivation,
is
many
big
end.
Users
typically
have
very
stringent
change,
requests
or
process
where
they
have
to
get
everyone
together
and
then
sometimes
they
have
free
spirits
where
changes
are
blocked.
C
Whether
that's
a
good
idea
in
general
is
debatable,
but
people
still
do
that
who
use
kubernetes
so
for
those
people
who
need
a
lot
of
legwork
before
anything
goes
into
production
for
them.
This
will
be
really
helpful
because
they
can
get
all
their
ducks
in
one
row
and
once
the
patch
is
up,
they
can
fix
it
pretty
much
in
a
matter
of
a
day
or
two.
So
that
would
be
a
good
good
thing
to
add.
F
F
I
also
added
this
note
for
what
this
means
for
companies
that
are
already
on
this
distributors
list
and
have
access
to
the
full
vulnerability
details,
and
so
I
think
distributors
should
be
able
to
republish
the
announcement
on
their
own.
However,
they
communicate
with
their
customers.
F
I
said
that
distributors
can
include
their
own
patch
release
timelines.
So
if
a
distributor
knows
that
they'll
be
able
to
make
patch
releases
available
on
the
day
of
on
the
day
of
the
release,
then
they
can
say
so
or
if
you
know
patches
will
be
available
two
days
later,
they
can
give
their
customers
a
heads
up
similar
to
the
our
mitigations
available.
F
Distributors
can
say:
have
this
binary
kind
of
point
of
is
user
action
to
be
required?
So
will
the
clusters
be
automatically
upgraded?
Will
they
be
automatically
mitigated?
F
They
can
say
that
what
they
cannot
say
is
if
those
mitigations
were
applied
behind
the
scenes
before
pat
the
public
disclosure
date
or
if
the
platform
is
unaffected
and
again
that's
to
minimize
the
chance
of
oops.
I
lost
my
that's
to
mitigate
the
chance
of
release
or
sorry
leaking
the
details
on
that.
F
So
that's.
The
overall
of
the
proposal
definitely
would
love
to
hear
more
feedback
and
again,
especially
anyone
who
thinks
that
this
would
be
useful.
I'd,
be
especially
interested
in
hearing
kind
of
why
or
how
useful.
A
A
F
But
yeah,
if
those
get
out
of
hand,
then
maybe.
F
Kick
off
an
email
thread
to
the
maybe
kubernetes
security
discuss
or
whatever.
That
group
is
just
to
kind
of
collect
a
little
more
feedback,
asynchronously.
A
And
you'll
get
a
you'll
get
a
couple
of
different
you'll
get
a
couple
of
different
audiences
there,
which,
from
a
casting
a
wide
net
perspective,
is,
is
good.
F
Yeah
in
terms
of
next
steps,
I
think
I'll
continue
to
gather
feedback
over
the
next
week
and
then
the
the
security
response
committee
has
a
one-off
meeting
scheduled
for
next
thursday
and
so
I'll
add
this
to
our
agenda.
And
if
everyone
in
that
group
agrees,
we'll
put
it
into
effect.
A
B
Is
this
a
proposal
that,
like
is
like,
has
an
rfc
that,
like
goes
into
effect
at
some
point
after
a
certain
comment
period?
Is
it
something
that
somebody
is
voting
on
somewhere
like
how
does
this
work
as
a
proposal
process.
F
F
A
In
a
in
a
in
a
really
in
a
really
real
way,
right
now
from
a
governance
perspective,
I
don't
think
that
there's
anything
that
that
binds
the
src
to
to
do
anything
other
than
what
it
as
a
body
believes,
is
in
the
best
interest
of
kubernetes,
but
recognizing
that
we
are
just
people
who
have
thoughts
and
that
we
can
get
much
better
thoughts
by
making
sure
that
we
talk
about
them
with
other
folks
who
have
interest
and
their
own
ideas
like
bringing
them
here
and
then
really
real
talk.
A
What
I
think
will
happen
is
that
at
the
src
meeting
we
will
argue
it
out
until
we
find
consensus
on
on
the
feedback
that
we
get
from
this,
and
so,
if
it's,
if
it's
quite
clear,
if
it's
easy
to,
if
it's
easy
to
arrive
at
the
conclusion
that
it's
the
best
way
forward
for
kubernetes,
then
then
that
may
be
really
easy.
A
Right,
let's
jump
back
up
to
the
top
and
share
what's
going
on
with
subgroups.
Thank
you
so
much
tim
for
for
bringing
that
here.
I
think
it's
a
really.
I
think
it's
an
interesting
thing
to
it's
an
interesting
thing
to
talk
about,
and
I'm
glad
that
I'm
glad
that
we
have
that
we
have
this
group
to
share
it
with.
B
A
Nah
I
mean
this
is
yeah
yeah.
So
thanks
a
lot
audit
subgroup.
I
will.
I
will
report
news
from
audit
subgroup.
Ray
is
not
able
to
make
it,
but
after
after
extensive
contracting,
the
vendor
announcement
from
the
kubernetes
third-party
security
audit
request
for
proposal
process
has
been
made.
It
is
linked
in
the
it's
linked
in
the
notes
here.
P
Not
a
question,
I
just
thought
I
would
say
hello,
I'm
the
head
of
the
containerization
orchestration
practice
at
mcc,
so
I
will
probably
be
involved
in
some
capacity.
I
suspect
I
just
thought
I'd,
say
hi
and
say
that
I
will
be
at
least
in
some
way
involved
in
the
audit
hi.
A
L
Yeah
we
kick
started
the
mini
project,
which
it's
been
very
interesting.
It's
we
have
been
wanting
to
add
a
kubernetes
security
checklist
to
the
website.
There
are
many
adding
background
contacts
to
folks
who
are
new
to
the
call.
There
are
many
securities
checklists
available
all
over
the
internet.
You
can
find
a
lot
of
them
for
kubernetes,
but
we
wanted
to
have
something
that
comes
from
the
project
itself.
L
So
that
is
the
background
idea
for
this
task
and
you
can
go
to
the
tracking
issue
and
you
can
see
a
lot
of
buckets
and
if
you
want
to
add
anything
to
the
list,
please
feel
free
to
comment
and
we
are.
We
already
have
like
three
contributors
thanks
to
them.
Sorry,
I
don't
remember
the
name
and
they
have
been.
They
have
volunteered
to
take
up
few
sections.
L
L
So
that's
where
it
is
for
now,
and
the
second
thing
is
that
I
wanted
to
bring
into
attention
that
there
is
this
issue
that
mahi,
I
think
I
got
his
name
right,
I'm
so
sorry.
L
If
I
haven't
brought
up
in
the
last
six
security,
documentations
or
project
meeting,
he
has
been
working
on
adding
annotations
related
to
part
security,
and
he
has
created
this
pr
and
it
is
waiting
on
sick
odds
review
and
if
security
folks
want
to
take
a
look
at
it
at
your
thoughts
and
comments,
I
think
they'll
be
very
well
appreciated.
A
Thank
you
for
thank
you
for
sharing
both
of
those
with
us.
I
know
I'll
be
going
and
looking
at
that
pr
for
the
for
the
documentation
for
those
for
those
labels
tooling.
What's
going
on
what's
what's
happening
in
the
world
of
tooling.
C
Yes,
all
right,
so
couple
of
big
updates.
This
time
folks
who've
been
joining
the
meeting
meetings
for
a
while
know
that
we've
been
working
on
a
small
sort
of
implementation
to
create
a
auto
refreshing
list
of
fixed
official
kubernetes
src
cves,
and
we
did
a
lot
of
pre-work
neha
in
the
tooling
group.
Did
bunch
of
that,
and
now
we
are
in
a
process
where
we
want
to
have
that
on
website
kubernetes
website
and
as
part
of
doing
that,
we
realized.
C
There
were
a
couple
of
good
designs
that
we
couldn't
use
to
implement
it,
and
we
wanted
to
just
use
our
existing
cap
process
to
get
feedback
for
it.
So
we
wrote
up
a
cap
there
it's
available
for
review.
I
see
some
folks
already
started
adding
comments,
including
tapi,
so
thank
you
and
anyone
else
who
wants
to
look
at
it.
Ask
and
the
reviews
can
also
be
asking
questions
which
will
help
everyone
else
as
well.
So
take
a
look
at
that,
especially
folks
from
src
have
given
feedback
in
the
past
on
this
anymore.
C
Feedback
is
welcome,
and
I
think
we'll
maybe
keep
this
open
for
a
couple
of
weeks
or
so
tabby
before
we
can
mark
it
as
implementable
and
then
kind
of
go
from
there,
yeah,
okay,
all
right
yeah.
So
let
me
know
if
you
have
any
questions
there
and
the
second
update
I
wanted
to
give
it
together
with
pirko,
so
sasha
purcove,
carlos
and
mark
marco.
C
If
I
pronounced
it
right
and
a
few
navajo
and
few
others
in
sick
release
have
been
working
on
an
mvp
to
sign
all
the
kubernetes
release,
images
using
course,
keyless
co-signing
cosign
tool,
and
we
are
very
close
to
having
that
done
or
very
close
to
having
that
work
working
end
to
end.
So
I
was
lucky
enough
to
work
with
them
this
week
to
implement
the
verification
part
for
images,
and
it
was
great
fun
when
collaborations
across
things
happen,
so
definitely
encourage
everyone
who
haven't
worked
with
them.
C
Please
do
they
are
great
bunch
of
folks,
and
I
also
want
to
pause
for
purchase
and
others
who,
from
sig
release,
to
talk
more
about
this
that
I
may
not
know
about.
G
Yeah
yeah
thank
you,
pj
and
thank
you
especially
for
jumping
in
and
handling
some
of
that
it's
always
fun
to
build
things,
but
even
fun
and
funnier
funner
to
do
it
with
with
lots
of
friends
like
thank
you
so.
G
Exactly
we've
been
planning
this
for
a
long
time
now
and
finally,
all
some
of
the
tools
in
the
both
on
six
store
and
on
our
side
have
reached
a
maturity
where
we
can
start
to
see
the
implementation
happening.
G
So
when
you,
when
we
release,
I'm
gonna,
give
like
a
two
sentence
overview
of
how
we
do
the
release
processes
in
kubernetes.
So
we
there
are
two
main
stages
where
we
first
build
all
the
artifacts
container
images
and
the
binaries
and
all
of
that
and
we
staged
those
first
in
a
staging
registry
and
in
a
in
a
staging
bucket
and
once
we
run
the
wheels
and
verify
that
everything
is
correctly
done.
We
publish
the
artifacts
to
their
final
destinations.
G
This
is
the
the
binaries,
for
example,
go
to
a
staging
to
the
release
bucket,
where
usually
tools
like
cube,
adm
and
things
like
that-
will
pull
them
down
to
for
using
them
and
to
the
final
gcr
registries
that
were
that
store
the
usual
kubernetes
images.
G
G
That
is
a
program
that
you
file,
a
pr
and
the
stakeholders
give
their
okay
to
the
to
the
promotion
and
then
the
the
once
the
pr
merges
the
promoter
will
go
in
and
basically
copy
all
the
images
from
the
staging
registry
to
the
final
public
registry
right
and
then
what
we're
going
to
do
there
is
we,
during
staging
we're,
going
to
store
this?
The
images
signed
then,
before
releasing
we're
going
to
check
the
the
the
signatures.
G
And
for
this
we
had
to
implement
a
signing
library
which
wraps
all
of
the
c
store
and
cosine
functionality,
which
is
what
pg
has
been
working
on
to
enable
the
verification
on
that
part
of
the
library.
We
do
this
because
we
want
to
to
shield
our
apis
from
any
changes
on
the
side
of
the
of
sixer,
because
it's
moving
really
rapidly
and
then
so
that
one
is
almost
ready.
I
think
all
of
the
pieces
are
ready
or
almost
ready
just
to
merge
away.
G
I
think,
and
then
we
have
to
start
building
those
into
the
actual
release
tooling,
and
this
is
where
we
are
right
now.
So,
there's
a
big
change
coming
to
the
image
promoter
right,
it's
right
now
in
in
review
and
also
on
grail,
which
is
the
the
tool
that
builds
and
runs
all
the
other
builds
and
publishing
of
the
stitching
artifacts.
So
we're
pretty
close,
I'm
trying
to
see
if
we
can
get
at
least
part
of
this
working
on
the
next
124
pre-release,
which
is
scheduled
for
tuesday.
G
We
still
have
to
work.
Some
parts
of
the
of
the
infrastructure
with
seed
gets
infra,
but
it's
looking
pretty
good
and
I
am
I'm
fairly
confident
that
we
will
be
able
to
to
do
at
least
at
least
signing
the
the
the
staging
artifacts,
I'm
very
confident
that
we'll
be
able
to
do
it.
G
B
A
G
Yeah
and
oh,
and
if
someone
also
catches
to
to
watch
this
on
the
recording
or
are
you
involved
with
one
of
the
smaller
projects,
be
sure
to
approach
us
because
we
are
going
to
be
working
with?
Also,
for
example,
live
I'm
talking
with
the
folks
that
are
driving
the
ingress
engine
x
project
and
they
are
going
to
be
revamping
and
pioneering
as
well,
releasing
their
things
and
signing
them.
G
We,
we
are
currently
hard
at
work
with
some
of
the
folks
from
six
store
to
enable
the
kubernetes
wide
delegation
of
trust
that
will
come
from
six
store
and
then
to
a
kubernetes
delegation
and
then
from
then
we're
going
to
be
issuing
a
keys
for
folks
to
sign
their
projects
with
which
can
be
validated
all
the
way
up
to
the
seek
to
the
to
the
six-star
route,
and
that
is
still
in
progress,
but
in
the
meanwhile,
while
that
is
finished,
we
can
find
ways
to
start
securing
the
releases
and
having
all
of
the
all
of
the
features
that
we've
been
working
on
for
the
past
one
or
two
years.
A
C
For
anyone
who
is
big
on
golang
and
unit
testing,
I
would
also
encourage
them
to
look
at
some
of
the
prs,
because
for
me
it
was
a
great
experience.
Looking
at
how
the
mocking
is
done
for
unit
testing
the
it's
some
there
is
a
tool
I
think
called
counterfeiter.
That's
used,
that's
basically
mocking
the
structs
and
the
objects
in
release
sdk
and
then
it
auto
creates
the
mocks,
as
you
change
the
struct
definition.
So
that
was
very
cool
to
see.
C
All
right,
I
can
go
next
for
the
self-assessment,
but
basically
nothing
much
in
terms
of
new
updates,
similar
like
last
time,
still
working
on
the
updates
to
the
assessment
dock.
Hopefully
we'll
get
a
pr
soon,
next
time,
when
we
meet.
A
A
All
right,
so
we
are,
we
are
at
the
end
of
the
things
that
we
have
planned
to
discuss.
This
is
this
is
our
space.
This
is
our
space
for
us
to
to
share
our
our
thoughts
and
our
concerns
and
to
learn
from
each
other
and
to
find
out
who
else?
Who
else
has
shared
thoughts
and
concerns?
Does
anybody
have
anything
that
they
would
like
to
to
bring
up?
Now
that
we've
reached
the
end
of
of
the
planned
discussion
points.
Q
I'll
just
mention
that,
like
a
really
quick
thing,
just
because
we
were
talking
about
cosine
today,
I
had
cause
to
be
playing
with
github
actions
recently,
and
I
realized
that
in
if
you
have
the
publish,
docker
image,
github
action,
it
automatically
adds
cosigning,
which
I
thought
was
super
neat.
So
you
can
use
github
actions
and
it
is
like
super
simple.
Literally
click.
Q
Add
this
github
action
for
publish
docker
image
and
you
get
a
co-signed
image
out
and
like
no
more
additional
input
required
from
user,
which
I
thought
was
a
really
nice
compared
to
how
signing
has
traditionally
been
seen
as
like
hard
to
use
and
hard
to
manage
and
key
management
and
all
that
nonsense.
It
just
worked
one
of
those
nice
experiences
in
computing.
A
All
right,
if
that
is
if
that
is
that,
then
that
means
that
we
have
come
to
the
end
of
the
meeting.
Thank
you
all
so
much
for
coming
for
making
this
space
together
and
for
starting
to
answer
some
of
these
questions
that
that
help
us
to
push
kubernetes
security
forward,
I'm
so
glad
to
have
been
able
to
be
here
with
all
of
you,
and
I
look
forward
to
seeing
you
later
bye.