►
From YouTube: Kubernetes Release Engineering Meeting for 20220301
Description
Kubernetes Release Engineering Meeting for 20220301
A
We
have
two
topics
in
the
agenda:
they're
not
in
the
agenda
right
now,
but
I
would
like
to
share
them
with
you
and
and
if
anyone
else
has
any
any
other
topics
to
add
to
today's
meeting
feel
free
to
add
it
in
the
in
the
agenda
which
I'm
updating
right
now.
As
a
reminder,
this
meeting
is
governed
by
the
kubernetes
sort
of
conduct
and
it's
going
to
be
now
which
basically
boils
down
to
be
awesome
to
each
other.
A
A
A
A
A
So,
okay,
now
moving
on
to
the
to
the
first
thing
I
wanted
to
share
with
all
of
you
is
we've
been
working
today.
Well,
as
of
last
week,
we
did
some
pretty
substantial
changes
to
the
container
image
promoter,
which
is
the
the
the
the
the
tool
that
copies
all
of
the
artifacts
from
staging
to
the
production
registries.
A
So
last
week
we
had
several
refactors.
Some
of
them
are
still
appears
in
flight,
but
the
idea
is
that
to
lower
the
some
of
the
complexity
in
the
in
the
in
the
promoter,
there
were
several
code
reorganizations,
one
of
the
one
of
the
changes
involved
in
involved,
adding
support
for
local
registered
credentials.
So
previously
you
had
to
to
use
the
account
keys
that
that
the
promoter
used
to
to
use
as
identity.
But
now
it
will
read
your
local
docker
register
credentials.
So
you
can.
A
This
means
that
you
can
more
easily
run
the
promoter
in
your
local
machine,
which
has
speed
up
the
development
and
improvements
substantially,
because
you
can
now
run
the
promoter
on
your
machine,
set
up
two
test
registries
and
start
promoting
things
locally,
and
so
that
that
that's
the
first
one
I
wanted
to
share.
I
don't
know
if
there
are
any
questions
around
that
effort
or.
A
A
The
I
and
the
the
designer
libraries
will
use
that
token
to
do
the
the
to
do
to
request
the
keys
and
to
sign
the
images
and
record
into
the
transparent
to
603
the
transparency
log,
the
the
the
identity
and
the
operation
that
we
just
did.
So
you
can,
in
the
future,
go
back
to
the
transparency
log
and
check
that
the
signature
took
place.
A
Who
did
it
and
all
of
that,
and
so
in
gcp,
whenever
you
want
to
generate
identity
tokens,
you
have
to
impersonate
a
service
account,
so
you
have
to
run
your
credentials,
impersonate
the
accounts
and
generated
so
the
identity.
Token,
and
then
use
that
so
we've
been
thinking
about
ways
to
to
how
to
structure
how
to
structure,
especially
concerning
security
and
access
to
the
designer
accounts.
A
A
We
have
three
scenarios
where,
where
we
will
be
signing
things,
one
is
the
public
images
that
happen
during
image
promotion.
Those
signatures
will
be
the
signatures
that
will
get
eventually
to
downstream
users,
and
those
are
the
signatures
that
that
then
users
will
eventually
verify
to
ensure
images
are
haven't
been
tampered
with.
A
The
other
two
are
the
end-to-end
tests
of
the
image
promoter
and
the
other
one
is
the
staging
flow
when
we
what
the
staging
phase
of
the
release
process.
So
whenever
we
do
a
kubernetes
release,
we
build
everything,
the
stage
it
and
if
artifacts
look
good,
we
release
them
in
the
release
phase.
So
all
of
those
images
during
staging
are
going
to
be
signed
and
eventually
the
promoter
will
check
those
signatures
before
accepting
them
for
promotion.
A
So
the
first
one
I
would
like
to
to
talk
about
is
the
most
the
most
important
one,
which
is
the
impersonation
flow
that
happens
during
image.
Promotion-
I
don't
know
if
you
can
see,
I
I
think
I,
if
I
zoom
into
the,
if
I
zoom
into
the
the
graphic
it
doesn't
grow.
I
don't
know
if
it's,
if
you
can
read
it
or
or
it's
too
small,.
A
A
So
if
you
think
about
it,
you
run
the
promoter,
and
so
the
first,
the
first
one
is
the
promoter
stats,
and
it's
like
I
don't
know
kindly
pointed
out
to
me
last
week.
It
starts
in
a
pod
that
is
another
annotated
with
cloud
identity
and
that
takes
an
identity.
So
the
process
is
running
as
a
gcp
account.
A
So,
during
the
during
the
whole
image
promotion
process,
the
promoter
will
run
with
that
service
account
and
it
will
switch
to
various
identities
depending
on
the
thing
it
needs
to
do
so.
The
first
one
is
the
first
identity
that
comes
into
play
is
reading
the
source
registries.
So
the
promoter
is
going
to
take
images
from
a
source
registry
and
move
those
and
copy
those
to
one
or
more
destination
registries.
A
So
the
first
the
first
identity
needs
to
take
on
is
the
identity
that
it's
going
to
read
from
the
source
registries
generally.
Those
source
registries
are
open
in
public
and
read
and
read
only
for
everyone,
so
usually
there's
no
need
to
have
an
identity
there,
but
you
can.
You
can
specify
one
if
you're,
if
you're,
if
your
registry
is,
is
not
open
and
and
written
and
open
to
and
to
the
public
for
reading.
A
So
that's
the
first
one.
Then
the
second
identity
is
when
the
promoter
is
going
to
write
to
each
of
the
target
registries,
so
you
can
specify
one
identity
for
all
or
each
registry
can
have
its
own
so
that
those
are
the
first
two.
Those
are
important
because
the
promoter
will
shift
and
activate
saves
internally.
It
will
activate
service
accounts,
who
you
know,
gcp
service
accounts
to
do
the
the
container
reading
and
the
from
from
the
from
the
source
registries
and
then
activate
another
service
account
for
writing
to
the
registries.
A
So
our
current
proposal
in
this
issue
is
to
create
one
main
project
to
hold
all
of
the
things
that
have
to
do
with
signing
at
first.
It
will
only
contain
basically,
the
service
accounts
than
the
promoter
will
use
to
sign
things,
but,
depending
on
how
things
evolve
in
the
next
few
months,
and
mostly
depending
on
how
the
kubernetes
delegation
of
trust
from
six
or
ends
up
working,
we
may
have
to
use
the
kms
in
that
project
for
for
storing
keys.
A
A
A
Okay,
so
I'll
move
to
the
next
one,
okay,
the
next
one.
I
would
like
to
do
an
overview.
Okay,
maybe
just
briefly
going
on
the
on
the
impersonation
flow
of
the
of
the
image
promoter
end-to-end
tests.
This
is
simpler.
The
here
during
end-to-end
testing
the
promoter
uses
a
fixed
service
account
to
do
all
of
its
testing
it.
It
will
do
actual
promotions
of
artifacts
and
images
using
a
service
account
that
is
defined
in
a
json
key
file.
A
Htw
token,
that's
that's
stored
in
the
in
the
in
the
cluster
and
there
our
proposal
is
to
keep
using
that
and
simply
generate
another
dummy
service
account
to
use
for
identity
and
signing
during
the
test.
Now
this
is,
I
think,
trivial
and
not
much
controversy
or
debate
here
this
all
of
these
would
be
on
the
same
testing
project
and
and
there's
no
complexity
there
and
finally,
the
other
one
we
are
looking
at
here
is
the
impersonation
flow
during
the
staging
of
the
artifacts.
A
So,
once
again,
when
we
run
our
kubernetes
release,
we
build
everything
stage
the
artifacts
and
then
we
we
want
to
sign
those,
and
we
want
to
sign
them
because
before
releasing,
we
want
to
have
them
signed
so
that
the
promoter
can
actually
verify
the
signatures
that
staging
generated
and
if
they
check
then
allow
them
for
promotion
and
and
copy
them
to
the
registries.
By
the
way
this
verification
is
already
in
place.
A
So
if
we
were
to
cut
a
new
release
of
the
of
the
image
promoter
right
now
it
will,
it
will
check
for
signatures
in
every
image
that
gets
promoted.
If
it
doesn't
have
an
image.
If
it
doesn't
have
a
signature,
it
will
accept
it,
but
if
it
has
one
and
there's
a
problem
with
it,
it
will
reject
it
for
promotion.
So
that's
already
running
and
and
working
not
running,
because
we
haven't
made
a
new
version,
got
a
new
release
of
the
promoter.
A
Okay
and
then
so
in
this
case,
what
we
want
to
do
is
we
want
to
have.
We
need
to
have
a
service
account
that
the
also
all
of
the
kubernetes
image
promotion
runs
inside
of
cloud
build,
and
this
cloud
build
the
cloud
build
uses
a
file
service
account.
So
what
we
need
to
do
is
to
create
another
service
account
that
will
serve
as
identity
for
the
signatures
that
are
generated
during
staging,
and
we
need
to
add
permissions
for
the
cloud.
Build
service
accounts
to
generate
tokens
with
the
identity
of
designer
accounts.
A
A
It
doesn't
necessarily
have
to
be
part
of
the
bigger
topmost
kubernetes
identity,
because
if
you
were
to
see
it
in
a
more
tree-like
way,
there's
a
top-most,
kubernetes
identity,
and
this
could
be
like
a
project
of
of
release
engineering,
so
it
doesn't
have
to
be
part
of
that.
I
mean
we
can
store
the
story
there
if
there
are
other
needs,
but
we
don't
need
to
have
that
account
anywhere.
Really.
A
A
So
that's
the
basic
overview
of
the
of
the
flows
we
are
building.
There
are
pr
super
open
for
some
of
these
and
the
the
I.
I
would
like
to
hear
more
comments
about
the
establishing
the
signer
project
and
to
see
if
anyone
has
other
ideas.
That's
why
I
haven't
yet
opened-
or
I
don't
know
how
to
request
a
new
project
for
that,
but
I
still
haven't
started
on
that,
but
I
would
like
to
hear
if
others
have
any
other
project,
other
ideas
about
around
the
hosting
those
those
identity
accounts.
B
I
I
have
a
comment,
a
question.
I
will
start
with
my
comment.
The
first
comment
is:
we
should
stop
use
kubernetes
test
gcp
gcp
project
for
the
release
process,
because
it's
a
google
project,
not
a
community
owned
one,
and
we
did
some
change.
I
think
three
weeks
ago
about
fast
forward.
We
basically
decided
to
stop
using
that
project.
That's
that's.
My
first
comment.
B
A
B
A
B
A
A
But
right
now
the
goal
is
to
get
the
public
images.
Science,
that's
the
first
one
and
there's
at
the
same
time,
there's
the
the
designing
of
files
and
artifacts
and
blogs.
Also
going
on
this.
One
is
a
little
bit
more
behind,
but
work
is
going
on
and
it
will
be
basically
the
same
process.
So
you
have
your
artifacts
and
you
should.
Whenever
you
release
them,
you
will
run
them
through
the
to
the
promoter,
which
is
not
just
an
image
promoter.
A
It
also
promotes
files,
for
example,
the
ko
apps
kops
project
already
uses
that,
and
so,
whenever
you
publish
your
artifacts
via
the
promoter,
they're
going
to
get
a
signature
and
it's
going
to
be
stored
in
the
in
the
buckets
along
them
for
verification
proposed
purposes.
So
right
now
the
tool
we're
using,
which
is
cosine.
It
allows
you
to
verify
those
signatures.
A
Once
we
get
the
kubernetes
delegation
in
place
for
files
you're
going
to
have
to
specify
the
exact
delegation
that
you're
going
to
to
to
do,
for
which
you're
going
to
use.
So
whenever
you
you
verify
using
cosine
and
image,
for
example,
you
get
like
a
clear
path
of
the
block
that
you're
verifying,
so
you
get
a
domain
and
then
a
path
which
stuff
uses
to
calculate
the
the
the
the
trust
chain
all
the
way
up
to
the
to
the
full
to
your
roots.
That
gives
you
that
chain
of
trust.
A
When
you
have
like
a
an
artifact
that
you
downloaded
from
somewhere,
you
can
verify
that
signature
is
valid,
but
in
order
to
ensure
the
full
chain
of
trust
all
the
way
up
to
the
to
the
six
or
roots,
you
will
need
to
pass
a
flag
to
specify
the
kubernetes
delegation
that
you
do.
Basically,
you
have
to
tell
cosine
that
you're
using
the
kubernetes
validation
to
check
that
artifact,
but
it's
going
to
to
to
work
as
well.
A
A
That's
one
thing,
but
then,
in
order
to
to
to
give
you
a
little
bit
more
trust
us.
If
that
person
who
signed
the
artifact
is
allowed
to
sign,
said
artifacts,
you
have
to
go
all
the
way
up
to
the
to
the
trust
chain,
all
the
way
up
to
the
to
the
root
of
trust,
and
then
you
have
to
to
pass
the
the
the
actual
delegation
for
cosine
to
use.
A
I
don't
know
if
that's
that's
clear
or
maybe
frame
it
in
another
way
to
to
understand.
So
you
you,
you
get
your
signature
and
you
can
check
that
it's
valid,
so
the
signature
will
tell
you
if
the
lot
you're
looking
at
has
been
tampered
in,
any
way
that
that
that
will
allow
you,
but
but
the
chain
of
trust,
which
is
the
toughest
location
which
we
were
talking
about
last
friday.
A
A
People
from
one
project
are
not
going
to
be
able
to
sign
artifacts
from
another.
That's
the
point
of
the
of
the
tough
delegation,
so
you
may
you
may
sign
the
thing
and
you
may
produce
a
valid
signature
which
matches
a
block,
but
the
truth
of
the
root
of
the
chain
of
trust
will
not
be
completed
all
the
way
up
if
you're
not
allowed
or
designated
as
a
as
a
signer.
B
B
A
Cool
and
all
right
and
the
so
so
it's
okay
all
right.
So
I
wonder
I
know
if
there
are
any
any
other
concerns
about
around
the
the
infra
changes,
then
that
we're
moving
on
here.
Do
you
have
any
well
you
or
any
anybody
else,
any
other
comments
around
establishing
that
root
project
for
the
signatures
and
storing
keys
and
things
in
there.
B
I
want
to
be
cautious
about
this,
because
if
we
basically
set
up
the
gcp
project
for
sign
mutual
with
directly
going
production,
so
I
want,
I
think
I
think
we
should
start
have
it.
We
test
firstly
in
the
same
project
and
see
how
this
is
happening,
because
we
have
before
we
get
a
production
project
for
signature
during
the
image
promotion.
B
The
the
first
thing
we
should
be-
we
should
do
right
now
is
make
sure
we
can
basically
sign
the
image
in
the
station
project.
I
think
that's
the
first
thing
we
need
to
make
sure
in
station.
That's
the
first
thing
we
do
once
we
are
sure
we
basically
can
sign
and
possibly
verify
kls
container
images.
We
can
talk
about
promotion
and
basically
say:
okay,
we
are
ready
to
go
in
production
and
we
can
basically
do.
We
can
basically
promote
sign
image
during
the
release
process.
A
A
B
B
Exactly
because,
if
you
basically
sign
an
image
in
case
station
kubernetes
every
time,
the
every
time
you
do,
the
signature
you
impress
on
it,
it's
like
an
energy
project
and
once
you
do
the
promotion,
you
need
to
impress
on
it
another
project.
I
know
the
service
icon
in
a
different
project
for
promotion.
A
Exactly
yeah
and
these
signatures
will
be
carried
over
from
staging
to
release
and
then
after
promotion
they
will
still
be
available.
That's
the
idea,
but
but
yeah.
Definitely
we
can.
We
can
work
on
finishing
the
release
process
signing
part,
but
we
need
we
need.
We
need
the
permissions,
otherwise
it
will
break.
A
A
Okay,
so
any
any
other
questions
around
around
the
impersonation
flows
and
or
the
tough
delegation-
I'm
not
I'm,
not
a
tough
expert,
but
I've
been
to.
I
know
that
some
release
managers
jumped
into
the
into
the
tough
goal.
Last
week
I
probably
got
caught
in
not
knowing
what
the
effort
was
all
about,
but
I'm
too
happy
to
answer
my
using
my
limited
knowledge
of
stuff
or
how
we
plan
to
structure
that.
C
Yeah,
maybe
just
one
comment
for
clarification:
if
we
look
at
the
at
the
second
image
on
the
impersonation
flow
during
image
promotion,
then
then
it
mentions
that
we
sign
images
and
we
need
the
impersonation
for
that
on
designer
project.
Do
we
want
to
update
this
one?
I
mean
we.
We
were
thinking
about
copying
over
the
signatures
right
that
it's
more
clear
that
we
don't
actually
design
in
that
step,
but
we
copy
around
signatures.
A
C
A
Let's
go
over
that
again
really
quickly.
So
whenever
you
have
a
you,
have
a
service
account
which
will
serve
as
the
identity
of
the
signatures.
The
proposal
here
is
to
create
a
new
project
where
that
account
lives,
and
it's
there
that
account
should
have
permissions
specifically
token
creator.
Permissions
for
the
promoter
service
account
the
main
account
that
runs
the
promoter.
A
A
C
C
A
Yeah,
okay,
so
point
taken
on
that
and
and
I'll
do
the
shift
of
the
of
the
pull
request
or
not
to
the
to
the
other
project
and-
and
we
can
start
working
on
setting
during
staging.
So
the
the
good
thing
about
signing
things
during
staging
is
that
we
can
run
as
many
mock
releases
as
we
want
so
to
ensure
that
things
are
getting
inside
properly
and
maybe
have
some
some
images
to
work
with
and
test
the
promoter,
copying
the
signatures
and
everything.
A
B
For
that
so
I'm
trying
to-
and
the
question
is
how
we
do
that
and
where
are
the
signing
party
doing
valencia
or
do
we?
Can
we
do
that
online?
So
I'm
trying
to
basically
understand
how
we
can
generate
a
new
chippy
cheeky
who
is
sick,
our
teacher,
the
person
responsible
for
that
those
new
jpg
and
how
we
build
some
kind
of
web
of
trust
between
the
radius
manager.
B
A
Also
I've-
I
don't
know
if
you,
if
you
got
it
from
the
tough
talk
on
friday
there's
there
are
some
people
that
are
interesting
interested
in
extending
all
of
this
six
third
route
of
trust
chain
of
trust
into
the
signatures
in
the
packages
themselves.
There's
no
like
a
concrete
effort
right
now,
but
that
would
be
an
interesting
thing
to
to
keep
an
eye
on
as
well.
B
B
A
Yeah
yeah
I
mean
so
gem,
but
just
so
I
I
would.
I
would
say
that
considering
the
amount
looking
at
them
at
the
amount
of
work,
we
need
to
do
for
the
system
packages
in
the
kubernetes
empire,
just
to
having
our
our
own
distribution
and
roots
and
all
the
policy
applications,
and
all
that
and
seeing
how
some
of
the
projects
in
sixer
have
been
moving
probably
would
be
a
good
way
to
keep
under
consideration.