►
From YouTube: sig-auth bi-weekly meeting 20210526
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hi
everyone
welcome
to
the
may
26th
meeting
of
sig
auth
looks
like
we
have
two
items
on
the
agenda.
First,
is
the
csr
duration
hint
do
you
want
to
kick
this
off
mo.
B
B
On
the
issue
or
on
this
call,
I'm
welcome
to
listen
to
whatever
folks
feel
strongly
about.
A
Yeah
speaking
of
bike
shading,
did
you
also
see
the
discussion
in
the
sig
release
chat
around
somebody
not
wanting
us
to
modify
already
implementable,
implemented
caps.
B
I
have
not
read
the
details.
The
idea
of
writing
a
new
cap
for
a
field
is
silly.
I
I
will
I'll
deal
with
that
offline,
though
I
I
think
all
right,
oh
clayton,
do
you
want
to
share
your
bike?
Setting
you
don't
like
hint.
D
No,
we
don't
have
to
do
it
here,
but
I
don't
think
hint
should
be
in
the
api
okay.
So
it's
more
of
an
api
conventions
thing
I
stumped
a
couple
of
other
hints
historically,
and
so
we
don't
really
have
it
written
down,
but
I'll
I'll
take
a
look
at
the
cap
and
try
to
see
if
we
can
drive
to
conclusion
there
and
get
a
policy
written
down.
I'm
on
a
naming
consistency
kick
this
month.
B
Yeah,
that's!
This
is
exactly
why
I
brought
it
up.
I
figured
folks
care
about
the
strings
we
put
here.
So
the
implementation
is
relatively
trivial.
I
just
made
it
the
minute
yeah
the
two
options
that
you
have,
so
it's
that
part's
pretty
straightforward
matt
mike.
I
will
address
your
comments.
I
just
haven't
had
a
chance
yet.
A
I
would
I
would
kick
the
naming
to
liggett.
I
think
there
were
either
there
were
four
alternatives
discussed
in
the
pr
so
and
any
one
of
those
I'll.
Let
leggett
decide
because
he's
good
at
naming
stuff.
The
other
thing
that
I
was
wondering
was:
did
you
do
we
need
to
file
a
extension
to
get
this
into
122.
B
A
Awesome
well,
yeah.
I
think
this
is
fairly
uncontroversial
other
than
the
name,
which
is
only
medium
controversial,
so.
B
B
I
think
the
to
hear
and
friends
have
the
floor
for
lots
of
stuff
with
certs.
E
So
I
basically
took
the
feedback
from
the
last
time
I
presented
this,
so
we're
taking
a
step
back
and
saying
so.
First
before
we
talk
about
any
mechanism,
however,
we
do
this,
we
should
decide
whether
or
not
issuing
certs
to
workloads
is
something
that
is
a
good
fit
for
the
kubernetes
base
project.
E
There's
one
that's
very
important
to
me
and
then
there's
some
around
or
we
can
simplify
other
pieces
of
infrastructure.
E
E
E
E
E
C
C
We
have
treated
those
very
differently
in
cube
and
that's
why
you
can
set
different
ca
bundles
for
the
different
categories
of
things.
So
so
I
do
believe
that
they
are
different.
F
G
Absolutely,
but
significantly,
those
have
to
do
with
not
identifying
identity.
With
with
how
the
ca
system
is
set
up.
The
the
cas
that
are
in
use
in
public
web
browsers
are
not
identifying
your
identity
as
a
client.
They
are
identifying
your
identity
as
somebody
who
is
publicly
hosting
a
web
server,
but
because
we
don't
the
the
reasons
that
we
don't
issue.
Client
certificates
using
the
public
ca
list
do
not
apply
within
a
corporate
within
a
an
internal
ca
like
the
one
that
we
want
to
put
into
kubernetes.
C
I
think
I
would
dispute
that
the
distinction
here
doesn't
matter
and
that
they
would
or
should
be
signed
and
and
authenticated
using
the
same
ca.
I
would
not
expect
that,
and
I
would
expect
that
you
would
face
different
issues
with
trying
to
create
serving
certificates
and
distribute
them
than
you
will
with
a
narrow,
client
certificate.
E
Instead,
I'm
presupposing
that
you
want
to
identify
the
service
account
of
the
backend
you're
connecting
to,
and
then
you
have
some
out
of
band
method
for
deciding
whether
or
not
that
is
the
correct
service
account
to
be
backing.
What
you're
connecting
to
which
I
understand
is
a
different
model
than.
E
G
So
my
perspective
is
that
both
of
them
work
together
and
that
you
can
pick
and
choose
one
having
both
doesn't
actually
create
security
problems
so
long
as
your
application
picks
and
chooses
one
or
the
other
that
it's
making
making
use
of.
D
Yeah,
well,
it
is
it's
a
slight
change.
I
don't
want
to
derail
the
split
I
kind
of
agree
with
the
split
just
based
on
prior
art
as
well,
even
though
they
could
be
combined.
Splitting
them
leads
to
better
semantics,
especially
if
it's
all
done
automatically
it
hands
us
in
less
in
the
future.
I
guess
my
question
would
be
we
put
in
like
a
whole
bunch
of
csi
stuff
to
enable
people
to
go.
Do
things
like
this?
D
Has
that
been
tested
or
leveraged,
because
in
theory
I
don't
know
of
anything
that
would
prevent
you
from
demonstrating
this
today
with
a
local
csi
plugin
that
got
the
pods
service
account
and
issued
client
and
server
service
accounts
and
put
them
in
disk
automatically
the
same
way
that
the
service
account
controller
does
for
secrets.
E
Yeah,
that's
so
the
convention,
I
think,
is
the
main
thing
that
seems
important
to
me,
like
just
like
there's
a
convention
that
there
is
an
an
open,
idc
connect
token
available
at
a
certain
path
within
your
container
file
system.
D
And
certainly
like
this
is
so
I
denise-
and
I
argued
about
this
early
on
in
the
the
source.
Count
token
changes
but,
like
I
felt
like
pot
like
one
of
the
original
goals
with
pot
identity
was
to
allow
you
to
drop
in
un-identity.
There
are
trade-offs.
Tokens
are
better
in
some
cases
and
worse
than
others,
and
the
we
at
the
time
agreed
that
the
yeah,
some
of
the
aspects
of
tls
were
better,
but
we
wanted
to
focus
on
something
that
fixed
the
pragmatic
problem.
D
D
The
question
is:
is:
does
this
bring
in
so
much
extra
complexity
that
we'll
spend
the
rest
of
our
lives
chasing
the
the
details
of
certificate,
revocation
to
the
lessons
learned
during
time,
web
tokens
to
pod
location
are
those
you
know
transitive,
because
most
people,
most
of
the
time
do
want
a
server
cert
and
most
people
most
of
the
time
definitely
want
a
client
cert.
D
They
just
may
not
use
it,
but
it's
a
better
solution
than
the
token
in
a
number
of
cases,
so
I
certainly
am
in
favor
of
it.
I
just
understand
the
the
time
it
will
take
to
drive
this
out.
A
Requirements
to
set
that
up
are
either
too
challenging
to
do
securely,
or
I
don't
know
I
I'm
thinking
about
gatekeeper,
which
gives
that
has
a.
I
think
it's
like
a
grants,
itself
permission
to
approve
csrs
and
it
has
just
a
control
loop
right
inside
gatekeeper
to
approve
its
own
serving
certificate,
and
then
that
pattern
has
been
copied
out
because
it's
kind
of
like
the
zero
config,
only
a
zero
config
mechanism
for
securing
a
webhook
backend,
and
it
seems
like
if
we
want
people
to
extend
kubernetes
using
these
api
extensions.
D
I
was
gonna,
ask
so
there's
a
difference
between
the
identity
being
tied
to
a
pod
and
the
identity
being
tied
to
a
service
and
a
name
in
the
naming
system.
The
things
that
make
naming
really
easy
are
the
things
tying
it
to
service
and
dns,
because
it,
if
you
don't,
you
definitely
have
to
know
that
the
pod
is
suitable
like
when
you
talk
to
a
web
hook
in
cube.
D
You're
really,
ideally
you'd
be
talking
to
one
of
a
set
of
web
hooks,
and
when
you
start
getting
to
that
level
of
detail,
if
you
want
to
verify
the
identity,
you
then
have
to
verify
that
that
pod
is
supposed
to
be
in
that
set
which
starts
bringing
in
extra
complexity
and
like
david's
point
about
service.
Signer
cert
is
exactly
where
I'm
going,
which
is
saying
that
something
is
part
of
a
set,
is
something
that
cube
does.
D
D
But
if
you
just
do
it
on
pod
identity,
that's
not
really
enough,
and
then,
if
we
were
to
make
an
argument,
oh
well,
then
we'll
just
add
something
to
the
pod.
That
says
it's
part
of
this
service
that
gets
into
territory
that
we
had
historically
said
was
very
fraught
like
when
we
added
it
for
staples.
That's
I'm
still
not.
I
still
think
it's
coupling
a
pod
directly
to
a
service
is
a
little
weird
coupling
it
to
the
default.
D
D
D
Yeah,
but
again
that
a
service
account
can
be
a
singular.
We
have
never
grouped
things
by
service
account
other
than
security.
So,
like
the
question
is,
is
a
service
account
tied
to
a
service
and
services
and
pods
are
orthogonal
pods
and
services?
Pods
and
service
accounts
have
a
parent-child
relationship.
D
A
A
Yeah
the
only
scenario
where
that
would
bite
you
is,
if
you
were
trying
to
migrate
a
web
hook
back
end
from
one
service
guy
to
another.
In
the
same
name,
space,
which
seems
like
a
fairly
small.
C
Well,
so
well,
no
you're
you're
talking
about
creating
a
new
way
to
verify
server
and,
and
what
I'm
going
to
say
is
that
for
the
two
cases
you
brought
up
aggregated
api
servers
and
meshing
web
hosts,
we
can
actually
use
the
normal
server
tls
verification,
the
one
that's
been
around
since
before
we
were
born,
and
it
is
not
hard
to
build
something
that
sets
that
up.
There
are
multiple
demonstrated
solutions
for
doing
it.
That
mean
that
you
rely
on
nothing
but
an
annotation
on
a
service
and
an
annotation
on
your
api
service
and.
C
C
I'm
not
saying
that
this
feature
might
not
have
a
place
somewhere
else,
but
I
want
to
claim
that
it
is
the
best
solution
for
api
services
and
yeah
and
mike
as
old
api
services
and
admission
web
hosts.
D
Yeah,
I
was
only
gonna,
so
maybe
to
go
back
so
the
client
part,
I
don't
think,
is
disputable.
Client
certs
have
a
significant
advantage
over
tokens
and
they
don't
confide.
They
don't
disclose
security
when
they're
in
contact
with
something
else,
but
we
don't
necessarily
have
as
clear
of
a
use
case
in
cube
for
that
unless
we
can
come
up
with
one
on
the
serving
side
for
tls
web
or
for
web
hooks
and
cert
or
web
hooks
and
aggregated
api
servers
that
are
running
on
the
platform.
D
I
still
feel
the
connection
is
to
the
service,
not
the
service
account
and
then
that's.
I
think
what
I
would
probably
worry
about
going
too
far
on
this,
unless
we
can
come
up
with
an
approach
that
that
does
not
tie
identity
because,
like
david,
what
you're
saying
is
like
the
set
identity
is
from
a
service
account,
but
what
we
really
want
to
do
is
verify
that
the
the
server
we
are
talking
to
is
in
the
set
that
we
expect
it
to
be,
and
that
gets
a
little
like
that.
D
G
I
mean
within
my
coop
tls
proposal,
the
set
of
services
that
your
pod
matches
are
used
as
host
names.
I
I
don't
actually
like
that.
I
don't
think
that
you
should
be
using
that
as
off.
I
think
that
you,
the
google,
has
internally
been
verifying
the
service
that
you
are
connecting
to
by
its
service
account
name
for
longer
than
I
was
there,
and
I
was
there
10
years
ago.
G
I
I
think
this
is
the
right
answer
that
you
need
to
be
as
a
corporation.
You
need
to
be
thinking
about
who
it
is.
You
are
trying
to
connect
to
not
names
that
are
arbitrarily
assigned
to
services,
but
identities.
D
And
that's
that's
a
really
strong
argument.
If
that
shows
up
in
the
cap-
and
I
haven't
read
it,
that's
fine.
That
kind
of
history
is
like
that's
an
argument
that
I
think
is
like
an
argument
from
authority
and
there's
a
relevant
authority
there
like.
If
we
can
come
up
with
a
strong
enough
argument
that
that
applies
to
everybody
else.
I
think
that's
an
argument
we
could
potentially
play
out.
D
I
just
want
that
very
clearly
stated
that
we're
effectively
giving
up
like
tls
is
being
used
as
infrastructure
identity
connected
to
a
physical
resource,
which
does
that
then
limit
our
ability
to
run
web
hooks
off
the
platform.
Or
is
this
just
yet
one
more
thing
and
we
didn't
actually
simplify
the
world.
We
actually
added
just
a
new
option.
F
G
Cert
manager
is,
is
for
external
certs,
not
that
it
can't
handle
internal
certs,
but
that
it's
its
design.
Mechanisms
are
for
interacting
with
the
public
cea
list,
which
is
in
and
of
itself
a
misnomer,
but
let's
not
get
it
go
there.
F
F
C
Not
at
all,
as
I
understand
it,
when
you
generate
your
cert
serving
cert
with
start
manager
and
it
gets
signed,
you
can
curl
and
reference
your
custom
ca
and
it
can
verify
it
the
name.
As
I
understand
this,
the
goal
is
to
create
a
certificate
that
will
be
used
for
serving
that
will
not
be
verifiable
with
standard
tools.
E
I
wouldn't
have
characterized
that
as
a
goal.
It's
just
the
way
we
were
approaching
it.
A
So
I
I
think
we're
approached
like
we
are
observing
the
same
problem
and
approaching
it
at
different
angles
like
we
have
pods
loosely
coupled
with
services,
so
we
don't
want
to
give
a
pod
a
tls
certificate
for
hostname
for
a
service,
especially
not
a
namescapes,
namespace
scope,
dns
name,
especially
maybe
not
even
a
like
I'm
trying
to
think
about
how
many
past
segments
I
would
feel
comfortable
encoding
in
a
dns
name
for
a
server
cert.
A
One
approach
to
that
is
not
using
the
host
name
that
you
connect
to
a
service
as
server
authorization.
You
have
some
out-of-band
mechanism
to
decide
what
service
account
should
be
backing
that
and
another
approach
to
this
problem,
where
we
say
pods
are
loosely
coupled
to
services,
is
to
go
all
in.
I
think
so.
There's
which
david
and
clayne
were
recommending.
I
don't
know
what
the
right
answer
is,
but.
F
But
I
I
guess,
we're
I'm
kind
of
getting
hung
up
here
and
I'm
sorry
to
to
believe
you
know
to
hammer.
The
point
is
and-
and
maybe
this
is
the
the
the
difference
between
having
a
distinct
server
and
clients
or
versus
tying
the
two
together
it.
You
know
if
I
want
a
service
that
listens
to
or
that
listens
on
a
cert
with
you
know
the
existing
mechanisms.
F
You
know
the
the
the
existing
you
know,
server
name
based
mechanisms,
I
define
assert,
cert
manager
publishes
it
and
all
my
pods
serve
that
same
cert.
I
can't
uniquely
identify
each
server
based
on
that
circ,
but
you
know
if
the
server
then
had
if
each
pod
then
had
a
unique
key
that
had
an
identity
tied
to
it
that
again
yeah
it.
F
Well,
I
I
guess-
and
maybe
I'm
I'm
conflating
two
different
things
here,
the
the
from
what
I'm
hearing
and
what
I've
read.
The
idea
is
that
I
can
get
a
cert
mounted
and
I
can
get
a
key
pair
insert
mounted
into
my
pod
and
that
keeper
insert
can
be
used
both
to
identify
me
as
a
client
and
identify
me
as
a
service,
and
so
that
way
I
can
start
you
know
I
can
just
fire
up
and
say:
okay,
I'm
listening
on
tls.
F
You
know
out
of
the
box,
which
you
know,
I
think
everybody
is
a
good
idea
and
so,
but
as
a
web
hook,
you
know
if
I
do
that
with
a
web
hook,
and
I
write
a
lot
of
web
books.
So
I
run
into
this
a
lot
if
I
write
a
web
hook,
you
know
the
api
server
and
I
want
to
do
it
over
tls.
F
I
have
to
tell
the
api
server
today
what
cert
it
is
and
that
cert
has
to
line
up
with
the
service
assuming
it's
running
in
cluster,
and
so,
if
my,
if
my
podcert
doesn't
have
my
service
name
as
a
subject,
alternative
name,
the
api
server
will
reject
it.
F
So
the
solution
I'm
hearing
is
to
change
the
rules
so
that
it's
identified
a
different
way
and
I'm
not
arguing
for
or
against
that.
To
be
honest,
I
I
would
agree
that
most
of
the
circles
are
pretty
awful,
but
that
said
today,
the
way
I
handle
that
is,
I
generate
a
cert,
that's
bound
to
the
service
name
rather
than
to
individual
pods,
and
if
I
need
an
identity
for
the
pod,
I
have
a
client
certificate
and
that's
one
of
the
reasons
to
separate
those
things.
F
D
I
miss
that
was
actually
a
useful
summary
because
it
actually
raised
the
question
for
me,
which
is,
I
feel
like
we're
talking
about
three
separate
things,
and
each
of
them
has
value
independently.
As
a
pod,
I
should
be
able
to
assert
my
identity
as
the
pod
without
disclosing
my
without
giving
someone
else
the
ability
to
impersonate
me.
That's
pod,
client,
cert,
that's
a
pretty
reasonable
thing.
We
talked
about
this
in
the
pod
identity
discussions
four
years
ago.
I
think
we
all
agreed.
It
was
something
we
could
eventually
see
ourselves
doing.
D
Do
we
have
the
context
now
to
decide?
Probably
there's:
should
this
pod
be
able
to
identify
itself
when
serving
as
a
particular
plot
on
a
particular
infrastructure
in
a
verifiable
way?
I
think
that's
also
valuable
it's
a
bit
of
a
different
use
case,
but
I
think
you
know
going
back
to
the
to
the
discussion
about
google
running
this
way
like
it's
an
appeal
to
authority,
but
I
actually
would
appreciate,
which
is,
if
you're,
trying
to
talk
to
something
that
you
expect
to
be
a
certain
infrastructure
bit
being
able
to
say.
D
Then
there's
a
third
use
case,
and
this
is
where
it
gets
a
little
complex,
which
is
when
that
element
has
both
infrastructure
and
and
service,
like
general
client
needs
for
identifying
itself
via
a
local
name,
a
global
name
in
the
dns
and
tls
view
does
having
an
infrastructure
cert
compose
well
with
having
another
cert.
That's
for
a
client
sni
certainly
allows
you
to
do
that
these
days,
there
may
be
as
an
argument
that
most
workloads
running
on
cube
do
want
to
have
an
ability
to
talk
to
somebody
else
in
a
circle
they
are.
D
They
do
want
someone
else
to
be
able
to
verify
that
they're
part
of
the
infrastructure,
and
they
do
also
want
to
be
able
to
support
zero
to
n
extra
certs
that
tie
them
to
names,
which
you
could
maybe
argue
is.
If
someone
were
writing
the
framework
in
five
different
languages
for
running
on
top
of
cube,
you
look
for
your
service
account
token.
D
You
look
for
your
service
account
identity
that
you
could
use
to
talk,
that's
better
than
the
token
in
many
respects,
and
you
could
also
look
for
a
set
of
your
infrastructure
serving
cert
and
mix
that
in
by
s.
I,
when
people
want
to
talk
to
you
as
if
you're,
that
pod
and
the
question
would
be,
could
we
come
up
with
the
use
cases
for
each
of
those
that
justifies
it
in
a
single
proposal
versus
teasing
it,
apart
into
multiple.
F
A
F
A
Like
gatekeeper,
helm,
chart
needs
to
depend
on
the
cert
manager
helm
chart.
I
would
say
that
it
probably
deserves
to
have.
We
probably
deserve
to
have
minimal
functionality
in
kds.
D
We
established
that
the
first
time
around
with
pod
identity,
which,
as
we
said
in
general,
cube,
believes
that
tying
processes
to
infrastructure
an
identifiable
way
is
within
our
remit.
The
question
would
be:
can
we
do
it
in
a
way
that
doesn't
that
consolidates,
workloads
and
makes
workloads
more
secure,
makes
pods
run,
makes
workloads
running
on
kubernetes,
more
secure
and
easier
to
run
by
default
and
better
for
operations
teams,
and
that
that
last
one
is
the
kicker?
Is
it
better
for
an
operations
team
if
we
introduce
this
and
it
conflicts
with
cert
manager?
C
So
creating
a
client's
certificate
doesn't
seem
significantly
different
to
me
than
creating
a
a
service
account
right
like
I
could
see
it
being
similar.
You
asked
to
have
it
injected.
I
you
know
we're
starting
something
new.
I
would
make
it
short
from
the
very
beginning.
C
B
Okay,
please,
I
was
gonna
say
ignoring
the
serving
case
for
a
second
with
the
newer
style
service,
account
tokens
right.
We
we
bind
them
to
the
identity
of
the
pod,
you
know
with
an
extra
field
and
we
verify
that
are
we
are
we
saying
we're
not.
D
Gonna
do
that
with
these,
I
don't,
I
think
you.
I
think
it
would
be
required
that
the
certificate
be
tied
to
you,
it
and
a
node
and
a
no.
You
would
probably
like,
like
in
a
sense
we
are.
This
is
an
assertion,
that's
based
on
the
chain
of
trust
from
the
node.
If
the
node
is
compromised,
then
all-
and
we
have
this-
like-
I
think-
denise-
you
still
got
a
couple
of
these
docs
that
go
through
a
lot
of
the
different
variations
on
this,
which
are
effectively
the
prior
art
from
the
sig.
E
B
B
B
D
Well-
and
I
think
it's
a
I
think,
there's
the
yeah
getting
into
the
use
case
details
I
was
going
to
actually
add
with
the
token
even
you
know,
we
have
to
think
about
some
of
those
elements
as
well.
I
was
thinking
about
the
parts
of
the
token
and
the
cert
that
are
similar
now.
D
The
one
difference
is
is
that
the
client
cert,
because
it's
not
disclosed,
can
be
longer
lived
in
many
dimensions
like
to
david's
point,
but,
and
there
are
advantages,
even
if
it
is
a
little
bit
more
expensive
to
create,
but
there
is
there
isn't
at
least
the
ability-
and
this
is
not
discussing
the
delegation
of
the
node
to
generate
the
cert
is
ultimately,
if
you
don't
trust
the
node
at
a
particular
point
of
time.
Everything
else
is
questionable.
A
Yeah,
I
I
don't
know
in
a
large
shared
cluster
yeah.
I
think
you
need
more
than
just
a
node
certificate.
Generally.
You
also
need
some
guarantee
that
a
pod
was
scheduled
on
a
particular
node
versus
having
like
a
yeah.
D
That's
what
that's
what
I
meant
the
the
atta
station.
Someone
has
to
be
able
to
verify
that
the
worker
has.
The
worker
was
scheduled
that
pod
and
the
pods
ui
belongs
to
that,
and
at
least
we
have
the
mechanisms
in
the
cube
that
could
allow
for
a
use
case
for
the
serving
cert
there
are
so
web.
Hooks
and
aggregated
apis
are
a
little
bit
more
servicey.
D
There
are
a
number
of
things
around
health
checks,
probes,
monitoring
and
other
cubic
to
cubelet
or
cubelet.
To
other
thing
integrations
that
are
a
little
complicated
to
the
fact
that
we
use
like
a
webhook
authenticator
and
the
cubelet
works,
because
effectively
cubelet
is
rude
on
the
entire
machine.
D
So
we
don't
worry
about
it
too
much,
but
there's
a
number
of
cases
where,
if
you
want
to
target
a
pod
being
able
to
say
like
what's
the
easiest
way
to
make
sure
that
every
workload
on
the
cluster
has
an
identity
that
can
be
verified
for
infrastructure
integration,
the
serving
cert,
that's
tied
to
very
scoped
to
that
pod
and
that
bit
of
infrastructure
has
some
advantages.
C
A
C
A
I
I
feel
the
same
way
about
a
service
like
if
you're
saying,
if
you're
getting
a
a
key
out
to
a
pod,
the
the
nice
thing
about
service
gun
tokens
is
once
we
delete
the
pods
those
service
count.
Tokens
are
revoked.
B
Do
you
like
the
sorry
I
was
gonna
say
why
couldn't
you
just
tie
it
to
like
the
uid
of
the
service
as
well
right?
So
if
you
delete
the
service
and
you
make
another
one,
I
guess
you
would
need
some
kind
of
extra
like
do
you
guys
are
letting
the
perfect
be
the
enemy.
B
G
Short-Lived
circuits
are
great,
but
we
can
go
with
90-day
certificates
and
we
are
still
better
than
the
vast
majority
of
the
web.
You
know
the
there
we
want
to
avoid
the
part
where
people
assume
that
certificates
last
forever,
but
scoping
them
to
the
lifetime
of
a
pod
is
not
unreasonable.
G
Just
because
we
don't
currently
have
currently.
We
speak
http
across
the
wire
and
getting
anything
that's
better
than
that
is,
is
better.
D
So,
at
a
minimum
level,
there's
nothing
today
that
blocks
this
from
being
done
out
of
tree.
The
proposal
is
about
the
convention.
There's
probably
an
argument
that
the
client
cert
definitely
falls
within
the
remit
of
the
original
pod
identity
proposal,
and
so
I'm
at
least.
D
I
could
I'd
like
to
explore
that
one
and
there's,
while
there's
some
arguments
and
counter
arguments,
I
could
absolutely
believe
that
we've
got
a
little
bit
more
context
to
say
whether
it's
worth
it,
but
we
did
come
up
already
with
questions
around
verifiability
and
reliability
on
the
server
cert
was
the
original
thrust
of
the
proposal
to
dramatically
improve
serving
certs,
because
I
don't
feel
we've
at
least
just
based
on
the
discussion.
I
don't
feel
that
we've
identified
a
clear
path.
There.
A
C
A
I
I
guess,
if,
if
we
add
a
client
outfit
and
a
server
outfit
and
whatever
we
choose
for
the
surface,
account
identifier,
whether
that's
spiffy
or
that
common
name
system
service,
account
thing
that
we
have
does
it
matter
if
we,
if
there's
an
extra
service
camp
or
sorry
if
there
is
an
extra
server
auth
bit
on
that
certificate.
Sorry
downside
to
that.
A
Because
then
people
who
either
have
spiffy
libraries
for
mtls
or
are
willing
to
do
a
little
extra
work
can
use
this
for
mtls
within
a
cluster.
So
I
might.
E
C
And
and
then
in
addition
to
that
right,
like
so,
let's
say
you
even
do
all
that
right
in
order
to
use
it
for
the
aggregate
api
servers
and
admission
web
hooks,
you
will
need
to
change
the
way.
Those
verify
servers
from
the
means
that
we
use
today,
which
is
the
standard,
am
I
talking
to
the
server
I
expect
flow
to?
C
G
Is
allowed
you
can
shim
those,
though,
with
a
web
hook,
you
can
simply
set
the
the
cert.
It
expects
to
be
the
s
that
see
the
issuing
ca.
The
name
wouldn't
match.
F
E
B
And
there's
also
a
little
bit
of
different
stuff
too
right
like
today
like
we
have,
we
have
token
review
for
delegating
stuff
to
the
api,
server
or
other
places
for
tokens
right.
We
have
subject
access
reviews,
we're
doing
the
same
thing
for
authorization,
there's
no
certificate
review.
You
can't
ask
someone
else
to
figure
out
what
a
certificate
means.
It
happens
locally
on
the
client
right.
So
the
cube
api
server
cube,
live
clients.
Everything
in
our
infrastructure
has
literally
the
same
meaning
for
what
a
ca
bundle
means
for
a
client
server
right.
B
It
says:
okay,
o
is
the
group
and
cn
is
the
name.
That's
all
I
understand
that's
all
I
ever
ever
understand
right
if
you
change
that
in
specifically
meaningful
ways
like
I
mean
you
could
add,
like
a
required
extension
to
cause
it
to
fail
verification
sure
I
guess,
but
we
don't
have
a
way
to
delegate
this
today
right
and
that's
not
great,
I
don't.
I
don't
want
to
go
update
all
the
endpoints
to
understand
spiffy,
I
I'm
not
even
against
spiffy.
B
E
B
A
Yeah-
and
I
like
I
am
unopinionated,
I
I'm
slightly
opinionated,
but
I
don't
have
a
strong
opinion
whether
we
go
with
our
format
versus
spiffy
like
if
I
look
at
the
community,
it
seems
like
spiffy
is
gaining
adoption.
We
have
our
own
thing
in
the
corner.
Is
it
good
long
term
to
go
in
the
direction
of
other
cncf
projects
in
the
industry?
Probably,
is
that
direction
spiffy?
I
don't
know,
but
I
don't.
If
I
go
to
kubecon
and
look
at
blog
posts,
it
seems
like
it's
picking
up
steam
so
open
to
alternatives.
G
A
Go
ahead
mike,
I
was
just
gonna
say
it
seems
like
we
have
more
fundamental
issues
than
the
encoding
of
this
certificate
to
work
through
here
I
yeah.
C
C
To
have
a
certificate
that
sounds
great
sure.
Let's
do
that,
but
then
to
say
that
we
also
want
to
use
it
as
a
serving
certificate
and
there's
going
to
have
like
standard
serving
certificate
fields.
That
seems
different.
C
I
wouldn't
expect
the
lifetime
of
those
things
to
be
necessarily
the
same.
I
think
there's
a
difference
between
saying
someone
remote
contacted
me
and
let
me
see
if
I
recognize
them
and
I
am
contacting
this
other
server.
Let
me
see
if
it
is
responding
correctly
and
then,
if
we're
talking
about
building
a
new
means
to
evaluate
whether
we're
communicating
with
the
current
server
we
expect
or
not.
C
That
seems
like
a
separate
and
distinct
thing,
and
if
we
want
to
do
that,
I'm
not
I'm
not
necessarily
opposed
to
that
either.
But
it's
not
it's
not
clear
that
that's
what
we're
building.
First,
like
we
go
off
and
have
a
separate
proposal
that
doesn't
actually
issue
anything
and
says.
Okay,
we
want
to
have
our
aggregated
api
server,
be
able
to
authenticate
a
server
using
yeah,
I'm
not
familiar
with
the
standard.
Is
it
called
a
spiffy
standard.
A
C
And
that
seems
like
a
separate
thing:
if
you
want
that,
we
could.
We
could
talk
about
doing
that.
Is
this
proposal
trying
to
do
all
those
things
I.
E
G
Think
so
all
of
these
things
turn
into
something
magical
if
you
have
all
of
them
together,
if
you
have
the
ability
to
act
as
a
client
or
a
server
identified
by
your
identity
and
the
kubernetes
api
server
understands
that
as
well,
then
you
are
able
to
do
all
of
these
things,
which
is
all
of
these
all
of
these
complex
things
with
x,
509
with
a
relatively
simple
magical
interface
they
compose
well
because,
yes,
you
can
add
server
certificate
and
client
certificate
to
the
same
thing
and
really
serv
server
certificates
and
client
certificate
identification
are
actually
not
that
different.
G
C
A
It's
I
think
it's
a
nomenclature
thing
that
the
way
you
authorize
somebody
to,
I
guess
what
we
would
need
to
do
as
a
signer
or
approver
in
the
cube
api
server
to
approve
a
serving
certificate
is
very
different
than
what
we
would
need
to
do
to
approve
a
client
certificate.
C
E
B
One
I
wanted
to
ask
sorry
mike
is:
can
somebody
write
a
concrete
list
of
things
of
this
that
cannot
be
accomplished
out
of
tree
today
like
what?
What
are
the
gaps
within
what
we
provide,
as
extension
points
that
you
need
that
way?
If
those
are
just
intrinsically
good,
we
can
just
go
right.
The
extension
points
that
way.
A
So,
as
clayton
mentioned
before,
I,
this
needs
to
be
teased
out
into
like
individual
things
to
deliver.
There
are
a
number
of
items
here
that
I
think
make
sense
to
import
include
in
core.
A
I
am
definitely
biased
towards
like
prioritizing
this
tls
authentication
for
apis
aggregated
apis
in
web
hooks,
because
I
think
that
is
way
too
hard
to
do
securely
today.
I
think
we
can
discuss
whether
it
would
be
good
to
offer
client
certificates
as
alternatives
to
tokens,
but
yeah.
If
I
think
the
answer
to
your
question
is
a
lot
of
this
can't
be
done
today
out
of
tree.
A
Which
is
not
necessarily
a
reason
that
we
should
do
this
stuff
out
of
tree
forever,
that
we
should
always
require
the
gatekeeper
helm
chart
to
also
install
cert
manager,
for
example,.
B
So
I
want
to
be
clear:
I
don't
think
like
client
search
for
service
accounts
or
the
ca
stuff
and
serving
search
stuff
for
api
service
and
admission
web
books.
I
don't
actually
think
that
should
be
out
of
long
term,
mostly
because
I
felt
the
same
pain
that
you
felt
mike.
I
have
written
the
code
that
automates
this
without
using
the
csr
api,
and
this
is
zero
fun
and
added
zero
value.
B
To
my
day,
just
the
code
I
had
to
write
to
as
an
awk
caring
person
once
you
have
security,
so
that
wasn't
fun,
and
I
think
I
disagree
a
little
bit
on
with
david
on
this
type
of
stuff,
where
I
do
think
I
lean
stronger
on
the
injury
versus
autotree
thing.
B
What
I
was
trying
to
tease
out
is:
I
want
to
make
sure
that
if
there
is
a
gap
that
cannot
be
filled
today,
but
we
think
it
is
a
valuable
gap
just
due
to
like
you
can't
verify
us
a
spiffy
identity
and
if
we
think
that's
valuable.
Let's
just
do
that
that
way,
because
the
reality
is,
if
we
added
this
in
122,
actually
123
as
an
alpha,
it
would
take
years
for
this
to
roll
out
in
a
meaningful
way
across
all
providers.
So
it
would
be
great.
B
Just
like
the
psp
proposal
will
be
implementable
as
a
webhook
and
usable
across
all
sorts
of
environments.
It
would
be
nice
if
you
had
you.
Could
I
don't
know
if
helm
charts
can
optionally
install
a
thing?
I
don't
use
helm
very
often,
but
I
could
imagine
you,
optionally,
install
cert
manager
to
get
you
a
bunch
of
functionality
unless
your
detector
at
a
new
enough
version,
and
you
use
the
cool
new
functionality
right
like.
A
Yeah,
I
don't
know
how
it
works
either.
I
think,
basically,
what
you
are
suggesting
is.
We
should
tease
this
out
even
further
into
the
different
things
we
could
deliver
and
then
rationalize
them
individually
and
experiment
out
of
tree
set.
C
C
To
latch
progress
as
you
go
wrong
right,
like
like
the
client
cert
stuff,
isn't
particularly
contentious
the
spiffy
stuff,
I'm
I'm
open
to,
for
you
know
a
way
to
identify
an
aggregated
api
server,
but
the
serving
cert
aspect
of
this
proposal
seems
unusual
to
me
and
yeah.
E
Yeah,
I
think
some
of
that
is
an
artifact
of
ted,
and
I
are
coming
at
this
from
different.
C
B
A
Is
not
allowed
by
the
tls
spec,
however,
you
can
use
out-of-band
mechanisms
for
validating
names.
A
A
But
you
are
right
and
we
could
do
it
out
of
tree
if
we
ignore
allowed
usages
of
certificates.
B
G
Because
the
tls
spec
does
actually
acknowledge
that
names
are
hard
and
that
there
are
multiple
possible
conventions
for
names.
The
tls
spec
is
rotting,
which
is
why
there
are
certain
sands
that
we
should
absolutely
never
use
and
not
a
spiffy
sand,
but
it's
totally
reasonable
for
for
a
spiffy
sand
to
be
added.
It's
just
that,
like
clients
will
take
ten
years
to
catch
up
to
that.
A
Yeah,
it
seems
like
we
are
maybe
digging
in
a
little
bit.
So
what
are
like
proposed?
What
are
some
good
next
steps?
I
can
recommend
teasing
this,
even
apart
even
further
into
like
the
different
user
journeys
that
we
want
to
enable
clayton
had
a
few.
E
A
Sounds
good
cool
is
there
we
only
have
two
minutes
left.
Do
you
want
to
wrap
this
up
any
closing.
A
Well,
it
seems
like
we
will
have
a
discussion
topic
to
replace
pspv2
over
the
next
couple
meetings.
A
All
right,
I
do
not
think
that
we
have
enough
time
to
go
over
ci
flex
and
test
grid.