►
From YouTube: Kubernetes SIG Auth 2020-06-10
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 2020-06-10
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/preview
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
Cool,
hey
everyone.
This
is
the
sig
auth
meeting
for
june
10th
2020.,
not
that
much
on
the
agenda,
but
let's
get
started.
So
I
wanted
to
point
out,
for
the
pulls
of
note.
Jordan
has
been
doing
a
lot
of
work
on
getting
the
csr
api
ready
for
v1,
and
I
see
that
a
lot
of
the
stuff
that
he
had
open
has,
I
think,
since
merged
on
the
call.
A
Did
you
want
to
point
out
anything?
Is
there
anything
in
particular,
you
need
assistance
on.
I
know
you
need
people
to
go
review
stuff.
B
I
think
it's
actually
david
and
runners,
and
you
and
sean
did
a
pretty
good
job,
reviewing
stuff
from
cube,
control
and
controller
and
stuff.
So
after
this
pr
is
in,
we
actually
will
have
like
all
all
the
pieces
needed
to
do:
end-to-end
v1
apis,
which
is
pretty
cool,
so
the
the
conformance,
the
only
ci
job
we
can
flip
to
actually
only
ga
features
and
apis,
which
is
awesome,
hey
awesome.
How
many
years
did
this
take.
A
Too
many
awesome.
Okay,
do
you
do
you
need
anything
in
particular
from
anyone
on
this?
Are
we
good
to
make
sure
we
get
csr
to
v1.
B
It's
on
a
good
track.
I
think
the
next
step
will
be
sweeping
the
in-progress
documentation
pr.
So
I
will
probably
ping
the
channel
to
see
if
anyone
wants
to
help.
There
are
two
or
three
pages:
one
is
sort
of
cluster
admin
facing
one
is
user
facing.
A
This
otherwise
for
119,
the
other
thing
that
you
guys
can
remind
me
if
I'm
forgetting
the
other
bit,
was
trying
to
get
exec
to
ga
we'll
see.
If
that
happens
in
terms
of
pr's
that
are
open.
A
I
have
one
open
for
wiring
in
the
cluster
information
andrew
had
one
for
the
install
hand,
andrew's
had
one
open
to
fix
a
bug
in
relation
to
like
token
interaction,
we
we
need
to
do
dox
prs
to
update
docs,
to
line
up
with
what
the
cap
actually
says
is
the
api,
as
well
as
in
like
there's
outstanding
tests
that
need
to
be
written,
and
the
api
actually
has
to
be
reactive,
e1.
A
I
can
link
in
there.
I
have
a
issue
on
kkk.
That
is
where
I
wrote
down
all
the
things
that
were
left
so
yeah
I'll
link
that
and
I'll
update
from
gender
to
have
that
I'm
a
little
skeptical.
We
can
get
all
of
this
in
for
119,
mostly
because,
like
there's
a
significant
amount
of
testing
that
I
think
is
still
left
as
like
part
of
the
ga
requirement.
A
So
it's
all
right.
If
it
doesn't
make
it,
it
doesn't
make
it.
But
we
know
what
we
need
to
do
and
I
don't
think
there's
like
outstanding
like
I
want
this
api
to
do
this
thing
and
it
doesn't
do
it
so
that's
there.
A
I
think
we
can
go
on
to
discussion
topics
now.
I
will
actually
hold
mine
for
a
bit
mostly
because
it
might
take
up
the
whole
time
or
maybe
not,
and
I
was
going
to
let
liz
and
like
aiden.
C
That's
good
to
know
yeah
so
hi
there,
I'm
aiden,
I'm
a
anchor
on
a
engineering
team
and
we're
doing
a
little
bit
of
research
into
kate's
secrets
partially,
because
we
want,
we
see
a
little
bit
of
a
gap
there
around
the
generation
of
certain
secret
types
and
the
rotation
of
them
on
the
platform,
and
we,
when
digging
into
them,
we
we
did
notice
that
there's
a
couple
of
extra
secret
types
that
are
not
really
well
documented,
such
as
like
basic
auth
or
tls,
or
things
like
that.
C
B
Yeah
so
so
the
secrets
are
just
sort
of
a
bucket
of
bytes
they're,
not
structured,
there's.
No,
it's
just
key
value,
you
know,
and
so
whatever
meaning
those
keys
and
those
values
have
has
to
be
agreed
on
between
the
thing
producing
a
secret
and
the
thing
consuming
the
secrets,
and
so
the
secret
type
was
a
way
to
identify.
B
A
particular
sort
of
agreed
on
meaning
for
keys,
so
the
it
may
have
been
the
first
one,
probably
the
first
one
was
the
service
account
secret.
So
if
you
have
a
secret
that
is
of
type
kubernetes,
io
surface
account.
B
The
thing
generating
that
is
going
to
create
three
keys,
a
namespace
key,
a
ca,
dot,
cert
key
and
a
token
key,
and
it's
going
to
populate
those
with
the
current
namespace,
a
certificate
bundle
to
talk
to
the
api
server
and
a
token
credential
to
use
against
the
api
server,
and
so
the
the
type
lets
someone
who's.
Reading
the
secret
understand
what
keys
it
can
expect
and
what
the
meaning
of
those
keys
are
and
for
a
controller
that
is
going
to
be
maintaining
that
secret
or
listing
filtering.
B
B
We
required
that
the
credentials
associated
with
a
particular
volume
provisioner
have
a
secret
type
that
indicated
it
was
for
that
provisioner
and
the
goal
there
was
to
make
sure
that
the
person
who's
putting
data
into
this
secret
intends
that
data
to
be
used
for
volume,
provisioning
purposes
and
sent
to
this
volume
provisioner.
And
so,
if
you
look
at
the
the
persistent
volume
provisioner,
it
will
follow
the
reference
to
to
grab
the
data
out
of
the
secret
to
use
those
credentials.
D
A
D
That
you
can
describe,
I
have
one
secret
that
can
fulfill
these
different
things.
I
have
a
tls
key
and
a
cube
config
in
me.
Right
like
there
are
many
times
I
wish
I
had
a
config
secret
type
because
it's
pretty
common
right.
There
are
also
times
I
wish.
I
had
a
similar
field
on
config
maps
to
say
this
one
contains
ca,
bundles
and
a
well-known,
a
ca
bundle
in
a
while
location.
D
B
Right,
that's
the
thing:
it's
a
convention.
It's
not
enforced
server
side
generally,
certainly
not
for
types
that
aren't
kubernetes
specific.
A
A
This
kind
of
vaguely
rates-
I
I
haven't-
had
a
chance
to
actually
read
the
pr
such
issues.
Someone
had
opened
up
something
about
adding
to
the
tls
seeker
type,
a
field
for
ca,
and
I
just
hadn't
had
a
chance
to
think
about
it
or
even
figure
out
what
the
use
case
was,
but
it
sort
of
is
related
to
like
growing
things
over.
B
The
yeah,
let
me
know
if
there
are
other
questions
or
anything
else
that
would
be
helpful,
and
if
we
want
to
fold
some
of
this
explanation
back
into
the
field,
documentation
that
that
could
be
fun.
C
A
A
More
more
intent,
yeah
yeah,
I
think
odyssey's-
probably
wrong,
but
like
I
don't
think
any
of
that
hurts.
But,
as
we
mentioned,
all
of
this
is
convention
right.
Nothing
is
being
enforced
unless
you
go
in
force
of
using
some
kind
of
admission
yourself,
which
you
could
there's,
there's
no
reason
that
if
you
have
a
controller
that
manages
a
particular
type
that
it
can't
also
be
bundled
with
matching
admission.
C
Thank
you.
So
even
I
know
liz
is
here
and
jake's
here
as
well.
Do
you
have
any
other
questions
on
that.
E
E
B
See
a
lot,
the
issue
that
moe
mentioned
around
some
of
the
use
for
tls
bits.
I
think
a
couple
of
the
ingress
controllers
had
types
mentioned
in
their
documentation,
but
I'm
not
quite
sure
like
a
like
sort
of
a
secret
that
they
expected
to
have
not
just
a
certificate,
but
also
maybe
a
bundle
for
use.
Doing
client
validation.
B
A
This
is
more
of
a
question
to
say
long
term.
Do
we
see
some
path
of
like
having
a
more
like
a
stronger
story
on
storing
secrets
in
crds
like
things
around
like
encryption
at
rest,
because
if
you,
if
you
like,
I
would
not
suggest
to
folks
like
on
the
call
that
you
should
start
making
like
a
custom
crd
type
for
a
different
kind
of
secret,
because
as
far
as
I
know
today,
you
can't
target,
like
various
compliance
requirements,
to
make
sure
that
at
rest,
those
secrets
are
correctly
protected.
A
B
D
On
that,
but
connection.
B
D
A
David
on
the
api
machine
here,
but
did
you
you
guys
like
sort
of
write
down
what
some
set
of
things
you
were
happy
with,
like
just?
Was
it
just
like?
The
idea
was
okay
and
then
it
was.
It
was
that
the.
D
Idea
was
okay
right
that
you
could
have
the
notion
of
confidentiality,
and
it
was.
There
was
a
question
about
whether
it
would
be
something
just
on
a
crd
or
whether
it
be
exposed
via
discovery,
since
there
are
auditing
implications
right
and
then
whether
keys
themselves,
like
the
the
names
of
the
types,
were
confidential.
D
In
addition
to
the
contents,
because
for
audit,
the
name,
if
the
name
being
confidential,
causes
problems,
tracking
metadata,
obviously,
for
storage
for
storage,
since
the
keys
themselves
and
lcd
are
not
encrypted
just
the
content,
as
I
recall,
you're
permanently
facing
problems.
A
B
D
Been
a
very
long
time,
I
think
it
was
fairly
quick
in
terms
of
like
doing
is
reasonable
yeah,
it's
probably
reasonable,
we'll
devote
review
time
to
it.
Probably
would
we
devote
development
time
to
it?
A
F
Yeah,
thank
you,
I'm
bruce.
I
I
work
with
aiden
and
liz
and
the
credit
team.
One
thing
about
those
those
types,
those
secret
types
that
I
had
in
mind
was
that
my
first
thought
is
that
I
don't
like
too
much
that
they
contain
non-secret
information
like,
for
example,
there
are.
There
is
the
type
that
like
has
a
username
and
a
password,
and
I
I
wish
it
was
formatted
in
a
different
way
or
organized
in
a
different
way
that
the
username
is
not
in
the
secret
table.
F
Okay,
one
of
the
arguments
that
I
have
is
that
I've
seen
people
getting
confused
so,
for
example,
my
main
example
is
the
like
credential,
sorry,
private,
key
and
certificate
thing.
People
are
not
too
familiar
with,
you
know
like
public
key
cryptography
or
with
certificates,
and
so
they
see
this
thing
and
it's
like.
Okay,
all
this
stuff
is
private,
and
then
we
tell
them.
No,
no
certificates
are
actually
a
public
thing.
B
Yeah,
I
I
think
it's
like
ease
of
use
coherence
of
configuration
being
able
to
refer
to
a
single
object
instead
of
two
objects.
I
mean
if
so,
this
one
wants
to
create
separate
like
a
config
map
to
hold
their
certificate
in
the
secret
to
hold
their
private
key.
They
certainly
can,
but
is
that
I
don't
think
it's
particularly
important
to
distinguish
between
those
just
in
the
interest
of
time.
I
know
it's
like
225
and
we
do
have
several
other
things
on
the
agenda.
B
So,
like
there's
discussion
about
like
how
to
use
secrets,
maybe
that
would
be
a
good
thing
to
take
offline,
so
we
could
be
sure
to
get
to
the
other
items.
A
Cool
all
right,
all
right.
G
Okay,
that's
me,
can
you
hear
me.
A
G
So,
a
little
bit
of
background
in
118,
the
service
account
issuer
discovery,
feature
gate
was
added
to
the
api
server
which,
which
adds
open
id
connect,
discovery
endpoint
to
the
api
server,
and
normally
there
is
no,
for
example,
a
row
binding
associated
with
it
and
normally
then
then
users
have
to
add,
for
example,
the
authenticated
users
or
sorry
anonymous
users
in
order
to
be
accessible
by
everyone.
G
However,
if
the
anonymous
authentication
flag
set
false
to
the
api
server,
it's
not
actually
possible
to
access
in
any
means,
and
the
main
problem
is
that
a
lot
of
client
libraries
are
already
using.
I
mean
they
assume
that
that
this
point
endpoint
is
not
behind
any
authentication
or
authorization,
and
a
lot
of
those
has
have
to
be
changed.
G
So
my
question
is:
is
there
any
possibility
to
work
around
around
to
work
around
this
thing
without
disabling
this
slack
or
just
put
a
proxy
or
something
in
front
of
it
or
some
other
idea?
Yeah
the.
B
If
anonymous
requests
are
disabled
on
the
api
server,
we
honor
that
by
not
allowing
any
anonymous
requests
to
the
api
server.
The
the
feature
was
designed
so
that
in
cases
where
you
don't
actually
want
discovery
clients
pulling
from
your
api
server,
you
can
host
the
discovery
document
somewhere
else.
B
So
you
could
have
something
that
connected
to
the
api
server
in
a
credentialed
way
pulled
out
like
the
key
set
information
and
the
information
it
would
need
to
build
and
serve
the
discovery
dock,
and
then
it
could
serve
it
from
a
url
of
your
choosing.
That
url
would
need
to
correspond
to
the
issuer
url
that
you
select,
but
if
you
have
a
server
that
you
really
don't
want
to
expose
to
anonymous
requests,
then
choosing
a
different
location
to
host
your
discovery.
Documents
is
probably
what
you
would
want.
A
To
do
yeah,
I
think
what
this
comes
down
to
is
in
order
to
sort
of
use
this
feature
you,
you
have
to
sort
of
coordinate
with
the
person
running
the
api
server.
You
you
at
least
in
the
anonymous
case
like
if
you
are
able
to
configure
like
so
like,
for
example,
it's
the
endpoint
is
accessible
by
default
by
all
service
accounts.
So
if
you
are
able
to
send
a
bearer
token
for,
like
your
pod
service,
account
you'll
be
able
to
read
this
endpoint
but
yeah.
A
If
the
the
case
says,
I
have
a
client
library
that
I
cannot
update
and
it
assumes
just
anonymous
access
to
this
metadata.
Endpoint
yeah.
Your
real
only
choice
is
coordination
between
whoever
set
up
the
api
server
and
whoever
wants
to
consume
this
endpoint,
because,
no
matter
what
they
would.
Even
if
you
want
to
host
this
thing
elsewhere,
almost
all
client
libraries
when
they
ask
the
issuer,
sorry
like
when
they
fetch
the
issuer,
url
the
when
they
read
the
document.
A
G
I
actually
found
this
when
I
was
trying
to
connect,
for
example,
one
api
server
to
another,
so
the
one
api
server
is
actually
trusting
the
other
one
and
it
was
not
possible
because
the
first,
let's
say
the
let's
say,
the
master
api
server,
which
which
is
going
to
be
trusted
by
the
rest,
is
not
I
mean
it.
You
cannot
actually
configure,
for
example,
to
keep
api
server
to
talk
to
the
to
the
to
the
discovery
endpoint
with
like
bearer
token
or
something
like
this.
B
Yeah,
so
the
options
there
are
to
allow
the
discovery
doc
to
be
fetched
anonymously
on
the
server
that
you
want
to
point.
Other
servers
at
that's
one
option:
the
other
is
to
host
an
anonymous
anonymously,
accessible
discovery,
endpoint
and
pull
the
information
you
want
from
whichever
api
server
you
consider
the
authority
or
the
root
of
trust
and
construct
the
docs
that
would
be
served
in
that
I've
seen
things
use
like
publicly
available
buckets.
B
You
know
there
are
different
options
for
where
you
can
host
that
one
nice
thing
about
doing
that
is.
It
means
that
your
api
server
is
no
longer
in
the
critical
path
for
things
that
want
to
verify
tokens
right.
So
there
are
actually
some
benefits
to
extracting
and
hosting
the
discovery
information
in
a
maybe
a
more
available
or
a
more
accessible
location.
G
A
Okay,
I
think
all
we
have
left
now
is
the
csr
stuff,
so
I
had
written
this
up
down.
I've
been
kind
of
thinking
and
playing
around
with
the
csr
api
recently
just
kind
of
going
through
some
things
and-
and
I
like
mike,
I
had
conversations
with
you
as
well
kind
of
related
to
eks,
so
some
of
the
things
that
kind
of
came
up
to
mind
a
sort
of
obvious
one
like
the
last
one
is
kind
of
something
I'm
wondering
if
you
want
to
try
to
address
is
so
mike.
A
If
I
understand
it
correctly,
any
cass,
you
guys
don't
plan
on
any
support
for
the
client
cert
based
approach,
which
is
perfectly
valid
today.
You
know
because
we're
sorry
in
older
versions
of
cube
before
we
had
the
signer
name,
you
know
there
was.
There,
was
sort
of
one
no
way
to
indicate
that
you
were
going
to
refuse
to
sign.
The
client
could
just
wait
for
some
amount
of
time
and
give
up
or
whatever
and
two
like.
If
you
use
the
default
sign,
it
will
go
ahead
and
sign
it.
A
If
everything
is
fine,
you
know
after
it's
been
approved,
but
it
won't
work
because
you've
purposely
not
configured
the
trust
that
way.
A
So
I've
been
thinking
like
how
do
you
make
the
case
of
like
I
want
to
use
the
default
signers,
and
I
don't
want
to
support
a
subset
of
them
without
necessarily
having
to
like
wholesale
right,
like
like,
like
basically
today,
like
the
easiest
thing,
if
you
don't
want
to
support
a
particular
signer,
is
wait
for
david's
pr
on
the
like
per
signer
keys
and
stuff
and
give
it
a
key
that
isn't
like
trusted
with
anything
and
thus,
when
it
signs,
it
won't
work
and
it
stays
out
of
the
way
right
like
because
that
requires
no
code.
A
Yeah,
so
you
could,
you
could
have
an
admission
web
hook
to
reject
that
that
is.
That
is
an
approach
you.
You
can
also
have
a
custom
custom
signer
to
deny
explicitly
as
the
new
api
fields
allow
you
to
explicitly
say.
I
refuse
to
sign
this
for
you.
I
I
guess
the
the
bit
I'm
trying
to
address
is.
A
D
A
We
don't
have
the
way
to
statically
configure
dynamic
admission
outside
of
the
api
server
yet
and
so
like
you
would
have
to
deploy
it
on
the
api
server
like
you
would
have
to
create
a
cube
api,
and
I
think
there
is
some
desire
to
have
like
things
that
are
enforcing
on
the
cube
api
without
literally
present
in
the
cubic
yeah
kind
of
like
the
stuff,
that's
burned
into
the.
A
A
B
B
B
B
A
Yeah
yeah
so
like
the
way
I
was
thinking
about
it
is
like
you,
you
know
you
can
choose
to
use
a
signer
or
you
can
choose
to
use
a
signer,
but
have
it
configured
in
a
way
that
it
will
automatically
deny
the
incoming
stuff
without
signing
it.
As
a
way
of
saying
like
on
this
platform,
this
is
yes,
we
know
this
is
a
built-in
kubernetes
signer.
You
might
expect
it
to
work,
but
we
are
very
obviously
telling
you
it
will
not
work
here.
A
So
you
know
like,
instead
of
requesting
a
client
start
approving
it
and
getting
it
back
and
then
trying
to
use
it
against
the
cube
api
or
see
if
it
works.
You
know
real,
close
and
upfront
that,
like
it's
not
supposed
to
work
well,.
D
So
I
guess
I'm
trying
to
figure
out
what
what
broke
along
the
way
to
get
us
here
right
like
it's,
this
these
signer
names
they
can
be
anything
so
in
the
future.
We
may
choose
to
add
more
cube
ones,
configuring
it
so
that
they
actually
get
signed
at
all
via
the
stock
cube
controller
manager.
Even
using
the
stop
cube
controller
manager
for
some
of
them,
you
don't
you,
don't
have
to
sign
with
anything
valid.
As
you
said,
you
could
also
simply
turn
off
that
entire
controller
and
use
some
other
mechanism
to
manage
it.
D
A
The
I
think
the
novel
one
would
be
the
idea
that
you
can
have
a
controller
active
but
you're
actually
telling
it
not
to
do
its
normal
job
you're
telling
it
to
go.
Why
would
it
be
active
at
all
right
like
if
you,
if
you
had
them
separately
named?
Why
would
you
turn
on
the
one
for
clients
yeah?
You
could
not.
You
cannot
turn
it.
You
could
make
it
so
it's
not
turned
at
all
and
then
the
client
would
just
issue
a
csr
and
it
might
even
get
approved
and
then
nothing
will
happen.
B
Easy
we
do
garbage
collect
today,
non-sign
certificates.
D
If
you
have
a
lot
of
notes
and
they
they
retry,
they
read
they
retry.
It's
painful
ask
me
how
I
know.
H
B
I
B
So
the
the
things
that
the
inputs
changed
is
what
you're
saying
so
yeah
I
I
guess
I
would
ask
like
cubelets:
don't
do
those
by
default,
like
you
have
to
ask
them
to
rotate
and
request.
D
Figured
or
it
I
mean
this-
this,
it
was
partly
our
own
making
like
we.
We
had
a
custom
signer,
because
we
didn't
want
to
sign
client
certs
right.
We
only
wanted
to
sign
serving
certs,
and
then
we
also
in
that
thought.
Okay,
let's
only
sign
x,
509
x,
like
sans,
for
domains
we
can
validate
on
nodes
because
we're
auto
approving
nodes
so.
D
So
it
I
mean
it's
caused
a
lot
of
like
pain
for
us
just
to
have
to
like
have
custom
code,
and
then
it
it's
not
exactly
like
upstream
and
then
there's
all
these
there's
these
assumptions
that
we
weren't
like
aware
of
and
then
we
get
burned.
So
that's
that's!
D
A
B
For
the
serving
certificate
feature
in
particular,
I
was
not
promoting
that
to
ga
this
release
because
they
were
like
the
api
I
think,
is
sufficient
now,
but
the
some
of
the
things
like
what
you
mentioned,
like
the
behavior
when
the
sands
don't
match
and
like
what
do?
We
even
recommend
people
do
to
decide
whether
they
should
approve
these
like
we
don't
have
a
built-in
improver.
So
I
wanted
to
take
some
time
to
get
feedback
on
that.
B
So
it
sounds
like
you
have
good
feedback,
so
maybe
we
could
at
least
strengthen
documentation
about
like
what
the
behavior
is
and
then
maybe
think
about
ways
to
make
the
cube
not
lose
its
mind
and
probably
for
like
120.
If
we
can
tighten
that
up
and
document
that
and
maybe
put
some
safe
cards
in.
B
B
So
like,
as
a
for
the
specific
question
I
would,
I
would
support
being
able
to
individually
address
designers
that
are
built
into
the
cube
controller
manager.
I
I
don't
have
a
problem
with
that.
I
probably
won't
have
time
to
go,
do
that,
but
if
someone
wanted
to
do
that,
I
I'm
not
opposed
to
it
for
some
of
the
more
sort
of
involved
like
automatically
reject
with
a
message
and
like,
I
think
I
would
probably
lean
on
admission
types
of
things,
oppa
or
types
of
things
for
more
particular
feedback
to
a
user.
D
To
your
environment,
I
will
say:
if
someone
wants
to
implement
that,
I
would
like
to
see
it
be
the
case
that
the
existing
controller
name,
if
someone
had
had
tried
to
disable
the
csr
controller.
I
would
like
that
to
continue
to
be
honored,
which
means
it's
not
a
perfectly
straight
replacement,
but
it's
still.
A
Possible
the
way
we
control
like
the
status
and
improve
sub
resource
of
csr.
You
couldn't
have
like
an
admission.
You
could
have
an
admission
plug-in
to
deny
the
csr
right
like
flat
out,
reject
the
creation,
but
you
couldn't
have
it
like,
like
in
requests
like
update
the
status
to
be
like
the
specific
deny.
If
it
denies
the
creation,
then
you.
B
A
A
No,
I
know
it's
more
of
like
the
the
way
the
api
is
written.
You
know
it's
more
of
like
you,
create
a
csr
and
you
see
based
on
status
with
someone
approving
or
not
approving
it
right.
It's
now,
it's
more
like
you
create
a
csr.
The
creation
fails
see
if
the
creation,
like
failure,
reason
is
one
that,
like
is
a
network
error,
because
something's
flaky
and
you
retry,
or
it's
like
the
admission.
D
Like
if
the
person
requesting
the
csr
and
the
consumer
of
the
csr
are
different
or
if
the
entities
are
different,
but
I
think
no
matter
what
you
chose
to
do,
you
would
have
to
choose
one
or
the
other,
and
so,
if
you're
gonna
write
one
thing,
you
could
just
choose
to
write
something
different
instead
right
like
if
you
wanted
to
allow
it
to
be
created,
you
could
just
explicitly
deny
now
right,
like
you
allowed
to
be
created
and
then
just
come
in
and
say
no,
this.
This
can't
be
issued
or
approved.
A
Yeah,
I
think
we
probably
beat
that
one
again,
some
other
stuff
that
I've
been
kind
of
poking
around
at
is.
I
was
trying
to
see
like
when
I
asked
for
a
cert
from
one
of
the
signers,
how
long
it
would
last
and
for
somehow
I'd
forgotten
that
the
default
was
one
year
and
I'm
I'm
trying
to
figure
out
one.
Why
we
have
that
really
long
default
and
two
and
like
what
environment?
Is
it
safe
to
hand
out
an
irrevocable
client,
cert
credential
for
the
api
against
the
api
server
for
a
year.
A
A
D
A
Yeah
yeah,
so
I
understand
that
it's
just
that,
like
none
of
that
tells
me
like.
I
should
do
this
as
the
default
right
that
doesn't
seem
like
like,
if
you
just
imagine,
you
have
vanilla,
cube
and
you're
running
it
like
it'll
issue
flight
and
you
either
incorrectly
or
correctly
wired
up
the
ca
bundles,
depending
on
how
you
think
about
it.
The
default
behavior
is
like,
if
I
I
think
cuba
adm
reuses,
the
same
ca
bundle
across
like
all
the
stuff
right.
J
A
All
clients
or
credentials
right
so
like
how
do
we
make
like
the
default
like
sane
and
safe,
like
like
in
my
head,
I'm
trying
to
figure
out
like
how
we
make
this
quick
gun,
not
so
obviously
broken.
A
D
Like
why,
wouldn't
we
control
it
by
the
deployment
mechanism
stance
right
like,
for
instance,
a
deployment
mechanism
could
say?
I
only
want
these
to
live
for
two
weeks
and
that's
just
my
stance.
A
different,
a
different
deployer
could
decide.
You
know
what
I
like
the
idea
of
a
year,
so
I'm
going
to
make
my
stuff
last
for
two
years,
but
so
that
that
part.
A
Is
fine
david,
it's
more
it's
more
of
like
today!
If
you
do
nothing,
you
choose
a
year
with
no
necessarily
understanding
of
what
that
means
right.
I
I
think
very
few
people
would
actually
feel
comfortable
if
you
told
them
that
this
api
lets
you
issue
out
credentials
that
are
irrevocable
and
they'll.
Last,
for
you.
A
D
J
A
A
A
I
I
fairly
admit
this.
Thank
you
for
that,
but,
like
so
I
know
in
traditional,
like
ca
infrastructures,
the
signer
always
controls
the
the
length
right
and
certainly
I
I
think
it
should
always
control
the
max
length
because
it
gets
to
decide
whatever
it's
comfortable
with
but
like
is
there
a
space
for
a
client
to
say
like
like
and
really
what
I
mean
a
client
here.
Is
I
mean
a
client,
that's
provisioning
credentials
for
someone
else
is.
A
D
A
A
Don't
trust
that
right
and
if
the,
if
the
answer
is
in
any
of
those
cases,
you
must
go,
build
a
custom,
signer
and
somehow
like
put
an
annotation
on
the
csr
when
you
create
it
and
this
custom
designer
observes
that
and
does
something
I
mean
that,
like
in
that
world,
I'd
rather
just
be
the
the
client
serving
ones
just
not
being
able
by
def
like
like
ever
like
you.
You
must
explicitly
enable
them
and
opt
into
using
them
and
understand
what
their
properties
are,
because
they're
just
dangerous.
H
So
the
nice
thing
about
rotating
the
root
is
that
you
can
pause
it
if,
for
whatever
reason,
rotation
infrastructure
is
broken,
you
can
wait
for
all
clients
to
reprovision
certs
and
then
make
a
decision
to
go
or
no
go
based
on
having
a
ticking
time
bomb
with
with
either
cereals
or
short
short
lived
search.
H
There's
definitely
a
happy
medium
in
there
but
too
low,
and
you
you're
really
cutting
into
what
you
can
actually
support.
If
pki
goes
down.
A
Yeah,
I
know
I
mean
I,
I
think
mike
what
you're
referring
to
is
like
the
epoch
approach.
Right,
like
google,
has
a
lot
of
it's
the
infrastructure
right,
your
system
posts
when
the
infrastructure
is
down
because
the
epoch
hasn't
changed.
So
all
the
search
for
a
particular
epoch
are
still
valid
right.
H
Yeah,
it's
basically
equivalent
to
routes
signed
for
10
years
that
rotate
every
couple
days.
A
Yeah
I
mean
like
maybe,
if
cube
did,
that
by
like
default,
somehow
like
right
actually
like,
like
you
know,
it
asked
for
a
ca
bundle
that
was
supposed
to
be
or
sorry.
It
asked
for
a
root
private
key
that
was
supposed
to
be
good
for
forever
and
it
issued,
like
you
know,
very
long-lived
credentials,
but
it
constantly
was
changing
the
epoch
to
based
on
some
criteria.
B
B
It
also
is
short
enough
that
it
starts
to
have
noticeable
implications
for
availability
operations.
So
I'm
not
like
I
hear
what
you're
saying
right
and
I'm
also
not
sure
what
the
right.
A
The
right
value
is
right
and
I
think
the
the
problem
is.
There
is
no
right
value.
It's
the
value
that
is
correct
is
based
on
who
submitted
the
csr
okay.
I
trust
this
entity
to
have
a
longer
cert,
because
I
have
vetted
that
identity
in
some
other
way
that
I
am
happy
with
right.
I
issued
this
to
this
unprotected
edge
component
that,
like
someone,
could
easily
break
into
okay.
He
needs
I.
He
needs
to
figure
out
like
a
better
rotation
strategy,
because
I
refuse
to
give
him
longer.
A
He
doesn't
get
to
have
a
year.
He
has.
If
he
goes
down
for
more
than
a
week,
then
someone's
gonna
have
to
go
fix
him
right,
like
that's.
What
I
think
comes
down
to
is
like
we're
saying
it's
the
responsibility
of
the
signer,
but
this
is
the
sign.
The
built-in
signers
are
basically
brain
dead
when
it
comes
to
doing
anything
reasonable
on
delay.
A
Okay,
so
if
you,
if
you
can
imagine
that
I
could
use
all
the
built-in
signers
and
if
I
had
a
field
that
was
enforcing
the
max
bound
of
ttl,
I
could
have
an
admission
plug-in
that
says:
okay
and
mo
request
is
cert
for
his
for
serving
search
for
his
app.
It
can
only
be
like
for
like
a
week.
You
can't
ask
for
years
and
crazy.
A
I
am
asking
for
something
better
than
what
we
do
today
and
I
was
stating
various
options
that
we
had
that
none
of
them
are
necessarily
super
compelling,
but
what
we
have
today
seems
extremely
uncompelling
and
on
stage
like
I
feel
like
the
crs
benchmark
should
say
you
should
go,
make
sure
you
turn
off
these
things,
like
always
because
they're
like
they're
they're,
just
not
smart
enough
to
do
something
useful.
I
The
ca,
like
I
feel
like
there
is
a
there,
is
a
persona
that
doesn't
have
the
ability
to
rotate
the
ca
in
the
cluster,
but
does
have
the
ability
to
issue
search
with
the
csr
api,
and
so
they
they
want
to
be
able
to
like
cover
themselves.
If
they
issue
a
cert
to
a
edge
node
like
mo,
is
talking
about.
B
A
Yeah
I
I
had
meant
to
do
that.
I
apologize
I
haven't
done
so
yet,
but
yeah
I
I
all
the
issues,
even
the
ones
that
we
didn't
cover.
I
will
probably
make
just
like
individual
issues
for
those
kind
of
try
to
keep
them
separate,
because
I
think
they
are
pretty
distinct
but
yeah.
I
I
don't.
I
don't
think
any
of
this
affects
v1
work
for
csr.
I
just
as
I
think
through
there
there's
some
sharp
edges
on
some
of
this
stuff
that
all
right
so
really
awesome.
A
All
right,
thank
you,
everyone.
We
will
see
you
in
two
weeks.