►
From YouTube: Kubernetes SIG Auth 20180110
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180110
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/view#
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
We
are
recording
alright
welcome
to
the
sig
off
meeting
for
January
10th
2018
go
ahead
and
jump
into
the
agenda.
We
didn't
have
any
announcements
of
demos
listed,
so
we'll
jump
right
down
to
for
requests.
People
wanted
to
call
out
so
there
weren't
names
beside
these,
but
I'm
gonna
guess
Mike
wanted
to
mention
the
token
request.
One.
B
Got
a
question
related
to
that
one
I
actually
read
through
the
the
initial
proposal,
but
it
wasn't
obvious
to
me
whether
we
were
going
to
put
a
status
on
that
object
as
well
in
a
condition
that
would
indicate
check
back
later.
Something
is
going
to
write
this
as
opposed
to
immediately
responding
with
a
token
every
time
so.
A
A
A
A
C
A
A
A
D
Also
wanted
to
remit,
just
mention
that
so
the
we
took
out
the
TLS
kind
of
authorization
and
authentication
piece
of
it.
So
it's
just
a
local
UNIX
domain
socket
now,
which
I
think
is
the
right
thing
for
the
initial
piece,
we're
kind
of
discussing
internally
how
we
want
to
run
this
and
what
kind
of
considering
may
be
running
it
all
samasta,
so
I
think
after
that,
PR
is
in
and
with
the
basic
kind
of
local
domains
of
it.
B
I
actually
had
a
question
for
you
about
it
right,
the
the
Google
Doc,
you
were
active
in
the
Google
Doc
and
then
it
looked
like
activity
had
died
down
and
we
reached
agreement
in
the
Google
Doc.
Initially.
Are
we
prepared
to
say
in
principle
we
agree
with
the
whole
for
the
community
as
it
is
today
or
so.
D
E
D
A
The
only
question
I
had
was
around
the
the
version
parameter,
I,
think
that
was
kind
of
not
cargo
coltd
but
modeled.
After
the
way
the
cubelet
erp
interfaces
were
set
up
and
I
I
don't
have
a
lot
of
experience
with
versioning
G
RPC
interfaces.
So
I
wanted
to
make
sure
someone
who
did
kind
of
had
a
clear
picture
in
their
head
of
how
that
would
be
used
going
forward.
B
Okay,
I
think
I'd
like
to
say
then
that
they
ended
this
week,
I
plan
to
merge
the
the
community
poll
for
the
design.
So
if
we
want,
if
you
want
more
comments,
go
ahead
and
review
again,
it's
been
open
on
the
Google
Doc
for
a
while.
It's
been
linked
to
discussed
here
multiple
times
yeah,
so
I'm
not
expecting
to
see
any.
G
H
A
F
So
this
went
through
another
iteration
over
the
break.
I've
had
some
time
to
update
it.
They
stopped
this
feedback.
This
is
a
proposal
to
add
an
exact
place
plug
in
to
Clank
oh
and
coop
CTL.
So
you
could
use
sort
of
alternative,
credentialing
strategies
or
fleshing
strategies.
There
are
some
open
concerns
about
how
to
do
things
like
for
quest
signing
if
we
ever
potentially
want
to
do
that
or
respond
to
events
like
client
go
receiving
a
401
indicating
that
the
credentials
are
likely
expired
or
invalid.
F
F
H
A
I'm
not
sure
who
added
this
to
the
needs
review
list
was
this
teal
server,
bootstrapping
or
a
client
bootstrapping.
G
G
This
is
not
rotation.
This
is
like
the
the
initial
bootstrap
where
couplet
gets
a
bootstrap
Cooper
config
goes
in
and
we
stir
up
steal
off
certificates,
client
certificates
for
itself.
Well,
I
guess
the
bootstrap
is
both
right,
so
we're
interested
in
both
I
guess:
I
just
wanted
to
get
general
feedback
about
what
kind
of
blockers
there
are
to
get
that
to
GA
and
whether
that
might
happen
in
110.
C
Was
said,
the
returning
to
a
bootstrap
credential
is
an
attribute
of
the
rotation
to
client
rotation,
which
I
think
is
potentially
separate
from
this
specific
feature
and
then
the
like
deployments
specific
at
the
station
I
think
we
can
knock
out
inside
the
authentication
provider
plugin
stuff,
so
actually
I
feel
pretty
good.
With
this
specific
portion
of
cubelet
client
certificate
rotation
or
it's
the
client
certificate,
bootstrapping
I
don't
actually
have
any
changes
to
it.
That
I
can
think
of
off
the
top
of
my
head,
like
just
clarify.
G
C
So
for
the
bootstrap,
the
how
client,
TLS
bootstrap
works
in
qiblah
today
is
you
handed
it
cube
config,
so
I
was
I
would
like
to
be
able
to
have
that
initial
authentication
and
I
think
you're
authenticating,
as
a
user
in
who
is
in
the
group,
node
bootstrap
or
something
I
would
like
to
have
that
initial
authentication
be
able
to
take
advantage
of
like
TPM
or
VM
signed
identity
document
I.
Think
we
can.
C
F
F
A
The
key
is
that
the
interface
externally
doesn't
change
like
in
the
bootstrap
case,
where
you
say:
here's
the
cube,
config
that
you
use
to
bootstrap
and
right
now
it
only
has
a
certain
set
of
capabilities,
but,
as
we
add,
more
capabilities
to
client
go
loading
things
from
cube,
config
it.
It
would
be
good
to
keep
these
use
cases
in
mind,
so
we
don't
put
it
into
just
cube
controls.
We
put
it
into
the
actual
client
go
library
so
that
that
would
enable
pretty
advanced
use
cases
inside
the
cube,
Latour
inside
other
components.
A
C
Right,
yeah
and
I
I
have
some
open
questions
about
how
client
rotation
is
currently
implemented
or
certificate
rotation
in
general
inside
the
certificate
manager,
but
I
don't
think
that
that
needs
to
block
bootstrap
or
cubelet
bootstrap
all
right,
qiblah
client
certificate
bootstrap.
Does
anybody
have
an
alternative
opinion
on
that
I.
D
Think
one
of
the
issues
were
referring
to
is
like
certificates
expiring
and
then
what
happens
like
if
your
cost
to
get
suspended
for
I'm
trying
and
then
all
sorts
of
Speyer
if
they
were
only
dialed
for
let's
say
a
short
time?
How
do
we
kind
of
reissue
sets
and
get
back
to
working
cluster?
So
you're
saying
like
that
kind
of
issues
is
separable
from
the
bootstrap
yeah.
C
G
Okay,
I
think
that
answered
make
sounds
like
there's
no
immediate
blockers,
so
I
might
write
a
features
issue
about
just
sort
of
letting
living
at
least
the
bootstrap.
The
bootstrap
coop
command,
bootstrap
coop
config
flag
for
couplet
I
graduate
to
GA,
and
if
the
sort
of
rotation
and
stuff
is
not
on
GA,
that.
A
A
F
Just
to
sort
of
provide
some
background
for
why
we
open
that
issue
as
chorus
goes
forward,
we'd
like
to
utilize
more
of
the
CSR
bootstrapping,
but
are
sort
of
unclear
about
how
much
of
it
is
gonna
happen
in
the
couplet
or
happen
externally,
so
I
I
think
it
to
an
extent.
It
would
be
easier
for
us,
in
some
cases,
to
have
an
external
agent
doing
some
of
this,
and
that
impacts
the
design
decisions
of
us
using
the
couplet
flags
versus
writing.
An
agent
that
handles
all
of
this
ourselves.
C
G
Guess
just
add
context
to
context
for
bringing
this
from
say.
Cluster
lifecycle
is
just
an
overall
push
to
get
features
to
out
of
out
of
beta.
That
Covidien
depends
on
it.
Scoob
idiom
is,
and
you
said,
a
lot
of
places
and
really
we
should
be
able
to
start
calling
a
ga
at
some
point
we're
trying
to
sort
of
bought
it.
Although
all
the
things
we're,
depending
on
making
sure
that
everything's
marching
towards
GA
at
least.
A
D
D
D
Yeah,
so
Google
suddenly
contribute
it
might
be
a
bucket
of
money.
It
might
be
you
know,
but
we
can
that's
kind
of
like
pending
finance
people
figuring
I.
Don't
think!
That's
really
super
interesting
to
this
meeting.
I'd
expect
kind
of
like
we
have
a
spike.
If
we
did
this
we'd
kind
of
have
a
spike
filly
immediately
after
the
announcement
as
people
kind
of
look
for
a
low-hanging
fruit
and
so
ideally
we'd
kind
of
want.
I
Just
I'll
just
add
on
to
that
Greg
I
think
yeah.
There
would
be
a
spike,
obviously
at
an
initial
announcement,
but
the
ways
I
could
every
release.
You
could
imagine
every
time
you
new
set
of
features
come
out.
You'd
have
a
spike
and
they're
also
still
very
much
in
a
discussion,
but
if
we
wanted
to
provide
some
sort
of
SLA
as
to
how
quickly
we
respond
to
certain
types
of
vulnerabilities,
and
would
you
expect
from
larger
projects
that
might
be
something
to
take
into
consideration
as
well
get
a
p0
of
on
a
vulnerability?
D
D
Think
because
kubernetes
is
such
also
like
a
big
project
that
you
can
figure
can
configure
so
many
different
ways
that
we'd
probably
almost
have
to
go
to
the
extent
of
like
an
example,
application
that,
like
has
some
security
guarantees
about
this
namespace
shouldn't,
be
able
to
interact
with
that
namespace.
These
are
back
rules
enforce
this
distinction
between
these
two
parts
of
the
application.
Maybe
something
like
that.
That
would
give
like
explicit
things
that
security
reaches
researchers
could
like
have
a
quick
thing
to
run
up
and
start
testing.
G
A
Are
configuring
all
the
controls
we
have
in
place,
so
you
have
a
name
space,
constraint,
user
that
has
the
admin
role
that
has
a
network
policy
in
place
and
upon
security
policy
that
can
do
XY
and
Z.
Given
those
constraints,
can
you
do
bad
things
like
you
know,
I
agree
with
Gregg
like
if
it's
really
well
defined,
then
I
think
it
could
be
really
valuable.
G
D
I
think
I
think
that
documentation
needs
to
be
like
code
and
configuration
to
not
not
like
words
so
like
it
would
be
like
I'd.
Imagine
like
maybe
use
QAM
or
you
like.
You
have
like
a
defined
way
to
stand
up
the
cluster,
and
then
you
have
a
defined
application
with
exactly
like
those
kind
of
guarantees
that
you
would
explicitly
test.
Yeah.
E
E
I
My
proposal,
you
start
small
and
see
that
it
works
and
see
that
we
can
actually
define
something
small
and
go
from
there
pick
a
very,
very
small
scenario.
That's
reading
me
a
lot
of
work
to
define
and
then
the
appeal
also
look
at
thee.
The
other
thing
that's
figure
out
is
whether
the
standard
bug
bug
bounty,
triage
scales,
work
for
our
use
case,
so
the
standard
providers
out
there
I'll
have
a
scale
of
what
data
point
is
a
p0,
p1,
etc.
Those
are
usually
based
on
web
apps,
not
so
much
infrastructure
so
figuring
out.
G
Going
to
throw
out
another
idea,
it's
a
sort
of
a
way
to
frame
the
bug
bounty
as
through
cluster
conformance
if
we
could
create
a
conformant
suite
that
required.
Maybe
maybe
this
is
not
the
standard
conformant
suite,
but
another
level
of
security,
conformance
that
checks
that
you
have
all
these
security
features
enabled
and
then
say
bugs
are
valid
if
you
can
reproduce
them
in
a
conformant
cluster.
J
A
Yeah
I
think
there's
definitely
value
there,
because
the
the
impact
is
cross.
Big
I'm,
trying
to
figure
out
the
best
kind
of
venue
for
discussing
this
making
sure
it
has
the
right
visibility
like
if
we
all
say
yeah
this
sounds
great
and
then
it
goes
and
happens
and
then
suddenly,
like
eight
other
SIG's,
have
ten
things.
They
have
to
go
fix
urgently.
A
E
G
I
The
reason
the
reason
I
mentioned,
that
is
internally
Google.
We
have
some
standards
for
how
we
deal
with
with
certain
levels
of
party
bugs
there's
also
standards
for
the
project
zero.
So
if
project
zero
finds,
for
example,
a
p0
vulnerability
in
another
vendor
system,
depending
on
responsible
disclosure
agreements,
they
haven't
stuff,
like
that.
Sometimes
they
force
us
a
force.
They
strongly
suggest
that
the
vendor
disclose
that
within
a
week.
I
So,
for
example,
if
it
was
a
p0
vulnerability
in
cadiz
that
had
been
discovered
by
project
zero,
we
would
be
subject
to
the
same,
the
same
constraints
so
figuring
out
how
to
how
to
best
respond
to
some.
Some
of
these
vulnerabilities
in
general
should
be
something
we
figure
out.
You
know
right
now
with
the
the
set
of
people,
that's
emailed
on
that
security
list,
that
that
makes
sense,
but
if
we
hit
something
really
really
big,
how
do
we
get
out
that
message
soon
or
how
do
we
push
a
fix
much
sooner
than
that?
D
Yeah
I
think
that's
a
good
point.
I
I
think
our
next
step
is
to
kind
of
like
write
down
kind
of
what
what
this
might
look
like
and
and
share
that
back
and
yeah
I
take
the
point
of
like
it's
probably
needs.
It
needs
to
be
like
a
much
bigger
than
just
single
ass
kind
of
discussion
and
decision.
Cuz,
yeah,
I
I
would
hate
to
basically
sigilyph
ends
up
delegating
a
whole
lot
of
work
to
other
SIG's
that
they
weren't
expecting.
D
A
A
If
you
can't
create
deployments,
then
you
can't
bind
a
role
that
has
but
create
deployments
permission,
and
so,
as
long
as
you
are
living
fully
within
the
are
back
universe,
that
does
a
really
good
job
of
keeping
people
from
escalating
their
permissions,
but
where
it
gets
a
little
weird
is,
if
you
are
using
two
authorizers
and
so
gke
has
hit
this
where,
if
you're
a
super
user
from
GK's
perspective,
you
try
to
go,
create
an
are
back
role,
are
back
says:
well,
you
don't
have
this
permission
inside
this
role,
so
no
you
can't
do
that.
A
A
K
I
didn't
mean
to
like
shut
this
down
completely
I.
Think
it's
a
reasonable
workaround
to
ask
authorizers
whether
the
calling
user
is
a
super
user.
Our
authorizer
is
not
set
up
to
handle
that
question.
Currently
I,
there's,
probably
some
hackery.
We
could
do
to
figure
out
how
to
answer
the
star
dot
star
question
and
to
be
clear
that
what.
D
K
A
So
either
the
authorization
system
recognizes
star
as
a
special
thing
or
it
doesn't
if
it
recognizes
it
as
a
special
thing.
That
means
anything
then
great
or
on
the
same
page,
if
it
doesn't
recognize
it
as
a
special
thing,
which
means
anything,
then
that
would
mean
that
it
would
only
answer
true
if
they
had
explicitly
been
granted
like
a
literal
star
permission,
or
they
were
a
super
user
right.
K
Right
so,
for
example,
in
our
I
am
system,
there's
no
such
thing
as
a
star
permission.
There
are
ways
to
construct
roles
where
you
can
use
sort
of
star
like
language
that
include
all
you
know:
statically
defined
permissions
into
into
a
role,
but
the
the
asking
about
a
star
resource
or
a
star
permission.
Just
isn't
that
isn't
a
thing.
Okay,
so.
E
A
Possible
verb
and
resource
is
an
option
at
this
point,
like
people
can
define
arbitrary
new
resources
right
and
they
can
ask
arbitrary
new
verbs
like
you
can
now
score
such
like
us
review.
Can
you
educate
a
dolphin
to
you
go
back
to
my
favorite
example,
and
so
assuming
that
we
can
enumerate
everything
without
using
star
I,
don't
think
is
possible.
A
K
I
agree
and
I
think
it's
a
it's
a
philosophical
thing.
It
also
comes
down
to
our
back
having
a
different
concept
of
escalation
than
for
example,
Google
as
I.
Am
we
the
fact
that
I
have
the
ability
to
create
pods
and
Google's
I
am
does
not
imply
that
I
can
give
you
the
ability
to
create
pods
in
the
same
places?
The
only
thing
that
controls,
that
is
whether
I
can
set
policy
on
that
resource.
K
A
Would
it
make
more
sense
so
for
for
binding
roles?
We
actually
had
this
issue
originally,
and
we
let
you
bind
a
role.
If
you
have
all
the
permissions
in
the
role
or
if
you
have
the
bind
verb
on
the
role,
would
it
make
sense
to
go
that
route
instead
and
have
I,
don't
even
know
what
should
we
call
it?
That's
callate
mind.
E
K
I
mean
that
would
solve
our
problem.
I
think
that
would
make
the
this
transition
for
Google's
I
am
into
our
back
work
now.
I,
don't
know,
philosophically
philosophically
I
felt
nice
that
if
we
were
able
to
somehow
bridge
the
gap
by
saying
we're
doing
an
escalation,
we're
sorry
we're
doing
the
covers
check,
but
we're
doing
it
with
all
your
authorizers
that
felt
nicer,
but
digging
into
it.
I,
don't
know
if
it's
actually
possible.
It's.
K
J
One
problem
that
I
have
with
reusing
the
subject,
access
review
or
something
like
this-
is
that
you're
really
playing
double
duty.
What
you
really
want
is
a
new
type
of
call
which
is
like
subject
access
summary
or
something
like
that,
which
essentially
is
asking
the
authorization
system
to
to
provide
a
summary
in
terms
of,
like
you
know,
a
translation
from
one
type
of
description
to
another
type
of
description.
Sometimes
it's
going
to
be
possible.
J
A
I,
don't
think
it
was
I
think
it
was
attempting
to
use
the
existing
interface
that
we
have
for
asking
the
authorizer
questions,
and
even
within
that
there
are
two
ways
we
can
do
it.
One
is
trying
to
model
asking
about
a
super
user
permission,
and
the
other
is
trying
to
ask
a
specific
question.
Like
is
the
authorizer
okay
with
letting
you
escalate?
Our
back
rolls
so.
K
A
A
L
C
The
current
service
count
tokens
are
on
expiring,
but
they
are
bound
to
do
the
lifetime
of
certain
objects.
Actually,
they
are
only
bound
to
the
lifetime
of
service
accounts.
So
while
they
do
not
explore,
if
you
delete
a
service
account,
the
ID
tokens
that
was
issued
for
that
service
account
are
no
longer
valid
and
we
implement
that
by
embedding
in
the
weight
of
the
service
account
into
the
ID
token,
and
we
check
that
whenever
in
the
I've
been
authorized,
err
and.
A
C
C
C
Non-Expiring
tokens
with
the
new
authorizer
snow,
I
think
in
and
liggett
think
that
it
would
be
useful
to
be
able
to
support
non-expiring
tokens,
and
if
we
supported
both
of
these
functionalities,
we
could
have
a
drop-in
replacement
for
for
the
ID
tokens
that
we
currently
put
into
pods
as
the
default
service
kind
of
secret
I,
don't
know
how
that
plays
with
with
key
rotation
for
the
service
account
signing
ease.
So
if
our
objective
here
is
to
improve
service,
got
silent,
keys,
I
think
we
want
to
make
it
possible
to
implement
rotation
for
those
keys.
A
A
How
many
tokens
is
that
a
key
signed
are
still
in
use,
so
you
can
do
that
either
by
putting
a
expiration
time
on
them.
So
you
say
they
have
a
max
lifetime
of
whatever
30
minutes,
and
so
once
I
rotate
my
signing
keys
30
minutes
later
I'm
good
to
pull
the
old
key
out
of
out
of
rotation
as
a
valid
signing
key.
So
the
time
the
time
limit
is
one
way
to
do
it.
A
The
other
way
is
to
find
these
tokens
two
things
that
you
can
query
so
today,
they're
bound
to
service
accounts
and
secret
objects.
If
one
of
the
things
that
goes
in
the
secret
object
is
the
idea
of
the
key
that
signed
it,
then
you
can
look
and
see
how
many
non-expiring
but
bounds
to
secret
object.
Keys
tokens
are
there
that
were
signed
by
this,
and
you
can,
you
can
say:
are
they
are
they
still
in
use?
And
then
you
can
even
track
them.
C
A
If
it's
not
safe
to
remove
it,
because
you
still
have
active
tokens,
then
you
have
to
not
have
those
active
tokens
anymore
and
then
you're
into
sort
of
application
domain
rotation
problems
where
you
say
well,
I've
got
these
hundred
tokens
and
they're
used
by
these
pods
and
you're
kind
of
back
to
the
questions
that
we've
asked.
How
do
we
know
if
it's
safe
to
rotate
these
pods?
Can
we
set
up
a
new
token
and
then
like
redeploy,
we
restart
the
pod.
Can
we?
A
What
can
we
do
to
give
this
Auto
new
token,
and
if
it's
a
legacy
pod
that
doesn't
know
how
to
pick
up
new
tokens
and
is
expecting
it
to
be
valid
forever?
That's
going
to
be
really
tough,
but
at
least
you're
the
information
you
need
to
know.
What's
blocking
me
from
rotating
this?
Oh
these
tokens
used
by
these
pods
so.
C
I
want
to
I
would
like
to
bound
the
complexity
of
that,
and
it
seems
like
that.
If
we
do
allow
non-expiring,
I
tokens,
people
are
going
to
hold
on
to
them
forever
and
people
are
going
to
be
much
less
likely
to
implement
rotation
in
their
cluster
or
turn
it
on
which
I,
don't
think
is
I.
Don't
think.
That's
desirable.
A
C
A
Versions
rotation
starts
to
come
on
and
if
your
cluster
is
running,
things
that
depend
on
eternal
tokens,
never
expiring.
You
can
turn
off
that
feature
but
defaults
matter,
and
if
the
feature
becomes
available
and
usable
and
client
go
gets
updated
to
pick
up
new
tokens
and
the
thing
is
sort
of
using
the
the
in
cluster
config
and
client
go
clients
that
we
set
up
would
take
advantage
of
token
rotation.
A
C
So
what
does
that
mean
for
the
API
I
guess
my
specific
concern
is
I.
Don't
really
want
to
allow
a
client
to
request
a
non
expiring
token
from
this
API
forever.
I
think
it's
valuable
as
like
an
intermediate
I
think
it's
a
valuable
feature
for
the
next
six
months.
But
how
do
we
remove
functionality
like
this
in
six
months
or
a
year,
however
long
it
takes
to
move
clients
over
to
a
client?
Go
that
a
supports
rotation.
A
G
C
Yeah
I
had
also
entertained
the
similar
ideas
it.
It
does
seem
like
a
cluster
administrative
decision.
I
want
to
I.
Guess
how
do
we
get?
How
do
we
provide
like
a
reasonable
window
for
cluster
administrators
to
perform
the
migration
and
like
how
do
we
get
people
to
actually
do
the
migration
eventually
so
I
think
the
best
way
to
do
that
is
to
deprecate
the
old
format
and
remove
it
in
a
year.
A
A
C
Is
different
than
never
expiring,
so
it's
not
any
real
practical
sense,
I,
yet
I
think
in
a
practical
sense.
They
are
because
you
know,
if
I
have
an
ID
token
that
is
like
valid
for
three
months.
I
know
that
I
can
safely
pull
pull
a
signing
key
every
six
months
or
have
a
two
on
rotation
that
that
key
is
only
valid
for
six
months.
A
G
C
G
D
I
think
humans
are
generally
really
bad
kind
of
very
infrequent
things
with
like
big
consequences.
You
know
like
you
can
imagine
like.
So
if
my
workflow
is
like
I
get
a
thing
for
six
months
and
that's
and
then
I
go
prune
in
my
CI
CD
system
and
I
have
to
set
a
calendar
reminder
to
remind
myself,
and
you
know
what
that's
definitely
like.
That's
just
that's
just
asking
for
failure
like
that's.
That's
a
really
predictable
kind
of
failure,
mode
everything.
C
A
Interesting
I,
if
the
timeline
is
long
enough,
switching
what
the
Qibla
generates
for
point
of
views
to
expiring
like
it.
If
you
run
a
pod
and
it
gets
restarted,
I
guess
we
can't
make
assumptions
about
a
pod,
restart
being
necessarily
safe
depending
on
whether
it's
replicated
and
that
gets
really
tough
I
mean
if
the
lifetime
is
like
a
year
or
six
months
or
something
are
you
expecting
people
to
upgrade
their
clusters
and
you
know
drain
and
reload
and
upgrade
their
couplets
every
few
months
or
every
few
years
good.
A
We
start
making
reasonable
changes
from
non-expiring
to
expiring
for
the
point
of
use,
ones,
API,
wise,
I
think
you
still
have
to
be
able
to
request
non-expiring
ones,
but
if
the
cubelet
at
the
point
of
use
generation
started
requesting
expiring
ones
that
were
really
long-lived
and
an
administrator
could
crank
that
down
shorter
if
they
wanted
to
or
an
application
could
do
something
in
a
pod
that
could
indicate
yeah
I
can
handle
rotation,
make
it
really
short,
I
think
that's
how
we
move
it.
So
API.
E
C
Okay
yeah,
so
I
had
imagined
that,
like
we
would
want
to
when,
when
we
flipped
this,
we
would
want
to
rotate
keys
every
few
days,
so
potentially
keep
non-expiring
tokens
around.
We
can
make
them
individually
revocable
by
attaching
embedding
youĂd
of
a
service
account,
and
also
you
would
of
like,
should
we
do
like
a
you
it
of
an
empty
secret.
A
G
If
I'm,
not
understanding
everything
everybody,
if
part
of
the
problem
areas,
we
want
to
rotate
the
route.
Signing
key
for
service
account
tokens,
but
we
have
these
tokens
that
live
forever,
that
we
don't
it
they
live
in
some
third
system.
We
don't
necessarily
have
the
ability
to
automatically
add
ematic
lee
rotate.
Why
do
those
tokens
need
to
beast
and
it
sort
of
embedding
state
and
we're
saying
every
time
we
validate
one
of
those
tokens,
we're
checking
it
against
a
you,
ed
and
a
secret?
Why
do
we
bother
with
the
root
key
right?
G
C
C
A
New
options
to
the
API
server
for
the
signing
keys,
because
the
option
you
have
today
is
something
people
can
give
public
keys
to.
So,
if
you
want
to
enable
this
as
an
API,
you
have
to
tell
it.
You
have
to
now
tell
the
API
server
here's
the
signing
key
to
use,
and
so,
if
you
have
one
of
our
expiring
and
one
for
non-expiring,
that's
interesting,
but
could
let
you
do
that
I.
G
The
problem
where
you
almost
ran
out,
you
don't
want
to
have
creating
a
secret
in
a
namespace,
just
sort
of
magically
generate
an
identity
in
the
namespace,
but
what,
if
so,
this
over
the
fact
that
there's
a
secret
in
a
namespace
with
a
UID
and
that's
the
thing
we're
checking
against
also
feels
like
an
implementation
artifact?
Do
we
also
solve
this
problem?
That's
instead
of
having
that
secret
with
a
UID
live
in
a
namespace.
We
keep
that
bit
of
state
in
a
cluster
scoped
object.
Somehow
I
would.
B
G
G
B
A
We
they're
pros
and
cons,
given
that
there's
nothing
actually
confidential
in
the
record.
It's
just
a
sort
of
marker
so
that
you
can
see
that
it
exists
and
you
can
revoke
it,
but
it's
not
that
it
doesn't
actually
contain
anything
confidential.
That's
it
wouldn't
bother
me
for
it
to
be
a
non
secret,
a
new
resource.
A
C
G
C
G
A
With
expiration
dates
and
I
know
we're
running
out
of
time
what
we
can
wrap
this
up,
I
would
still
expect
it
to
be
bound
to
something
that
can
be
deleted
so
generated
for
use
with
a
pod
and
have
the
pod.
You
would
as
a
claim,
and
if
you
delete
the
pod
you
would
then
you
can't
use
that
joking
against
the
API
like
whether
it's
a
secret
or
pod
or
something
like
I,
would
expect
these
to
be
bound
to
bounce
to
things
that
can
be
deleted.
You
know
so.
B
A
L
In
what
case
would
you
want
a
secret
to
actually
be?
Let
me
rephrase
that
why
do
you
ever
want
service
accounts
to
store
their
token
in
a
secret?
What
does
that
give
you
I
know
you
want
to
be
able
to
in
an
object
to
delete
things.
Fine
I
agree
with
that
part
now.
I
agree
with
trade
and
everyone
in
the
secret.
It's
really
annoying,
and
now
getting
access
to
secrets
means
you
also
get.