►
From YouTube: sig-auth Bi-Weekly Meeting for 20220014
Description
sig-auth Bi-Weekly Meeting for 20220014
B
C
D
No,
no!
That's
what
you
say.
This
looks
amazing.
It's
like
you're,
proposing
exactly
what
I
want
yeah
David,
that
the
oidc
one
and
the
multiple
authorization
web
hooks
seemed
like
it.
Yeah
touched
a
lot
of
similar
things
that
you
and
I
have
thought
about.
If
we
want
to,
if
you
want
to
take
one
and
I'll,
take
the
other,
that's
fine.
C
B
B
A
A
B
C
C
C
B
A
B
D
A
B
B
Okay,
so
let
me
introduce
this
and
then
I
can
try
to
answer.
I
saw
David
got
some
comments,
but
I
think
we
can
have
some
good
discussion,
but
the
the
gist
of
this
change
to
the
cap
is
that
it
proposes
adding
a
kubernetes
rest
API
to
expose
some
amount
of
internal
opaque
State
about
each
API
server
into
their
kubernetes
API,
so
that
you
could
write
a
controller
to
drive,
rotation
and
and
sort
of
outlines.
B
I
just
need
to
tell
it
to
do
it,
but
I
think
that's
an
appropriate
use
of
the
storage
version
migrator
anyway,
but
sort
of
just
is
it's
a
basically
a
status
only
API
there
would
be
one
per
one
instance
of
the
resource
per
API
server
and
it
basically
contains
a
set
of
hashes
that
if
they're
equal,
you
know
everything
is
the
same.
If
they're
not
equal,
then
you
know
it's
not
the
same.
C
B
Right
so
maybe
I
need
to
pick
a
better
name
for
that
field,
but
so
the
way
that
the
right
key
is
populated
is
given
a
particular
group
resource.
We
know
we
have
a
set
of
Transformers
for
it,
and
this
API
only
really
covers
KMS
V2,
because
it
does
assume
that
Cam
sv1
and
the
other
approaches
are
just
basically
covered
by
the
encryption
config
hash,
because
they're
sort
of
static,
but
so
the
status,
API
and
KMS
V2
will
tell
you
what
key
a
KMS
plugin
is
currently
believing
it's
going
to
use.
B
So
if
you
have
more
than
one
KMS
V2
plugins,
the
read
keys
are
the
ones
that
those
plugins
are
attempting
to
use,
so
maybe
I,
don't
maybe
weak
key
is
the
wrong
name
for
that.
But
so
the
the
right
key
is
for
a
given
resource
for
the
index:
zero
Transformer.
If
it's
KMS
V2,
what
is
what
is
it?
The
key
ID
that
you
last
Saw
by
looking
at
status?
Okay,.
C
C
A
B
So
read
key
is
the
right
keys
of
any
other
KMS
plugins
right,
if
you
told
them
to
encrypt
it's
just
that,
we
would
never
ask
them
to
it's
mostly
what
they
are
emitting
in
their
status.
Api
thinking
about
it
more
I'm
wondering
if
I
could
just
drop
the
field
altogether.
Maybe
I
just
don't
need
that
information
as
part
of
storage,
migration.
D
B
C
B
Yeah
so
one
of
the
changes
I'm
working
on
right
now
is
today
the
KMS
Transformer
eat
both
the
V2
and
the
V1.
They
cannot
detect
staleness
from
the
data
they're
reading
from
etcd.
So
one
of
the
things
that
that's
going
to
wire
up
is
the
ability
for
that
code
to
know
like
what
the
last
status
key
ID
was.
So
that
way,
when
it
decodes
data
off
of
disk,
it
can
be
like.
Oh
this
one
I
have
to
use
key
one
with,
but
I'm
supposed
to
be
using
key
2
now.
So
this
is
stale.
B
Basically
you
don't
want
to
run
storage
migration
until
your
system
is
all
caught
up
to
you,
but
you
can
observe
when
it
catches
up,
there's
no
harm
in
doing
it
earlier,
just
wasting
IO,
basically
so
I
I
guess
some
other.
Just
at
a
high
level
do
folks
think
it
is
good,
a
good
idea
to
make
an
entire
kubernetes
rest
API
for
this,
mostly
because
I
could
not
come
up
with
any
other
way
to
do
it,
but.
D
So
like
including
the
key
ID
for
the
current
key
ID
in
what
we
use
to
calculate
like
what
effects
storage
makes
sense,
we
have
storage
version
hash
in
Discovery
already.
Is
there
a
reason
we
couldn't
take
this
additional
information
like
the
key
ID
and
like
make
that
part
of
what
we
factor
in
choose
to
our
diversion
hash.
B
B
C
C
The
storage
version,
the
storage
version,
API
object,
which
was
its
replacement,
because
we
thought
that
we
could
do
a
better
job
with
it
would
still
be
open
to
completion.
But
there's
nobody
available
to
continue
working
on
it,
and
so
that's
the
one
that
has
a
an
object
for
each
for
each
Cube,
API
Group
resource
and
then
has
indications
about
the
storage
version,
encoding
version
and
conditions
on
it
per
API
server.
D
B
D
C
Right
C
line
361
that's
been
removed
in
this.
This
cap,
oh
or
in
this
cap,
update
the
API
I,
see
now
I
I
would
still
say:
yeah
I
think
they
probably
go
together.
I
think
most
response
at
the
time
and
now
is
likely
well
that's
great.
If
it
were
there,
I
would
use
it,
but
it
does
not
match
the
graduation
level
that
I
want.
D
So
that
was
going
to
be
my
next
question.
So
if
you
have
three
distinct
servers
serving
Cube
API
server
stuff
with
encryption
turned
on,
and
then
you
have
maybe
a
couple
other
aggregated
servers
that
also
have
encryption
like
for
their
resources,
what
happens
with
the
API
servicing
and
how
does
something
like
storage
migrator
know
like
when
it
should
start
touching
instances
of
a
given
resource
based
on
what
shows
up
here,
I
apologize,
maybe
you've
already
talked
about
all
this
I
haven't
read
the
code.
B
So
I
hadn't
thought
about
the
aggregate
API
server
case.
I
need
to
think
more
on
that
one,
but
the
the
general
API
server
cases.
The
way
this
differs
from
the
storage
version
API
is
that
or
this
sort
of
differs
is
that
it
basically
proposes
that
each
API
server
on
Startup
just
makes
one
of
these
and
they'll
get
gc'd
as
they're
not
updated.
B
So
basically,
if
you
have
n
that
matched
the
where
n
is
the
number
of
API
servers,
you
expect
and
they
all
line
up,
then
you
can,
then
you
can
use
them
as
those
identities,
but
it
does
not,
for
example,
like
the
API
server
identity
had
like
this
lease
concept
and
like
with
some
labeling
and
some
other
semantics.
None
of
that's
present
here.
It's
just
you
make
a
resource
per
API
server.
B
B
B
B
B
C
B
A
B
A
D
Maybe
just
think
about,
like
the
multi-server
case
and
the
like,
even
the
way
you're
describing
sort
of
the.
If
you
don't
update
for
a
while
garbage
collection
cleans
it
up,
I
mean
that
sounds
like
a
lease
yeah
and
the
aggregated
case.
Think
about
that
I
mean
I
know
the
the
storage
version
thing
is
Alpha,
but
this
would
also
start
as
Alpha.
So
it's
not
like
you're.
B
C
D
All
right,
like
the
thing
that
yeah
the
problems
that
it
was
solving,
were
like
around
storage
migration,
which
is
like
an
annoying
technical
debt
thing.
But
as
long
as
we
never
ever
delete
old
API
versions,
it's
like
an
interesting
it'd
be
nice
to
clean
this
up
rather
than
an
urgent
thing
and
then,
like
small
inconsistencies
on
surfacing
new
apis
during
an
upgrade
which
is
rare
and
short-lived
and,
like
generally
resolves
itself.
So
there's
just
not
a
lot
of
demand
for
it
and
it's
a
thorny
issue
to
work
on.
B
Let's
see,
I
can
move
up
to
like
hot
reload,
which
is
the
one
above
this
I
think
the
just
the
open
question
there
is:
is
hot
reload
just
going
to
happen
when
you
upgrade
to
126?
That's
you
know:
it's
not
merged.
Yet
I
haven't
reviewed
the
pr
and
stuff,
but
there
is
a
PR
that
gives
us
hot
reloading
of
this
config.
D
If
we
follow
the
same
pattern,
we've
taken
in
the
past
with
things
like
ca,
bundles,
where
we
only
replace
the
existing
configuration
when
we
successfully
load
a
non-empty
replacement
like
if
you,
if
you're
editing,
process
like
move
the
file
somewhere
else
and
then
moves
into
a
new
file
in
place,
we
should
never
accidentally
be
like
oh
I,
guess
you
wanted
to
turn
off.
Encryption
meet
big
so
like
keep
using
the
successfully
loaded
one
until
we
get
another
successfully
loaded,
non-empty
one
I
I,
don't
know
David.
What
do
you
think.
A
B
B
D
We
this
reminds
me
a
lot
of
like
the
dance
when
you
update
a
crd,
and
we
have
to
like
let
ex
like
stop
accepting
or
set
up
the
new
Handler
with
the
new
crd
definition
start
Direction,
requests
of
that.
Let
old
requests
complete
via
the
old
Handler
and
then
shut
it
down
right.
Let's
make
sure
we
don't
break
anything
in
place.
B
Yeah,
the
beauty
of
it
is
I
recently
wired
up
a
context
to
that
whole
thing,
so
you'll
be
able
to
turn
it
off
when
you
want
to
turn
it
off,
because
previously
it
just
never
closed
the
connection
until
the
API
server
shut
down
so
yeah,
we
have
a
place
to
clean
this
up.
Now
we
can.
We
can
wire
it
up
better.
Okay,.
B
B
No,
this
still
won't
work
for
that
until
Rita
is
currently
assigned
the
issue.
So
whenever
Rita
fixes
that
issue
that'll
get
sorted,
but
no
you
you
that
that
needs
to
be
fixed
and
you
should
be
able
to
directly
say:
I
want
XYZ
crd
encrypted
and
that
should
actually
work.
This
is
more
of
just
I,
don't
care.
What's
on
my
cluster
and
I,
don't
know
what's
secret
or
not,
please
just
encrypt
it
and
leave
me
alone.
B
So
today
it's
I
think
group
resource
is
annoyingly.
Just
a
string
in
the
encryption
config
object,
which
really
annoys
me
so
I
guess
we
could
make
it
parse
it.
However,
we
want
to
we
wherever
we
think
it's
appropriate
as
long
as
it
doesn't
have
ambiguity
into
what
it
means.
But
today
we
just
parse
the
string
into
a
group
resource
and
yeah.
B
B
D
B
B
That's
what
I
figured
we
would
have
to
do,
because
otherwise,
clients
would
have
to
like
the
the
storage
migration
controller
thing
would
have
to
go
figure
it
out
itself.
It
seemed
awful
yeah
since
they're,
not
the
authority,
but
so
I'll.
Follow
that
aside,
I
think
those
are
all
technically
doable.
Does
anyone
object
to
basically
semantic
star
Magic
on
top
of
that
string
field
to
make
it
do
different
things.
D
B
And
we
provide
you
with
a
reference
implementation
which
I
still
have
to
review.
Christoph
I
apologize,
I
have
not
forgotten,
but
yeah,
so
I
I
think
we're
we're
significantly
putting
things
in
the
right
place.
Where
writing
a
bad
one
is
really
hard
because
it
would
mean
you
decide
to
ignore
all
the
free
stuff.
D
I
have
to
run
to
another
meetings.
I'm
sorry,
I,
real,
quick
on
the
the.
If
we're
going
in
reverse
order,
one
one
one:
four,
oh
five
I
opened
up
that
up
and
it
looked
like
it
was
proposing
like
surfacing
or
letting
you
target
particular
encryption
providers
in
annotations
or
like
for
particular
API
objects
that
that
doesn't
seem
like
something
we
want
to
do,
or
at
least
I
wasn't
expecting
to
expose
Storage
level
configuration
out
to.
B
Yeah
I
I
agree
with
that
General
sentiment,
but
you
know
I,
don't
think
ROM
is
here
to
defend
what
he's
asking
for,
but
I
can
try
to
give
some
some
color
to
this.
One
of
the
things
that
the
KMS
V2
design
implicitly
sort
of
requires
is
that
a
KMS
plug-in,
like
only
has
one
right,
key
like
in
the
sense
of
like
what
it
says,
is
current
right
key.
Is
it
can't
have
like
one
per
namespace
or
something
so
what
ROM
was
trying
to
build?
C
B
C
B
B
B
A
B
C
B
C
A
B
Some
API
server
Behavior
to
pass
in
more
data
to
them,
or
something
and
so
I
mean
I,
can
try
to
figure
out
where
they
got
sort
of
this
multi-tenancy
for
the
KMS
thing
to
see,
if
at
least
that
bit
could
keep
working
like,
for
example,
because
key
ID
is
opaque
to
the
API
server.
Nothing
prevents
you
from
like
creating
a
giant
Json
blob
with,
like
all
the
mappings
and
shoving
all
that
through
it's
just
the
API
server
would
be
like.
A
C
C
Where,
like
you
know,
once
every
year
or
so,
someone
loses
a
key
and
we
cycle
the
whole
thing.
If
you
had
the
backup
and
you
had
that
you'd
have
a
problem
and
if
you
were
multi-tenant
and
you
were
I,
don't
know,
qci
I'm
sure
qci
has
never
lost
a
key.
Then
the
qci
information
in
that
backup
would
still
be
safe.
A
A
B
C
A
C
C
B
Yeah
so
I
I
thought
about
passing
extra
metadata.
What
what
comes
out
of
that,
though,
then
is
the
status
API
has
to
sort
of
explode
to
handle
it.
So,
for
example,
if
you
decide
you
want
key
id1
for
Secrets
right
for
config
Maps,
you
have
to
tell
the
API
server
that
that's
what
you
want,
so
it
can't
just
be
I
pass
in
extra
information
to
the
plug-in.
B
C
Else
it
sounds
like
the
next
thing
to
do
is
just
make
sure
this
was
actually
impossible
before
and
then,
if
it
wasn't
impossible,
come
up
with
good
reasons
why
we
would
say
this
is
a
bad
idea
and
the
one
from
Mike
about.
If
somebody
changes
this,
then
you
can't
restore
backup,
is
pretty
good
and
assess
that
against
just
how
much
a
game.
By
doing
it.
A
B
B
Is
it
won't
give
up
it'll
keep
trying
until
it
finds
when
it
runs
out
of
Transformers
I
I
asked
Jordan
about
this
and
he
felt
like
it
was
just
a
bug
and
we
shouldn't
allow
that
I
think
I
think
we
asked
internally
in
Azure
and
we
don't
it
doesn't
matter
to
us,
because
we
always
give
all
KMS
plugins
unique
names
based
on
I.
Think
the
key
that's
in
use.