►
From YouTube: sig-auth bi-weekly meeting for 20230301
Description
sig-auth bi-weekly meeting for 20230301
A
Okay,
hello:
everyone
welcome
to
the
March
1st
2023rd
meeting
of
Sig
auth
hop
over
to
the
agenda.
The
first
item
to
discuss
is
the
external
signing
key
for
service
account
tokens
draft
cat.
B
Yeah
so
we
talked
about
this
I
think
like
late
November
and
then
there
were
the
holidays,
and
so
so
it's
been
a
while,
but
there
I
did
receive
some
feedback.
That
I
tried
to
include
in
this
and
I
followed
the
feedback
to
open
a
new
cup
instead
of
trying
to
edit
the
other
one.
B
A
Sorry,
what
was
that
last
part?
Oh.
B
So
should
I,
oh,
so
the
the
old
issue
is
closed.
So
should
I
just
open
a
new
issue
and
basically
link
to
the
old
one
and
then
use
that
for
the
cap
number
yeah.
A
I
think
that
would
be
the
best
thing
to
do.
We
can
start
fresh,
given
it's
been
so
long
since
we
did
the
old
one.
So
I
guess
this
is
probably
slated
for
1
28.
Then.
A
A
Cool
did:
are
there
any
significant
changes
from
the
previous
cap
or
I
guess
previous
proposal.
B
A
Cool
sounds
good
I
guess
we
can
review
and
then
discuss
in
more
detail
in
a
later
cigarth.
C
For
the
I
know,
I
looked
at
the
doc
I
hadn't
had
a
chance
to
look
at
the
pull
request.
Do
you
is?
Was
it
pretty
easy
to
see
the
responses
to
the
questions
that
were
in
the
doc?
I
didn't
see
any
inline
responses,
so
I
wasn't
sure,
like
some
of
the
questions
I
had
were
like
how
this
interacts
with
the
controller
manager
and
things
like
that.
So
I
wasn't
sure
yeah.
B
I
was
I
was
looking
through
the
dock
the
other
day
trying
to
find
it.
B
B
Yeah,
it
looks
like
Micah
responded
about
the
KCM
stuff,
and
then
this
should.
We
include
the
algorithm
yeah
yeah,
I,
I,
I'll
double
check,
but
I
believe
I
included,
like
the
the
feedback
about
the
algorithm
and
I,
put
a
note
in
the
pr
for
yeah
I.
Think
most
of
it
is
in
the
pr
I'll
double
check.
D
C
Had
asked
if
the
controller
manager
was
generation
of
tokens
was
deprecated
and
there
were
two
types
of
tokens:
the
controller
manager
created
it
auto
created
tokens
and
that's
no
longer
happening,
but
it
also
would
fill
in
secrets
that
were
requested,
and
so
that's
still
supported
so
I
I
do
think.
C
We
need
to
figure
out
how
this
would
interact
with
that
aspect,
I
just
looking
at
the
like
the
motivation,
the
main
motivation
listed
is
talking
about
being
able
to
reload
a
signing
key
to
rotate
keys
and
just
adding
support
for
a
dynamically
rereading.
The
file
would
be
way
easier
to
meet
that
motivation,
and
so,
if
the
motivation
is
actually
to
support
like
out
of
process
signing,
that
would
be
good
to
hoist
into
the
motivation,
because
that
yeah
like
there
are
way
easier
ways
to
get
rotation
without
restarting.
B
Yeah,
that's
that's
good
good
feedback.
All
yeah,
I'll
I'll
think
about
that
some
more
and
chat
with
Mike
and
some
other
folks,
and
that
might
be
the
route
we
end
up
going.
A
E
B
C
G
G
Like
I'm,
just
a
little
confused
like
I
guess,
like
so
I
know,
you
guys
have
had
a
patch
for
this
for
a
long
time.
I
feel
like
you
would
have
just
done
that
if
that's
what
was
needed,
I'm
just
a
little
lost
now,
because
it's
way
more
work
to
build
an
entire
RPC
thing
wire
it
up
to
something,
carry
a
patch
for
it.
I
don't
know,
am
I
missing
something
because
yeah
I'm
totally
down.
If
you
just.
B
Want
yeah
I,
it
might
be
that
I'm
missing
something
I
I'm
coming
into
this
I
didn't
have
that
much
context
on
originally
but
like
how
it
was
implemented,
and
why
originally
several
years
ago,
but
yeah
I'll,
need
to
follow
up
with
our
auth
team
and
see
if
they
have
any
plans
like
what
what
their
plans
look
like
and
how
just
doing
the
dynamic
reload
sounds
to
them.
C
Okay,
yeah,
just
let
us
know,
maybe
either
tweak
tweak
this
to
sort
of
make
sense
with
the
outer
tree
focus,
and
then
we
can
sort
of
evaluate
that
and
figure
out
like
if,
if
that's
a
reasonable
path
forward
or
if
the
dynamic
stuff
would
need
your
goals.
A
H
Yeah
just
kind
of
throwing
this
out
there,
so
people
can
read
it
and
form
some
opinions.
I,
don't
think
we
need
to
have
like
a
long
discussion
on
it
today,
but
so
this
is
sort
of
like
looking
at
what
would
the
the
next
thing
after
clustered
thrust
bundle,
so
cluster
trust,
bundles?
Are
the
mechanism
for
Distributing
roots
of
trust
within
the
cluster?
The
other
half
of
x509
is
actually
getting
your
leave
certificates.
H
So
I'm
outlining
and
I
have
some
sort
of
proof
of
concept
code
linked
there
as
well,
because
it
was
way
easier
to
like
start
coding
it
and
then
come
back
and
co-design.
It.
H
But
basically,
what
I'm
proposing
is
that
we
give
cubelet
the
ability
to
have
a
projected
volume
source
that
generates
a
key
and
goes
off
to
some
in
cluster
assigner
and
requests
a
certificate
from
it
and
then
automatically
rotate.
The
key
insert
when
it
looks
like
the
cert
is
approaching
its
expiration.
H
E
So,
just
looking
through
the
the
goals
and
like
quickly
browsing
the
the
API
produced,
is
there
anything
about
the
idea
of
having
a
spiffy
identity
that
called
that
shapes
the
way
the
API
would
be.
H
H
No,
so
I
actually
went
to
Great
Lengths
to
make
this
totally
agnostic
to
whatever
ends
up
in
this
circle
like
we
don't
want
to
take
any.
You
know
this
is
sort
of
building
on
top
of
the
entry
I,
don't
on
top
of
the
existing
signer
mechanism,
where
you
can
have
plugable
third-party
things,
just
existing
in
the
cluster
answering
certificate,
signing
requests,
and
so
this
is
just
saying
from
the
perspective
of
all
the
machinery.
E
If
we
wanted
to,
we
would
be
able
to
develop
this
and
later
add
spiffy.
I
know
you've
been
wanting
spiffy
for
a
long
time
right,
but
we'd
later
be
able
to
add
spiffy,
see.
H
I,
don't
okay,
I,
don't
really
mind
what
goes
so.
The
only
reason,
I've
included
anything
about
spiffy
under
the
possible
goal
section
is
that
the
moment
we
create
a
default
certificate
that
can
be
used
as
an
API
server,
client
customer
or,
like
users,
are
going
to
start,
depending
on
the
format
of
that
certificate
for
their
own
workload
to
workload
authentication.
So
we
need
to
make
sure
it's
what
we
want
or
we
could
play
games
where
we
don't
make
the
like.
H
Okay,
yeah,
but
my
main
interest
here
is
to
land
the
mechanism
rather
than
specifically
Landing
some
sort
of
default
implementation.
Although
I
think
the
defaulting
movementation
is
like
a
logical,
Next,
Step.
H
G
Terry,
where
are
we
on
the
the
actual
trust
anchor
stuff
are
we
are
we
doing?
Is
that
gonna
make
it
for
127.
I.
H
G
Okay,
so
if
we
had
both
of
those,
then
you
have
the
ability
to
express
your
anchors
and
the
ability
for
the
cubelet
to
mount
them
for
you
into
pods,
but
for
but
nothing
from
the
API
server
yet
like
the
API
server
can't
use
it
for,
like
web
hook,
anchors
right
right,
okay,
so
I
was
just
trying
to
remind
myself
how
far
we
got
on
this.
Oh.
F
E
A
question
about
possible
future
like
graduation
criteria.
Thinking
this
through
not
saying
it's
definitely
a
thing,
but
how
would
you
feel
if
one
of
those
criteria
for
moving
to
Beta,
for
instance,
or
or
moving
to
stable,
was
demonstrating
how
a
a
workload
that
wanted
to
have
its
own
signing,
Zone,
signer
and
its
own
trust
anchor
would
be
able
to
use
this
API
to
have
other
workloads
easily
create
a
certificate
only
good
for
communicating
to
itself
and
have
that
flow
function?
E
Is
that
is
that
a
flow
you
envision
happening?
Is
it
well
I,
guess
just
start
there
yeah.
H
I
guess
so
I
definitely
make
think
think
it
makes
sense
to
like
link
the
beta
or
GA
criteria
of
the
cluster
trust,
bundles
work
and
the
any
forthcoming
like
workload
certificate
mounting
stuff,
because
they're
meant
to
be
used
together,
at
least
in
part
as
like.
A
a
unified
hole.
I
do
think
that.
E
I,
haven't
I,
haven't
done
all
the
way
through,
but
that
seems
like
a
natural
way
to
use
what's
being
created
here.
Yeah
and
I
don't
have
having
not
read
apologize.
I
have
not
read
this
entire
doc.
Yet
I
don't
immediately
know
all
the
parts
that
would
come
together
and
how
much
burden
there
would
be
on
someone
trying
to
actually
make
that
work.
H
A
Sounds
good
all
right,
no
deck,
reuse.
G
Okay,
so
I
wanted
to
bring
this
up
to
get
people's
feedback.
I
talked
to
Jordan
about
this
earlier
today.
Just
to
start
the
conversation
with
him,
but
the
general
just
is
so.
We
just
started
collecting
metrics
from
CI
on.
You
know,
running
a
cluster,
that's
using
KMS
V2
and
just
seeing
the
numbers
of
like
basically
what
the
cost
of
these
operations
is
and
when
everything
is
awesome,
the
cost
of
these
operations
is
like
fractions
of
milliseconds.
G
Super
awesome,
so
this
had
been
discussed
a
long
time
ago
for
cam
sv1,
but
we
didn't
push
it
through
because
we
didn't
have
a
way
to
make
it
work,
sort
of
correctly
with
storage
migration,
because
storage
migration,
because
the
KMS
layer
did
not
have
a
way
of
correctly
informing
the
rest
storage
layer
that
it
needed
to
have
a
rewrite
for
Keystone
illness.
G
So
with
KMS
V2,
we
fixed
that
with
the
whole
key
ID
concept,
so
their
plugin
can
tell
us,
as
in
the
API
server
that
I
know,
all
your
bytes
are
all
exactly
right,
but
I
need
you
to
issue
a
write
anyway,
because
I
plan
on
changing
how
I
store
the
data
by
encrypting
it
differently.
So
we
have
all
those
capabilities
now.
G
So
what
this
PR
does
is
it
removes
the
inline
one-to-one
mapping
on
right
calls
to
make
an
immediate
encrypt
call,
and
instead
what
it
does
is
on
a
background,
go
routine.
Basically,
every
minute
it's
going
to
sit
there
and
create
a
new
deck
and
that
deck
will
get
reused.
For
that
minute.
Approximately
I
still
need
to
update
some
of
the
semantics,
so
the
gist
is
that
the
current
plan
I
had
was.
G
If
the
plug-in
is
having
a
hard
time.
Basically
like
it's
in
some
broken
State,
we
would
reuse
the
deck
for
up
to
two
minutes,
but
afterwards
we
would
not
allow
further
rights
with
it.
I
mean
we're
well
within
any
window
of
AES
GCM
key
reuse
right,
we're
we're.
F
G
F
G
Just
in
general,
like
we,
we
saw
like
to
give
an
example
in
the
E
to
e
test
that
we
have
for
canvas
right
now.
It
ends
up
doing
like
14,
000
encryptions,
but
like
with
this
PR,
it
does
like
30..
G
So
you
know
vastly
reduces
the
load
on
your
plug-in
and
I'm
gonna
I'm
still
working
on
optimizing
it
so
like
right
now
it
just
always
keeps
making
new
keys
I'm
going
to
make
it.
So
it
only
makes
a
new
key
when
the
key
has
been
used
at
least
once
and
and
the
plugin
hasn't
changed.
This
key
ID,
but
I
wanted
to
get
feedback
on
this
because
it
I
think
it's
one
of
like
it's
one
of
the
few,
like
true
divergences
from
KMS
V1,
like
I,
think
so
far.
G
V2
has
just
been
very
carefully
expanding
and
polishing
on
what
existed
before,
but
I
think
this
one
is
pretty
significantly
different
and,
like
the
the
two
minute
number
basically
comes
from
like
well.
How
long
would
you
need
to
tell
an
operator
if
they
don't
want
to
actively
figure
out
if,
like
plug-in
state
has
been
observed
to
like
wait
right
like
so
there's
metrics
that
tell
you
the
state
of
the
plug-in,
but
there's
not
a
rest
API
yet
so
like?
G
G
Get
feedback
see
if
there's
concerns
or
other
things,
but
yeah,
my
my
feeling
is.
We
should
make
this
change
before
going
to
Beta.
So
that
way,
we
don't
change
the
contract
of
how
the
system
is
going
to
internally
work
under
people
when
it's
in
the
beta
state,
and
my
feeling
is
that
with
the
numbers
I'm
seeing
on
the
from
the
metrics
that
we
do
need
a
change
like
this,
because
otherwise
the
performance
just
isn't
sort
of
good
enough
to
really
be
a
motivating
factor
from
like
V1
to
V2.
C
One
other
thing
to
point
out
is
that
having
some
amount
of
reuse,
that's
bounded
also
helps
in
read
cases.
So
if
you
on
cluster
creation,
you
know
we
create
I,
don't
know
a
thousand
node
objects
and
a
thousand
whatever
events
and
leases
and
are
back
whatever
I.
Don't
know
we
do
a
bunch
of
stuff
on
culture
creation
with
decorate
use.
You
know
a
big
Stone
right.
I
C
G
So
we
also
lacked
a
way
for
the
plug-in
to
tell
us
that
hey
the
remote
implementation
that
remote
KMS
has
rotated
its
key,
so
you,
like
whatever
state
you
have,
is
no
longer
valid
I.
Need
you
to
start
over
irregardless
of
what
you
were
doing
previously.
I
need
you
to
make
new
decks
and
I
need
you
to.
Let
me
rotate
out
right.
It's!
Basically,
your
hierarchy
of
Keys
has
changed
so
now
like
now.
G
The
plugin
can
inform
you
without
any
API
server
restarts
without
any
of
like
the
really
heavy
painful
migrations
right
you
can
like.
Basically,
the
system
can
Coast
on
like
a
functional
State,
and
you
can
change
your
functional,
State
and
it'll
very
quickly,
notice
it
and
start
letting
you
migrate
to
it.
H
C
I
C
Don't
think
so
the
two
main
things
that
I
wanted
to
be
sure
of
were
that
we
could
really
clearly
communicate
the
bounding
of
time.
C
So,
if
I,
if
I
rotate,
my
Ricky
like
after
what
point,
can
I
be
confident
that
every
right
is
going
to
be
using
that
key,
initially
like
I,
think
a
one
minute
period
like
one
or
two
minutes
like
slow
single
digit
minutes
is
probably
fine
as
a
default
and
I'm
not
sure
we
need
a
configurable
knob
like
it
takes
time
to
do
a
date
of
rotation
anyway,
to
do
a
storage
migration,
so,
like
saying
rotate,
your
key
queue,
a
job
for
like
two
minutes
later
to
start
the
migration
that
seems
probably
okay.
C
If
we
get
feedback
in
beta
that
nope,
we
absolutely
need
to
be
able
to
configure
this
shorter
or
longer
like
I
guess
we
could
add
a
knob
but
I'm
not
sure
we
need
a
knob,
so
bounding.
The
time
is
the
big
concern
and
then
the
other
thing
was
What
mo
mentioned,
like
making
it
not
make
calls
and
steady
state
if
it's
not
needed.
C
So,
even
though
we
have
this
background
thing,
if
we're
not
actually,
if
someone
only
encrypted
secrets,
for
example-
and
no
secrets
are
being
written
like
we
shouldn't-
need
to
get
a
new
deck
every
minute.
I
Yeah
I've
got
another
question
that
might
be
a
little
off
topic,
so
feel
free
to
skip
it.
If,
if
you
want
to
keep
talking
about
this
proposal,
which
is,
is
there
anything
in
KMS
V2
or
are
we
thinking
about
anything
like
like
today?
If
I
try
to
list
secrets
and
even
one
of
the
secrets
can't
be
decrypted
and
I
can't
even
find
out
which
one
can't
be
decrypted,
because
you
know
there's
no
like
metadata
on
the
secrets
that
I
can
get
because
it's
encrypted
with
the
secret?
C
I
H
I
It's
not
it's
not
really
something
like
broken
in
the
storage
layer.
Right,
it's
like
like,
say
customer.
You
know
disable
the
key.
Now
they
can't
list
any
of
their
secrets
and
you
know
or
like
sometimes
we
get
a
case
where
a
customer
disabled
a
key
and
then
they
tried
to
do
a
key
rotation
to
like
fix
the
API
server
problem.
But
it's
sort
of
like
you
know,
yeah,
that's
a
high
leverage
thing
you
can
do
in
the
wrong
direction
and
and
then
we
need
to
figure
out
or
you
know
what
like,
which
Secrets
do.
I
G
I
G
What's
gonna
happen
afterwards,
yeah
I,
so
I
I
think
we
talked
about
this
a
lot
on
the
initial
KMS,
V2
conversations
and
I
think
we
basically
said
we
just
can't
do
anything
here
like
like.
We
can
make
the
problem
more
obvious,
but
we
cannot
give
you
an
automatic
solution.
You
you,
the
operator,
have
to
build
your
infrastructure
to
help
your
customers
out
of
this
hole,
basically,
like
probably
on
the
AKs
side,
like
you
know
at
some
point,
we'll,
hopefully
have
like
a
managed
version
of
all
of
this.
G
I
G
I
Sense
yeah,
but
it's
it's
saying
that,
because
like
it,
doesn't
have
any
way
to
express
anything
else
today,
right
like
maybe
maybe
it's
capable
of
being
lenient
like
I,
don't
know,
maybe
it
all
it
does,
is
annotate
them
with
some
random
thing,
and-
and
you
know,
if
it
can't
annotate
one,
it's
not
that
big
a
deal.
I
don't
know,
but
it
doesn't
seem
like
we
give
give
a
lot
of
options
today,
I'm,
not
convinced
that
if
we
did
give
an
option
now
that,
like
everybody,
would
adopt
it
I
mean
it's,
you
know,
I,
don't
know.
I
If
we
we
ever
get
a
guarantee
at
this
point,
but
yeah
it
is.
It
is
kind
of
a
we
do
see,
customers
break
clusters
with
with
you
know,
doing
a
key
operation,
and-
and
you
know
where
they
you
know,
they
might
prefer
that
some
subset
of
the
Clusters.
E
I
Something
like
that
might
wouldn't
work,
but
like
yeah
secrets
that
are
broken
like
it
like.
Basically,
if
I
had
a
list
that
returned,
like
all
you
know,
all
the
errors
of
things
Cube
API
server
couldn't
read
in
the
list
that
that
might
help
keep
control,
delete,
doesn't
work.
C
E
But
but
an
option
that
would
say
Force,
Elite,
skip
all
finalizers,
really
really
delete.
This
thing.
E
You
know
I
only
have
like
three
options
that
mean
now.
You
know
grace
period
zero
for
real
force.
Clearly,
we
should
have
have
a
really
long
one,
for
you
should
feel
bad
because
you
lost
your
encryption
keys
but
but,
like
I,
can
see
this
being
a
practical
problem
right
where
we
do
this
rotation,
there's
some
stuff,
that's
broken.
E
The
person
who
has
it
either
doesn't
want
to
grip
through
all
the
logs
or
can't
and
then
even
once
he
has
them
he's
unable
to
actually
unwedge
it
without
direct
at
CD
access
and
then
providing
a
mechanism
for
him
to
say
no
really
just
I
screwed
up
nuke.
These
sounds
like
a
practical
solution
that
we
may
be
able
to
give
them,
as
as
part
of
this.
C
If,
in
the
process
that
fulfilling
that
list
request,
we
hit
decode
errors
like
surfacing
that
information
in
the
error
response
isn't
leaking
any
information
to
them
that
they
didn't
already
have
permission
to
see
like
here's,
the
names
and
namespaces
of
the
things
that
we
couldn't
decode
and
maybe
cap
it
at
like
the
first
I,
don't
know:
10
100,
something
like
that,
gives
them
the
information
and
then
on
delete
like
if,
in
the
process
of
delete,
we
hit
an
encode
error
like
the
person
was
authorized
to
delete
it's
borked
like
maybe
we
allow
that
I
don't
know.
C
F
I
I
think
something
like
that
would
help
I'm
also
curious.
Like
is
there
anything
we
can
do
on
in
updates
like
if
a
Secret's,
undecryptable,
I,
assume
I
can't
update
it
or
reply
over
it,
even
if
there's
a
controller
trying
to
apply
something
over
it,
yeah
and-
and
in
that
case,
like
there's
already
a
part
of
the
system,
that's
trying
to
heal
the
system
by
just
applying
over
it,
but
it's
being
blocked
by
updates.
C
Way
harder
like
delete
like
go
out
and
come
in
again
is
a
lot
safer,
like
we
don't
validate
on
delete.
We
do
validate
on
update
and
update,
has
like
very
particular
rules
about
what
can
and
cannot
be
changed.
C
I
A
Problem
I
had
a
comment
on
the
deck
reuse.
So
if
our
objective
is
to
increase
the
ReUse
of
decks
for
as
GCM,
can
we
switch
from
randomly
generating
the
IV
to
using
a
counter.
G
What
does
it
buy
me
exactly
other
than
I
mean
if
I
was
actually.
Let
me
think
sorry
if.
C
A
So
that
would
if,
if
our
goal
is
to
reduce
the
number
of
like
active
decks
in
use,
I
could
see
an
API
server
using
the
same
deck.
For
you
know
the
entire,
probably
the
entire
duration
of
its
process.
If
we
were
using
non-random
IBS
we'd
have
no
worry
about
this
200
000
per
day
problem,
using
that
we
have
with
random
IVs,
which
is
that
we
will
use
an
IV
twice
if
we
are
instead
using
like
an
atomic
counter
as
the
value
for
the
IV.
G
Yeah
I
guess
we
could
I
I
guess
in
a
sense,
I
would
say
that
we
can
do
that
either
way.
It's
really
more
of
just
like
I.
Think.
The
core
question
here
is
not
like
how
much
we
reuse
the
deck
or
exactly
what
process
we
use
to
make
that
safe
it's
more
about.
Can
we
just
do
it
at
all,
because
I
think
once
we
get
down
to
the
contract
of
we're
gonna
we're
willing
to
reuse
the
deck?
A
I
think
a
un-64
would
probably
get
us
for
most
through
the
lifetime
of
most
Cube
API
server
processes
on
a
single
key.
A
He
he
death
of
the
universe,
but
most
likely
but
200
000,
a
second
for
hundreds
and
hundreds
of
years,
but
I
think
what
Jordan
said
is
that
it
was
never
a
goal
to
have
a
deck
per
object,
so
I
think
regardless,
if
we
all
agree
with
Jordan
in
that,
then
that
answers
your
initial
question,
which
is,
is
this
okay?
So,
yes
and
I?
Guess
foreign.
A
Reduce
the
number
of
active
decks
in
the
cluster,
then
there's
probably
better
than
using
probably
better
methodology
than
using
a
random
IV
for
and
a
key
for
a
minute.
I
would
say
so.
G
Are
we
okay
with
that,
like
as
the
starting
point
and
then
like
I,
can
keep
iterating
on
it
and
if
we
want
to
make
it
a
key
for
like
the
life
or
the
server
I,
think
that
would
just
be
the
guy
would
have
to
re.
I
would
have
to
gut
the
GCM
Transformer
and
have
it
have
a
counter.
Basically,
but
it's
fine.
A
G
There
is
just
a
pure,
like
was
I
used
at
all
I
guess
that
wouldn't
I
mean
that's
still,
I
think
that
concept
sort
of
goes
away
if
you're
doing
a
counter,
though
so
I
would
I,
would
remove
I
think
that
mostly
it
would
just
be.
Has
the
key
ID
changed
like
we
always
have
to
rotate
the
key
if
the
remote
KMS
is
telling
us
that
hey
it's
it's
its
root
key
is
different.
C
G
Just
I
I
think
the
comment
in
all
the
current
code
is
based
on
the
fact
that
we
use
random
IVs.
If
you
have
a
counter
that
is
your
IV,
the
birthday
problem
has
simply
disappeared.
So
the
only
time
you
need
a
new
deck
there's
only
two
cases.
One
is
you
have
done
two
to
the
64
minus
one
rights
with
it,
which
we
just
said.
That
probably
will
never
ever
happen,
so
we
can
maybe
just
ignore
it
and
the
other
one
is
the
remote
KMS.
C
G
A
So
if
we
generate
the
key
locally-
and
we
have
a
counter
for
the
IV,
then
we
basically
can
use
a
deck
without
fear
of
IV
reuse
and
we
can
have
a
sanity
check
if
it
goes
to
zero
panic.
G
That
is
one
way
to
do
that.
Maybe
not
what
a
customer
wants
us
to
do,
but
you
know
we're
here:
okay,
I
think
we
still
got
another
item
on
the
agenda.
F
A
Well,
if
our
goal
is
to
reduce
the
number
of
decks,
we
have
I
would
say
that
is
a
better
approach.
I
don't
have
too
much
of
a
preference,
I
guess
I
didn't
review
the
pr
I
guess,
take
a
look.
I
didn't
see
if
it's
going
to
be
significantly
more
than
we
can
land
next
before
the
15th.
A
What
was
the
last
part
you
just
said,
Mike,
so
I
I
take
a
look
at
what
it
would
take
to
do
the
counter
and
if
it's
more
than
you
think
we
can
land
in
the
15th
and
I'm
fine
with
foregoing
it.
For
now.
G
Okay
and
the
other
thing
was
like
I,
see
stand
Michael.
Is
anybody
interested
in
writing?
A
cap
for
status
tells
me,
like
the
the
return
status
on
a
failure,
tells
me
what
stuff
was
not
decryptable
and
a
super
magic
delete.
Nuke
button
to
help
me
find
delete
those
I.
Don't
want
that
to
be
part
of
KMS,
but
I
do
want
it
as
a
general
thing.
F
G
That
you
could
somehow
include
this
information
in
some
nice
structured
way
that
is
parcelable
with
some
probably
some
limit
of
how
much
data
is
sent
back
and
then
you
would
need
after
the
the
user
has
this.
You
would
need
super
fancy.
Delete
number
four,
that
that
means
like
I,
really
don't
care,
how
you,
how
right.
F
Yeah
yeah,
oh
I,
I
I,
see
I
understand
so
so,
basically
you
you
would
first
tell
them
well.
I
I
tried
my
best,
but
I
really
really
couldn't
I
couldn't
get
this
for
you
because
it's
very
likely
broken
and
then
you
you
will
have
a
fun
fancy
way
to
say.
Well,
I
I
really
really
want
to
remove
just
because
it's
messing
up
with
the
rest
of
my
resources
of
the
time.
G
Yeah,
so
the
part
that
I
think
we'd
never
get
past
is
doing
something
automatically
for
people,
because
if
they
just
you
know
soft
deleted
a
key
in
their
HSM,
they
can
just
undelete
it,
and
the
cluster
will
be
back
so
that
that's
like
Step
Zero
like
do
try
to
do
that,
but
yeah
right
now
in
like
AKs
and
gke.
If
you
have
actually
lost
the
key,
it's
make
a
ticket
to
support
and
they
go
and
fix
that
CD
for
you
right.
A
A
Let's
get
to
these
last
two,
the
next
one
is
SC
denied
deprecation
warning.
There
is,
it
looks
like
there
is
a
PR
open.
D
Yep
and
I
mean
I'm
here
actually
I
just
had
a
question
for
you.
It's
it's
really
done
to
the
Aerospace.
It's
really
like.
How
can
I,
basically
are
the
warnings
on
the
creation
of
pods
in
cluster
that
uses
that
use
this
security
context.
Plugin
was
basically
that
because
I
I
just
missed
that
for
the
127.
D
pip,
so
I
don't
know
if
it's
clear
what
I
asked
for,
but
if
you
can
provide
me
some
help
on
how
to
do
that.
It
will
be
amazing.
G
C
G
G
G
E
No
One's
Gonna
notice.
Remember
no
matter
what
we
do.
No
one's
going
to
notice
when
we
get
rid
of
this
thing
until
the
release
that
it's
gone
and
like
the
nicest
thing
to
do
for
them
probably
is
to
have
a
feature
gate
for
it.
That
says
this
thing
no
longer
exists
when
the
feature
hits
on.
Put
that
thing
all
the
way
to
and
now
it's
gone
and
then
give
them
one
release
where
they
can
do
it.
Oh
my
gosh
set
it
back
and
in
the
next
release
the
future
gets
gone.
E
I
have
done
it
at
least
once
and
I.
Don't
remember
what
for
and.
C
Nobody
complains
until
State
called
deprecated
that
you
can
set
a
feature
gate
to
yeah.
A
So
it
says
that
this
is
Alpha
in
1.0,
so
I
I,
suppose
that
we
didn't
probably
didn't
have
future
Gates
then-
and
this
is
not
guarded
so
popping
it
behind
an
alpha
feature.
Gate
seems
reasonable,
and
then
that
gives
us
the
One
release
to
revert
and
then
proceed
from
there.
But
as
far
as
like
letting
people
know
is
logs,
probably
fine
for
the
deprecation
warning.
Then,
especially
if
we
break
people
on
upgrade
unless
they
enable
the
alpha
feature.
C
Requiring
them
to
opt
into
a
gate
to
use
it
and
logging
and
giving
them
a
release
is
seems
fine,
like
anyone
who's.
Relying
on
this
to
keep
them
secure
is
going
to
be
disappointed,
so
it's
actually
unhelpful
to
like
continue
letting
them
release
have
to
release
guard
things.
Yeah
like
this,
so.
A
A
All
right,
cool
I'll
summarize
that
on
the
pr
next
item,
to
hear
support
from
mounting
a
combination
of
synonym
and
label
selector
to
assume
you
support
for
matching
a
single
cluster
trust
bundle
by
name.
H
H
One
of
the
ideas
that
was
floated
was
well.
Let's
just
have
cubelet
and
mount
these
things
by
signer
name
and
label
selector,
and
so
now
it
can
do
that.
Do
we
actually
need
the
ability
to
mount
the
a
specific
one
by
name
or
is
it
an
acceptable
experience
to
say,
like
you've
always
got
to
set
a
signer
name,
even
if
it's
a
dummy,
signer
name
that
you
just
made
up
and
you've
always
got
to
put
a
label
on
it.
H
The
labels
would
be
I,
guess
something
that
you
have
to
read.
The
documentation
for
your
signer
for
I
was
thinking
like,
maybe
for
the
entry
signers
we
would
say:
have
a
label
called
live
or
something
like
that.
That
is
like
I,
don't
really
care,
and
then
we
would
label
them
with
a
counter
or
something
as
we
do
rotations.
If
you
do
care
specifically
about
seeing
rotations.
H
E
The
thing
we
should
know
the
answer
to
trying
to
know
which
label
selector
you
need
is.
E
E
C
It
yeah
it
might,
it
might
help
to
like
have
the
use
cases
that
we're
envisioning
so
like
rotation
is
a
good
use
case,
targeting
a
specific
like
for
ntls
targeting
a
specific
destination
like
label
collectors,
are
super
flexible,
so
I'm
pretty
confident
that
they
could
enable
almost
any
use
case.
We
could
dream
up
going
the
next
step
and
saying
like
for
these
use
cases.
How
would
they
know
the
selector
to
specify?
Would
it
be
a
convention?
Would
it
be
a
default?
Would
it
be
like.
H
Sure
that's
something
we
should
answer
I
guess
what
the
question
I'm
asking
is
a
little
more
focused,
which
is
like
we've
replaced
the
question
of
use
magic
to
determine
which
name
your
signer
was
using
to
use
magic
to
determine
which
label
selector
your
signer
wants
you
to
use
that
like
do.
We
need
to
still
need
to
have
the
other
option.
C
H
And
so
for
the
entry
ones
you
know
before
we
would
have
been
putting
them
in
Kate
as
IO
Dash
blah
blah
blah
long
name
that
you
know
from
reading
the
documentation.
Now
we
could
say,
hey
it'll,
be
you
set
the
signer
name
to
be
case.io,
slash,
API
server
and
maybe
we
say:
don't
put
a
label
selector
or
we
say
put
label
selector
equals
live.
C
H
C
If
we,
if
we
start
with
the
use
cases
and
figure
out
which
of
those
use,
cases,
would
actually
require
the
consumer
to
know
the
label
selector
and
if
a
lot
of
them
don't
even
require
them
to
know
the
label
selector
that
seems
positive
and
if
there
are
use
cases
that
requires
you
know,
specific
selection
like
I
want
blue
green,
or
you
know
this
particular
Target,
like
you
have
ways
to
do
that.
But
presumably
people
with
such
specific
use
cases
would
already
need
to
be
like
following
documentation
about
how
to
accomplish
that
use
case.
H
A
A
Cool,
where
do
you
want
to
sort
that
out
to
your
the.
H
H
C
Yeah
I,
so
a
lot
of
the
things
that
will
either
generate
names
so
we'll
generate
pod
names
to
generate
CSR
names
or
things
like
that,
and
we
have
things
that
do
cleanup
on
those.
So
you
sort
of
fire
and
forget-
and
you
don't
have
to
worry
about
managing
it
here,
like
presumably
whatever
name
you
create
like
you
have
to
manage
that
and
either
update
it
or
like
delete
it
later
as
part
of
a
rotation.
So
you
actually
have
to
keep
track
of
all
of
your
managed
objects.
Sure.
H
If
you
want
to
know
all
the
ones
that
are
related
to
your
signer
or
you
remember
that
you
put
my
fancy
signer
as
the
start
of
them,
you
won't
be
able
to
delete
someone
else's
trust
bundle
because
of
admission
checks.
You
won't
be
able
to
mess
with
it
all
the
admission
checks
are
based
on
the
signer
name
field,.