►
From YouTube: SIG-Auth Bi-Weekly Meeting for 20220202
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
Okay,
everyone:
this
is
the
sig
off
meeting
for
february,
2nd
2022.,
that's
more
stuff
from
the
agenda
than
I
asked
remember.
It
still
seems
kind
of
like,
but
let's
get
started,
who
added
the
cube.
Cto
commando
request.
Oh,
that
was
jordan.
I
think
jordan.
You
made
that
vr.
Do
you
want
to
talk
about
it?
Yep.
B
I
ran
across
this
when
I
was
thinking
through
what
we're
gonna
do
this
release
for
the
balance
service
account
token
stuff
and
looking
at
how
people
were
actually
scraping,
auto-generated
tokens
and
thought
we
should
give
them
a
nice
way
to
get
a
token.
The
way
we
want
them
to
so
I
think
I
will
actually
relocate
this
to
keep
control
create.
I
forgot
we
have
a
bunch
of
creation
commands
under
there,
so
tube
control
create
token
or
create
service
account
token
that
way
by
default.
B
A
C
Really
quick
question
there
I'll
I'll
review
the
pr,
but
just
directionally,
are
you
thinking
about
like
also
adding
flags
for
all
the
all
the
fields
on
the
api
like
audience
and
expiration
time.
B
B
A
B
A
B
A
A
A
I
was
going
to
ask:
does
anyone
else
want
to
take
a
look
at
it?
I
think
david
basically
said
just
fix
the
feature,
gate
stuff
and
we're
good
from
pr.
A
A
All
right,
I
might
take
that
as
just
let's
address
david's
comments,
make
sure
we're
good
in
pr
and
we'll
get
the
merge.
We'll
run
this
in
124,
but
there'll
be
an
alpha
in
124.
So
no
commitment
you
can
fix
stuff.
If
folks
are
unhappy
with
it,.
C
A
A
F
So
this
is
me:
I
have
a
small
presentation,
just
five
slides,
not
much.
F
F
And
see
you
soon?
Okay,
let
me
try
to
make
this
bigger
like
so
okay,
so
we
wanted
to
talk
about
cubeat
proxy.
It's
an
amazing
piece
of
software.
That's
in
widespread
use!
F
The
issue
I
we
wanted
to
talk
about
is
that
it's
currently
in
a
personal,
it's
not
part
of
an
organization,
it's
in
a
personal
github
account
and
we
would
like
to
kind
of
so
as
fast
as
properly
frederick
would
like
to
contribute
this
repository
to
kubernetes,
and
it
fits
quite
well
within
the
sick,
auth
domain,
because
it
does
authentication
authorization.
F
So
for
those
who
don't
know
it,
it
runs
basically
as
a
site,
and
it
does
basically
a
token
review
to
do
the
authentication
and
subject
access
review
to
do
the
authorization
and
every
if
everything's,
fine.
It
lets
the
request
through
to
the
upstream.
F
So
this
is
a
high
level
overview
that
I
hopefully
with
courtesy
from
frederick
copied
from
his
blog.
It
was
an
amazing
blog
where
he
gave
me
overview
of
how
it
works.
It's
also
referenced
in
the
documents,
and
it's
basically
what
I
said
right.
So
there
comes
a
request
in
this
case
from
prometoys
cubac
proxy
verifies.
It
first
with
a
token
review,
which
makes
authentication
then
does
the
authorization
and
call
the
kubernetes
api
to
verify
that
everything
is
okay.
F
There
are
also
two
cool
features.
Maybe
to
make
it
more
interesting.
Is
that
there's
also
aesthetic
authorization?
So
then
there
is
no
need
to
go
to
the
communities
api
and
verify
that
and
the
user
is
authorized
and
other
cool
features
also
that
you
can
use
oidc
provider.
So
you
don't
also
so
you're
able
to
call
the
idc
provider
instead
of
the
kubernetes
api
and
that's
basically
it
from
a
high
level
view
if
I
missed
something
saggy
sure
frederick
can
add
something
on
top.
I
guess.
G
Yes,
okay,
yeah,
so
a
couple
of
things
from
chat,
so
first,
let's
talk
about
the
500s
it
looks
like
github
is
literally
returning
500s
for
absolutely
everything
right
now,
so
it's
not
the
link's
fault,
but
jordan
also
commented
that
this
was
previously
discussed.
I
believe
this
was
actually
discussed
like
two
years
ago
once
before,
and
we
did
all
agree
that
we
wanted
to
transfer
the
repo,
but
I
just
didn't
pull
through
with
it,
and
I
basically
I'm
not
working
on
kubernetes
anymore
full
time.
G
So,
basically,
my
understanding
is
that
search
and
sorry,
I
don't
know
how
to
pronounce
your
name
want
to
kind
of
take
this
over
and
do
it
from
my
side,
like
I'm
more
than
happy
to
let
go
of
this
project,
I
don't
maintain
it
anymore,
anyways,
the
two
of
them
already
maintain
it.
So
for
all
I
care
they're
already
the
maintainers.
A
Tier
you
have
your
handbook,
let
you
go.
Oh.
H
I'm
just
could
somebody
maybe
give
me
an
example
of
as
a
user,
why?
I
would
deploy
this?
What
I'm
accomplishing
when
I
deploy
it.
I
I
Plus
you
want
to
express
some
notion
of
authorization
that
that
is,
you
want
to
express
okay,
I
only
want
service
accounts
to
access
this
service,
plus
they
should
have
permissions
against
some
expressed
cluster
role
or
you
know
any
any
arbitrary
wall.
That
is
role
that
is
configured
inside
the
cluster
when
frederick
and
me
have
been
working
actively
on
like
together
on
this
thing,
we
made
the
joke.
I
The
canonical
use
case,
at
least
for
our
downstream
stuff,
is
protecting
metrics
and
points.
That's
why
prometheus
is
present
in
in
this
diagram.
So
that's
that's
sort
of
like
the
canonical
use
case
and
the
static
authorizers
that
you
saw
and
as
well.
The
oidc
lookup
of
verification
of
tokens
is
essentially
a
means
to
save
your
api
server
from
those
token
review
and
subject
access
review
requests
if
if
there
is
need
to
do
so
right,
so
these
are
just
on
top
features
that
were
added
recently
and
yeah.
I
H
Yes,
but
I
have
one
follow-on
question
which
is:
would
you
typically
make
like
custom
resources
and
custom
verbs
in
the
r
back
or
are
you
piggybacking
on
top
of
existing
resources
and
existing
verbs.
I
It
could
be
either
one
right.
We,
we
even
have
a
lot
of
precedences
where
we
check
things
like
do.
You
have
get
permissions
on
or
like
read
permissions
on
any
spaces,
for
instance,
but
you
can
obviously
also
delegate
to
customer
resources
as
well.
That's
that's
no
issue.
Yes,
essentially,
everything
that
can
be
expressed
within
a
cluster
role
inside
kubernetes.
I
That's
a
good
question.
I
would
have
to
look
up
what
bastian
does
from
hashicorp.
I
literally
don't
know
if
there
is
anyone
here
that
does
please.
Let
me
know
this
is
strictly
against,
like
for
cube,
right
and
sort
of,
like
has
no
other
association
with
any
other
means
of
of
integration,
and
hence
also
the
proposal
to
contribute
to
sick
off
yeah.
B
I
linked
to
the
meeting
was
it
I
can't
I
couldn't
I
didn't
look.
It
was
last
march
or
march
two
years
ago,
but
anyway
there
was
some
discussion
there.
I
think
it
sounded
like
there
wasn't
particular
objection
to
it
getting
picked
up
by
sigoth
at
the
time.
B
The
main
reason
prompting
wanting
to
bring
it
in
was
cluster
api
and
cube
builder,
and
so
there
was
a
question
specifically
about
that
about
why
cluster
api
and
q
builder
weren't
using
the
delegated
authorization,
which
I
think
would
be
more
in
line
with
what
we
would
recommend.
B
So
if
you
put
something
that
only
knows
about
rbac
in
front
of
a
component
that
might
defy
the
expectations
of
the
person
running
the
cluster,
if
they
said
well,
I
have
a
webhook
authorizer.
Why
is
this
component
like
only
paying
attention
to
our
back
so
as
a
standalone
component?
I
think
david
had
commented
before
like
if
someone
wants
to
bring
it
in
he's
willing
to
take
a
look
at
it.
It
seems
reasonable,
but
I
don't
know
that
we
would
recommend
this
as
like
the
canonical
way
to
protect
a
service
running
in
the
cluster.
A
D
C
C
Doing
localization,
okay,
things
like
you
know,
when
I
terminate
assert,
I
have
this
cert
and
I
know
how
to
terminate
it
without
contacting
the
server.
I
know.
D
J
G
I
B
Okay,
so
it
sounds
like
we're
landing
in
a
similar
place
to
where
we
landed
the
last
time
we
talked
about
it.
It
doesn't
sound
like
there
are
particular
objections
we
might
want
to
tweak
the
name
or
tweak
the
docs
to
talk
about
how
we,
how
it
integrates
and
what
it
actually
does,
but
and-
and
I
do
think
we
want
to
check
with
cluster
api
to
see
if
they
are
using
a
standalone
component
when
they
could
be
using
a
a
baked
in
component,
but.
A
Sorry,
I
was
just
gonna
ask:
presumably
we
want
to
do
some
level
of
api
review
code
review,
just
as
we've
done
in
the
past,
for
like
secret
csi
driver
and
oracle
namespaces
controller,
and
I
I
I
have
the
old
meeting
notes
from
from
march
of
I
guess
last
year,
when
we
talked
about
this,
and
I
said
that
david
looked
like
you
were
willing
to
champion,
but
you
needed
to
do
it
later.
A
C
Yeah,
the
good
news
is
that
surge
can
bug
me
this
time,
but
I'd
be
happy
if
somebody
else
had
a
look
as
well.
J
I
was
going
to
ask
there's
a
the
original
issue.
We
went
back
and
forth
to
this.
We
never
actually
really
resolved.
At
least
I
don't
think
I
remember
us
resolving.
This
was
like
anyone
using
this
proxy
you're
giving
your
token
to
and
before
we
said
we
were
using
it
in
a
system
context,
and
we
were
like
you
know.
The
people
who
use
this
should
be
part
of
the
infrastructure
anyway
and
you're
basically
trusting
your
distro
to
do
this,
and
if
you
do
it,
it's
still
on
you.
J
J
B
For
service
account
tokens
for
sure
we
have
wider
audience
permissions.
I
think
if
you're
talking
to
the
api
server
and
the
api
server
is
proxying
you
through
to
something
like
this,
then
you're
going
to
be
using
tls
header
verification.
B
J
I
wasn't
implying
that
it's
not
useful
to
have
this.
It
would
be
more
around
the
streaming
of
how
we're
like
this.
This
is
an
important
thing
that,
if
you
use
this,
you
need
to
think
about
that.
Maybe
like
we,
we
don't
do
a
great
job
of
nuancing.
In
all
the
cases,
it
should
be
pretty
clear
like
either
it's
safe
or
it's
part
of
the
infrastructure,
or
we
have
something
that
makes
it
not
be
an
issue.
One
of
those
three
is
something
we
have
to
communicate.
B
Yeah,
it
probably
depends
on
what
you're
putting
it
in
front
of,
but
if
we're
going
to
give
an
example,
we
might
want
to
consider
the
example
being
to
specify
the
audience
and
then
say
to
get
a
token
for
this
audience.
You
do
this
and
then
you
can
use
it
against
this
thing
and
you're,
not
handing
your
api
token
to
it.
A
J
A
time
machine
and
go
back
and
write
that
command
yesterday
and
and
honestly
like
this,
this
also
raises
issues
of
like
infrastructure
and
like
tls.
Certainly
we
have
a
whole
mechanism
for
tls
certificate
distribution,
which
also
addresses
it,
whether
we
want
to
use
audience
or
not.
These
are
bigger
types,
because
just
this
is
this
is
a
microcosm
of
the.
J
I
Just
a
small
note,
the
support
for
token
audiences
is
something
that
we
explicitly
added
in
in
this
component,
so
you
can
explicitly
say
what
audiences
to
verify
against.
So
it's
literally
baked
into
the
tool
as
well,
just
as
a
site
and.
J
Maybe
that's
like
sufficient,
like
we
recommend
that
you
always
use
an
audience
for
it,
and
that
also
drives
a
use
case
which
is
hey.
Is
it
really
easy
to
get
an
audience
token
inside
a
pod,
if
only
we
had
some
great
example
of
showing
how
that
you
could
secure
a
really
practical
infrastructure
component
using
tokens
that
don't
require
you
to
pre-bake
a
secret
and
put
into
the
cube
api.
So
like
from
that
angle
like
that
is
a
very
positive
forwards.
G
So
yeah
well
surges
right
that
audiences
are
supported.
I
think,
like
the
main
user,
that
at
least
an
openshift
this
is
used
for
prometheus
does
not
support.
You
know
grabbing
an
audience
token.
J
J
So
right,
that's
what
I
mean
like
an
example
in
cube
docs
that,
like
really
crisply
like
hey,
we
hear
that
people
have
problems.
Securing
things
on
cube
clusters
that
have
infrastructure
components
that
want
to
transparently
look
all
of
the
work
sigoth
has
done
over
the
last
five
years
is
finally
coming
home.
To
look
how
easy
it
is.
I
As
a
suggestion,
I
mean
we
sorry
as
a
suggestion.
We
could
make
this
as
a
prime
example,
like
user
projected
service
account
token,
with
an
audience,
including
an
example.
How
to
configure
cube
object
proxy
with
it.
We
could
literally
make
it
in
the
landing
page
of
the
readme
as
well.
I'm
totally
into
that
and.
J
That
makes
that
makes
the
case
for
it
being
part
of
the
project
stronger,
because
while
there
might
be
scope
and
complexity
but
there's
also
a
look,
this
is
just
a
basic
component.
It
does
what
it
does
on
the
tin,
but
if
prometheus
has
a
use
case
for
it,
maybe
there's
others
who
have
used
cases
for
it,
and
we
can.
You
know,
look
for
some
sort
of
consensus
or
community
alignment
around
things
like
that
logging
has
this
problem,
you
know
17
different
types
of
health
checking
scraping
tools.
Have
this
problem.
A
C
That's
not
a
client
ca.
Well,
there's.
B
C
B
A
A
Yeah
no
sense,
I
I
guess
the
only
thing
there
would
be
is
you
do
need
a
particular
sort
of
our
back
capability
to
read
that
config
map,
but
since
it
is
meant
to
be
sort
of
dynamic,
as
in
the
ca
bundle
can
change,
it
has
some
nice
capability.
I
don't
know
if
there's
a
front
proxy
used
for
this,
but
you
know
that's
also
good.
J
J
What's
the
word
for
it,
the
ones
that
aren't
global
or
the
ones
that
aren't
don't
depend
on
a
pv
ephemeral,
an
external
plug-in
that
like
starting
to
talk
about
standardizing
kind
of
like
some
of
those
interface
level.
You
know,
could
you
mount
the
ca
that
you
expect
these
workloads
to
use,
maybe
not
in
core
but
as
a
there's
like
a
reasonable
set
of
extensions?
J
If
we
have
a
downward
api
and
we
can
manage
config
maps
and
secrets,
it's
kind
of
painful
to
force
people
to
call
the
cube
api
doesn't
mean
they
can't.
But
I
there's
an
argument
here,
which
is
the
same
sorts
of
like.
I
want
you
to
know
about
trust,
and
that
has
a
file
system
representation,
and
I
want
that
to
be
updated.
B
Cool,
so
maybe
that
may
be
a
good
ai
would
be
to
create
a
tracking
issue
and
copy
in
the
items
that
we
talked
about,
like
it's
a
checklist
and
then
tag
the
folks
who
are
driving
it
and
david
and
sound
like
he
wanted
one
more
reviewer
david.
If
there's
a
particular
area
of
the
review
that
you
want
a
second
set
of
eyes
on.
That
would
be
helpful
to
note
and
we
can
find
someone
appropriate.
B
C
A
J
A
Static
pods
work
as
long
as
you
like
do
some
detail:
yeah
yeah,
obviously
don't
change
anything
you
could
just
leave
it
alone,
don't
rotate
anything.
Everything
should
be
static,
okay,
cool,
so
we
had
some
good
stuff
from
this.
We
missed
anything.
If
anyone
wants
to
add
more
notes.
That
would
be
great
who
put
this
on
the
agenda.
E
H
Okay,
so
this
is
follow
on
late
last
year,
ted
and
I
presented
a
cap
around.
It
was
kind
of
wide
ranging
around
certificates
in
the
cluster.
H
This
the
feedback
we
got
on
that
was
extract
like
the
simplest
possible
piece
and
bring
that
back,
and
this
is
that
I
believe-
and
it
kind
of
dovetails
nicely
with
the
discussion.
We
were
just
having
around
distributing
trust
and
root
certificates,
and
things
like
that.
H
Basically,
the
proposal
here
is
that
we
give
cubelet
the
ability
to
request
certificates
from
arbitrary
signers
in
much.
In
the
same
way,
we
give
cubelet
the
ability
to
request
projected
service
account
tokens
in
a
projected
volume
source.
Add
a
similar
projected
volume
source
that
knows
how
to
request
certificates
from
from
in
cluster
signers.
H
It's,
I
think,
pretty
simple,
but
I've
been
kind
of
steeped
in
it
for
about
a
month
now,
so
I'm
a
little
biased
effectively
it
kind
of
works
like
it
says,
on
the
tin,
yeah
cubit
will
just
generate
a
key
minimally
configurable.
Basically,
we
you
can
choose
a
couple
different
rsa
profiles,
a
couple
different
ecgsa
profiles.
C
H
That
is
a
new,
that's
part
of
the
kep
is
proposing
a
thing
called
trust
anchor
sets.
You
can
think
of
it
like
root
certificates,
but
every
time
I
say,
root
certificates.
My
coworker
upgrades
me
and
tells
me
that
they
are
not
root
certificates
because
they
don't
have
to
be
roots.
They
are
trust
anchors.
C
Is
that
is
just
not
that
I'm
I
have
doubts
about
this
particular
cap.
I
haven't
read
it
at
all,
but
that
particular
trust
distribution
mechanism
have.
Is
that
something
you
have
a
specific
small
and
separate
cap
for
or
you're
just
hoping
it
all
goes
in
I
mean
not.
Maybe
it
will
just
that
sounds
like
something
people
wanted
for
a
long
time.
H
I'm
happy
to
split
that
out
further.
We
do
have
a
similar
custom
resource
already
that
we
use
inside
gke,
that's
kind
of
where
the
experience
is
coming
from.
But
if
it's
separately
useful
I'd
be
happy
to
break
it
out
into
a
separate
cap,
because
I
think
I
didn't
realize
how
widely
applicable
it
was.
But
then
the
discussion
we
were
just
having
made
me
think
that
maybe
it's
would
be
useful.
It's
effective!
C
Yeah
I've
had
that
request
from
people
many
times
for
how
do
I
verify
the
csrs?
I
don't
know
mo?
Have
you.
A
Had
similar
requests
yeah,
I
know
that
that
was
my
initial
feeling.
Is
we
hand
waived
the
trust,
distribution
problem
of
the
csr
api?
Just
saying
we
don't
do
it.
So
that's
that
intrigued
me
as
to
oh
we're
doing
it
now.
So
I
I
I
guess,
let's
let's
do
that.
C
Of
the
cap,
so
you
know
all
at
once
might
be
fine,
but
that's
just
a
noteworthy
thing.
A
Okay,
okay,
so
here
could
so
I
could
you
give
us
a
high
level
of
like,
like
maybe
a
flow
of
like
I
don't
know,
I'm
a
pod
author.
What
do
I
do
and
then
like?
What
are
the
actions
the
system
takes
on
that
behavior.
H
H
You
add
a
projected
volume
that
designates
that
signer
says
where
to
put
the
key
and
what
sort
of
key
to
generate
and
where
to
put
the
issued
certificate
in
your
pod
file
system
and
then
kubelet
kicks
off,
creates
the
csr
waits
for
it
to
be
approved.
If
it's
not
approved,
it
blocks
your
pod
from
starting
up.
H
H
Zero,
I
think,
or
very
little.
The
idea
would
be
that
your
signer
needs
to
understand
the
format
that
keyboard
is
generating,
which
is
detailed
at
the
bottom.
It's
pretty
simple.
Okay.
H
A
Okay,
and
so
presumably
the
signer
that
is
handling
this
needs
to
at
least
like
as
a
for
example.
Would
we
expect
the
signer
to
look
at
the
the
user
information
field
on
the
csr
right,
which
would
be
a
cubelet
identity,
and
is
it
expected
to
validate
that
that
cubelet,
for
example,
like,
for
example,
is
it
like
the
node
authorizer?
Is
it
supposed
to
validate
that
that
pod
is
running
on
that
cubelet
and
the
cube
should
be
able
to
do
this.
H
Yeah
at
the
very
bottom,
in
the
csr
format
section,
I
call
that
a
set
of
security
considerations
that
signers
need
to
check.
One
of
them
is
yes
they
for
completeness
they
need
to
either
piggyback
on
the
existing
node
authorizer
check
or
re-implement
an
authorizer
check
in
the
system
we
built
like
this.
We
ended
up
just
re-implementing
the
node
authorizer
check.
A
C
A
A
J
Bootstrap
signer
has
the
ability
to
create
an
un
a
csr
for
itself,
and
then
they
all
have
the
ability
to
renew,
because
the
renewal
is
related
to
who
they
are.
It's
not
quite
the
same
as
general
purpose.
Csr
creation,
because
the
bootstrap
credential
may
actually
not
isn't
used
once
the
cubelet
takes
over.
Unless
somebody
changed
something-
and
I
missed
it
in
the
last
year.
But
so
it's
not
quite
general,
but
it's
not
a
far
step
from
it,
like
you
could
argue
the
cubelet
once
the
cubelet's.
Renewing
its
responsibilities
are
to
remember.
C
J
I
mean
ultimately,
the
authorizer
is
checking
that
you
have
permission
to
do
things
related
to
your
role.
That's
probably
one
of
the
differences
here
actually
between
something.
That's
like
an
entry
plug-in,
and
my
question
about
doing
this
with
an
inline
volume
plug-in,
is
that
in
theory
the
node
authorizer,
which
is
not
extensible,
could
say,
and
yes,
the
cube
is
allowed
to
do
csrs.
For
this
specific
reason,
however,
that's
framed,
but
it
is
a
little
I
mean
the
note.
Authorizer
is
not
extensible
to
the
level
that
would
allow
an
out-of-tree
approach
to
approximate
this
today.
B
H
Yeah,
that's
what
I
was
so
I
had
actually
not
thought
about
whether
or
not
cubelet
has
the
ability
to
create
these
csrs
today
but,
like
tim,
says,
the
more
important
security.
The
consideration
here
is
that
sign,
approvers
and
signers
should
not
be
willy-nilly,
like
they
need
to
be
very
clear
that
they
are
approving
a
certificate
for
a
pod
that
was
requested
by
a
cubelet.
That
has
a
reason
to
be
requesting
stuff
for
that
pod
right.
It.
J
H
Yeah,
I'm
assuming
that
public
kind
of
has
unrestricted
permit
ability
to
create
these
csrs.
Maybe
there's
a
node
authorizer
check
that
says:
hey!
You
need
to
be
requesting
csrs
for
that
represent
only
pods
that
you're
running,
but
that
would
require
looking
deep
inside
the
csr
object
itself
at
authorization
time,
but
as
a
property.
J
C
J
Cubelet
is
allowed
to
request
this
csr
because
this
pod
is
on
it
that
requests
this
service
account,
which
would
be
in
what
was
kind
of
what
I
meant
by
inheriting
the
chain
of
trust
like
the
cubelet
is
authorized
to
grant
permissions.
That
is
a
subordinate
to
itself,
and
then
I
guess
the
question
is:
is
that
is
the
trust
anchor
a
crossover
to
a
different
trust
domain
as
well.
H
I
think
the
check
has
to
be
done
in
both
places.
Then
node
authorizer
say
that
cubelet
is
allowed
to
create
the
csr
and
then
the
signer
or
the
approver
component
of
the
signer
needs
to
do
whatever
security
checks.
It
feels
are
necessary,
including
a
repeat
of
the
node
authorizer
check,
probably.
K
I'm
not
sure
about
the
first
one
or
the
value
of
the
first
one.
We
already
have
that
the
create
of
the
from
the
csr
api
is
not
sensitive,
and
I
think,
like
a
model
that
would
be
sort
of
probably
fine
today,
would
be
for
a
node
for
one
one
of
these
signers
or
csr
approvers
to
just
issue
a
subject.
Access
review
for
create
token
for
the
pod
or
something
that
would
be
a
good
approximation,
but
yeah,
I
don't
think
create,
is
particularly
sensitive
and.
J
K
J
J
Today,
I
guess
that's
what
I'm
saying
I'm
I
wouldn't
make
this.
I
don't
think
that
this
necessarily
has
to
take
on
the
responsibility
for
going
and
doing
that,
but
in
terms
of
pushing
in
the
right
direction,
but
you're
right
mike
and
actually
like.
If,
if
the
I
mean
the
fundamental
permission
here
is
that
the
cubelet
is
allowed
to
impersonate
the
service
account
through
a
pod,
and
we
don't
talk
in
those
terms
and
I'm
not
even
arguing.
A
I
was
going
to
go
back
to
david's
point.
I
think
david
you
had
mentioned
so
this
conversation
we
just
had
covers
the
authorization
of
the
cubelet
to
create
slash,
approve
these
and
the
signers
verification
of
that.
Before
doing
this
extra
signing
and
updating
certificate,
I
think
david.
You
had
asked
about
the
other
side,
which
is
the
pod
itself,
requesting
the
use
of
a
particular
signer,
and
I'm.
H
A
J
It's
kind
of
an
interesting
like
comparing
this
to
the
previous
discussion
of
like
audience.
It's
effectively
this
ca,
the
ca
trust
is
a
proxy
for
who
the
audience
is,
and
the
use
just
like
audience
is
a
proxy
for
a
human-defined
thing.
It's
a
little
bit
of
physical
pain
that
they're
not
there's
no
mapping
between
those
concepts,
but
I
don't
know
that
it's
our
job
to
and
if,
like
we
were
talking
about
like
building
blocks,
there
are
some
elements
of
this
that
nothing
prevents
potentially
adding
on
additional
metadata
in
the
future.
H
So
one
open
question
I
have
about
this
is
whether
or
not
so
we
have
this
long
section
on
csr
format
and
it's
not
clear
to
me
that
any
of
this
data
actually
needs
to
be
inside
an
x509
csr.
It
could
just
be
on
the
kubernetes
csr
object,
but
I
haven't
thought
through
the,
like:
maybe
security,
implications.
J
It's
weird
because
it's
a
little
bit
like
the
the
actual
certificate
request
carrying
it
opens
some
door
for
interrupt
with
complex
signing
implementations
and
we
all
know
how
popular
complex
signing
implementations
have
been
and
how
successful
they
are,
and
so
there's
kind
of
a
I
kind
of
have
this
I
reading
this
I
was
like.
Oh
that's
good.
A
A
question
related
to
this
has
I
I've
had
this
use
case
in
the
past,
but
I
don't
know
others
have
where
I
have
like
a
privileged
actor
that
I
want
to
create
csrs
using
for
a
less
privileged
actor,
but
I
don't
want
the
less
privileged
actor
to
like
control
any
of
the
csr
fields
right.
I
basically
just
want
the
public
key
of
the
less
privileged
actor
and
it's
the
csr
api
is
weird
in
the
sense
that
I
actually
need
a
fully
signed.
Csr
object
to
you
know
get
through
the
whole
flow.
A
Presumably
you
know
it's
like
what's
what's
missing
there
today
is
the
fact
that
you
can't
specify
basically
the
the
data
that
you
get
through
the
csr
and
the
public
key
separately
right
like
from
what
I've
understood
that
the
security
properties
of
the
csr
kind
of
not
necessarily
based
on
the
threat
model,
that
I
necessarily
understand
that,
like
the
idea
is,
you
know,
you're
asserting
that
the
actor
who
you're
signing
the
csr
for
has
the
private
key
and
they
signed
over
this.
A
H
I
think
I
think
you're
right
that
in
this
case
we
don't
gain
anything
by
having
these,
like
pod
uid,
odd
name
signed
by
signed
by
the
key,
because
they're
being
they're
like
extra
extra
metadata,
that
we
only
trust
because
we
know
they
come
from
cuboid,
not
from
the
pod.
J
And
the
cube
is
the
one
creating
the
csr
in
this
case,
so
there
is
a
little
bit
of
it's
funny,
because
it's
the
world
would
be
a
better
place
if
everything
came
with
well
formatted
and
extensive
metadata
that
allowed
you
to
use
it
in
situ
without
having
to
build
a
more
complicated
integration.
J
So,
like
sometimes
the
if
you've
got
a
place
to
put
the
metadata
and
it
doesn't
hurt,
I
usually
would
tend
to
the
be
somewhat
judicious
or
be
generous
in
terms
of
the
metadata
we
set,
because
as
long
as
we
can't
come
up
with
a
use
case
like
as
you're
asserting,
which
is
this
is
wrong.
Who
am
I
trusting
to
do
this.
A
I
I
think,
the
bit
that
this
prevents
so
the
problem
I
had
with
the
flow
that
exists
today
is.
I
could
not
in
this
case,
if
I
understood
correctly,
the
private
key
for
that's
associated
with
the
certificate
is
generated
by
the
cubelet
on
behalf
of
the
pond.
It
cannot
be
the
the
pod
can't
instead
generate
its
own
private,
key
somewhere
else
and
just
provide
the
public
key
right.
A
J
It's
kind
of
a
fundamental
difference
in
scenario
too,
like
this
is
extending
the
cubelet's
chain
of
trust
the
same
in
a
compatible
way
to
our
comparable
way
to
service
account
token,
I
guess
maybe
another
question
here
is
and
that
that
triggered
it
mo.
I
I
want
to
prevent
your
question
from
being
answered.
One
of
the
other
things
that
that
you
know
asks
is:
is
there
a
scenario
where
this
is
something
that
other
elements
within
the
cubelet
would
like
to
use
a
private
key?
J
So
we
have
a
few
cases
and
examples
where,
like
service
account,
token
like
a
sidecar
might
want
it
or
an
integration
running
on
the
node
might
want
it
that
we
don't
we
haven't
really
developed
so
like
maybe
the
other
ask
here,
would
be
like
a
couple
of
kind
of
use
cases
that
you
intend
just
to
make
sure
that
we
can
frame
that
in
the
right
case.
L
H
J
J
And
so
I
was
just
thinking
like
you
know,
a
csi
plug-in
or
an
istio
plug-in
implemented
at
the
infrastructure
level
that
gave
the
container
something
that
allowed
it
to
say
who
it
was,
but
it
never
actually
saw
that
private
key.
I
didn't
know
if
that
was
something
that
was
you're
thinking,
and
maybe
this
is
a
use
case.
Canvassing
thing
that
might
help.
J
Fine,
when
your
cluster
is,
you
know
only
one
tenant
or
one
user,
so
just
something
I
was
coming
up,
so
a
set
of
use
cases
in
the
dock
would
be
great
and
then
maybe
like
if
we
could
poke
a
little
bit
at
who
else
might
want
to
use
this
private
key
and
what
are
the
use
cases
and
are
there
any
implications
on
the
design?
I
didn't
know
what
your
eyes
use.
Cases
were
so.
H
It
I
made
some
effort
to
make
sure
that
the
proposal
also
works
for
people
who
want
serving
certificates.
J
And
michael
telfen's,
private
private
pull
tokens
right
like
there's
an
argument
that
the
cubelet
is
actually
doing
the
pulling
on
a
user's
behalf,
and
so
there
is
a
shortcut
of
you
know
that
indirection
that
might
be
useful,
with
private
keys
for
external
registries
or,
for
you
know,
somebody
needs
to
prove
the
cuba
needs
to.
J
The
cubelet
would
ideally
like
to
have
a
credential
that,
if
exposed,
is
minimally
broad
if
it
has
to
give
a
credential
like
a
token
to
someone
who
wants
to
scope
it
private
keys
are
a
little
bit
easier,
so
it
may
not
be
necessary.
Just
something
also
like
crosses
over
the
private
key
does
have
advantages
over
the
service
account
token
in
terms
of
exposure
and
keeping
the
private
key
out
of
the
pod
altogether
has
some
interesting.
H
You
are
writing
a
job
and
you
need
to
make
a
encrypted
connection
to
someone
else,
but
you
don't
have
the
private
key.
Instead,
you
send
a
message
to
a
local
sidecar.
You
know
node
level
side
card.
That
is
keeping
all
your
keys
in
a
in
a
in
an
hsm
and
it
does
the
tls
connection
setup
and
then
hands
you
back
an
initialized
connection
through
magic
yeah,
it's
much
harder
to
think
about
how
to
oh.
J
I've
certainly
seen
a
number
of
those
and
that's
partially,
why
I'm
probing
here
whether
this
is
whether
there's
other
types
of
things
that
we
could
like
laying
the
foundation
here
and
then
also
being
able
to
go,
and
you
know,
look
at
you
know
this
would
dramatically
up
level
security
of
most
workloads.
Most
people
are
just
really
bad
at
setting
up
tls
certs
anyway,
so
I'll
add
a
few
more
comments
to
the
doc.
Thank
you,
though.
Okay.
A
Too
much
time
for
discussion,
so
this
does
seem
like
a
really
good
topic
to
hear
which,
like
which
piece
of
this
are
you
wanting
to
tackle?
Like
I
know
you
know,
david
had
mentioned
trying
to
pull
out
the
ca
distribution
problem,
basically
that
that
shrubby
is
smaller,
though
I
don't
know
how
contentions
I'm
sure
folks
have
opinions
on
how
they
won't
get.
C
H
L
I
E
I'll
put
it
on
the
agenda
for
next
yeah.
Let's
do
thank
y'all,
we'll
see
you
all
in
cubics.