►
From YouTube: Kubernetes SIG Auth 20171004
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20171004
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
All
right
welcome
this
is
the
cig
off
meeting
for
October
4th
2017
got
a
pretty
full
agenda,
so
we'll
go
ahead
and
jump
in
before
we
get
to
demos
and
designs
and
planning.
Are
there
any
announcements
that
people
have
or
would
like
to
make
the
only
one
I'm
aware
of
is
the
retrospective
for
the
one
eight
release
that
is
scheduled
for
later
this
week?
A
A
So
this
is
a
tool
that
I
am
shamelessly
stealing
name
from
audit
to
allow.
So
it
consumes
kubernetes
audit
logs
and
takes
a
username
and
looks
for
things
that
that
user
did
and
generates
our
back
rolls
and
bindings
for
that
user.
That
covers
the
things
that
that
user
attempted
to
do,
and
so
I
wanted
to
demo
that
real,
quick.
A
A
C
A
A
That's
something
that
I
expect
to
be
able
to
control
in
the
future
and
say
I
want
to
expand
verbs
or
not,
but
this
is
kind
of
codifying
some
best
practices
so
that
those
set
of
permissions
are
typically
granted
together.
It's
only
letting
you
get
them
in
the
default
namespace,
so
I
only
got
pods
in
the
default
namespace.
So
it's
only
going
to
grant
or
generate
a
role
that
lets
you
get
them
in
the
default
namespace.
If
I
tried
to
get
them
in
some
other
namespace.
A
Typically
that
means
you're
doing
it
at
the
cluster
level,
and
so
it
actually
changed
it
from
being
a
role
in
one
particular
namespace
up
to
a
cluster
role
across
all
namespaces
and
again
this.
This
would
be
something
you
could
say:
I
want
you
to
do
these
Auto
expanding
options
or
not,
and
so
something
I
have
running
in
the
background
is
an
apply
loop.
A
So
this
roles
definition
that
I've
been
auto-generating
I
am
also
Auto
applying,
and
so,
if
I
tried
to
do
that
thing
that
I
just
did
and
got
forbidden
I
am
now
allowed
to
do
it,
and
so
you
could
imagine
sort
of
this
three-step
process.
A
user
or
application
tries
to
do
things.
Those
auto
events
get
captured
and
roles
get
generated
from
those,
and
then
those
auto-generated
roles
could
be
audited
or
can
go
into
an
automatic,
apply
loop
and
be
audited
later.
A
It's
basically
a
really
nice
way
to
quickly
develop
roles
that
cover
the
the
behavior
that
an
app
or
user
requires,
and
so
you
could
run
this
locally
in
a
dev
cluster
and
then
take
those
generated
roles,
audit
them
and
apply
them
to
production
system.
So,
and
you
can
see
this
four
different
actions
as
well.
A
Well,
anyway,
that's
that's
the
core.
The
demo,
the
the
audit
feeding
role
generation,
feeding
applying
looping
back
to
automatically
allow
the
system,
and
the
nice
thing
about
triggering
this
off
of
the
audit
logs-
is
that
we
have
audit
logs
whether
or
not
the
initial
action
was
permitted.
So
in
this
case,
I
tried
to
do
something
got
forbidden,
but
the
information
that
I
tried
to
do
it
was
still
captured.
A
So
you
can
decide
for
yourself
whether
you
want
to
kind
of
give
this
thing:
elevated
permissions,
while
you're
in
the
role
development
phase
and
just
let
it
do
what
it
needs
to
do
and
build
a
rule
that
way
or
if
you
want
it
to
be
denied
until
the
the
role
gets
audited
and
applied.
So
you
can
work
either
way
so
yeah,
so
I'd
encourage
you
to
pull
it
down
check
it
out.
Like
I
said:
I
have
lots
of
things,
I
want
to
go,
add
to
it,
but
it's
a
pretty
useful
already.
F
F
A
A
I
know
there
were
a
few,
a
few
issues
that
came
around
the
one
night
release
around
cert
rotation,
that
impacted
cube,
Adam
and
and
some
things
that
we
might
want
to
take
a
look
at,
but
I
think
that
would
probably
be
better
done
in
a
retrospective
type
setting
where
people
have
time
to
look
at
them
and
prep.
So
we
can.
We
can
mention
them
here,
but
I
think
it
might
be
a
good
idea.
A
G
A
So
the
the
primary
thing
that
I
want
to
do
with
the
scope
of
node
on
node
is
to
work
with
probably
Mike,
and
some
of
the
folks
in
cig
note
to
just
agree
on
a
strategy
going
forward
so
that
the
node
isn't
blocked
on
what
it
needs
to
do.
But
people
who
also
were
trying
to
partition
their
cluster
can
understand
what
they
can
well.
They
can
trust
and
not
trust
if
they're
trying
to
trying
to
protect
from
things
that
nodes
could
set.
A
B
A
But
this
is,
this
is
related
to
some
of
the
container
identity
work.
That's
going
on,
it's
not
exactly
the
same,
but
it's
related,
which
is
as
more
things
desire
identity
for
a
broader
variety
of
reasons,
not
just
talking
to
the
key
baby.
I
I
think
we
want
to
get
ahead
of
the
instinct
to
just
reuse,
the
QAPI
tokens
as
credentials
for
other
services.
That's
that's
not
something
we
want
to
encourage,
but
so
we
want
to
have
a
recommendation
either.
A
C
C
Sorry
about
that,
did
you
guys
hear
what
I
said?
No,
can
you
hear
me
now
yeah,
all
right,
I
was
just
saying:
Mike's
design
is
sort
of
one
possible
path
for
a
pluggable
identity
or
one
one
route.
So
it's
worth
looking
into
even
if
you're
not
specifically
interested
in
passing
JW
tees
around
to
places
yeah.
A
F
So
my
biggest
concern
here
and
I
apologize
Mike.
This
is
not
something
I've
expressed
before
this
is
one
of
availability
generally
so
much
of
kubernetes.
If,
if
the
control
plane
is
gallant,
things
continue
to
cruise.
If
you
need
an
API
server
to
mint
new
JWT
s,
because
these
things
are
pair
wise
and
it's
like
N
squared
with
the
number
of
services
talking
to
services
or
n
by
M,
then
then
that
requires
a
higher
level
availability
for
the
API
server
than
we've
seen
in
the
past,
and
so
because
it's
all
centralized
like
that.
F
J
K
K
I
think
you
can
still
have
I
think
you
can
have
both
I
think
bolting
on
is
almost
orthogonal.
If
we
do
it
right,
the
question
is:
is
should
like
I
mean
just
matically
I.
Think
there's
some
level
of
even
if
we
all
agree
like
on
this,
call
that
the
right
thing
to
do
is
to
put
something
new
into
cube.
The
right
thing
for
us
to
do
as
a
project
is
to
do
it
plugged
into
cube
in
a
very
particular
way
and
still
be
available
right.
J
Yeah,
so
I
would
say
that
the
that
we
need
to
not
conflate
the
the
strong
principle
identity
with
the
way
of
that
ID
that
a
workload
identifies
as
that
identity.
Would
you
say
that
that
is
correct,
so
I
guess
this?
The
distinction
should
be
made
between
service
accounts
and
service
account
tokens.
Yes,.
K
Service
accounts
very
long
time
service
account
tokens.
Ideally,
the
mechanisms
where
my
pods
get
access
to
a
token
is
somewhat
with
the
mechanisms
and
the
details
in
the
verification
path.
We
try
to
focus
on
the
preserving
the
use
cases
we
have,
while
gradually
making
that
better
I
don't
think
that's
I'm
not
disagreeing
when
they
think
you're
saying
actually
just
like
the
focus
is
on.
If
we
can
show
these
things
being
split
out,
we
start
pushing
the
whole
project
in
the
right
direction.
K
I
was
looking
to
work
with
somebody
on
to
prototype.
Maybe
like
that's
something
like
you
and
I
can
can
talk
more
about
afterwards,
like
I
had
started
to
go
work
at
the
Flex
volume
side
for
injecting
shots
or
plasma
qualities,
but
forcing
to
use
the
extension
mechanisms,
authorizer
initialize,
their
API
application,
flex
volume
and
there's
one
more
to
go
through
that
exercise
out.
If
it
can't
be
done,
we
don't
have
good
enough
extension
mechanisms.
J
J
What
the
intent
was
with
the
jot
Minter
and
the
the
verifiable
workload
jots
is
to
give
us
a
way
of
interacting
with
a
third-party
or
external
identity
providers
and
gives
us
something
that
we
can
start
to
work
on
now
that
is
achievable
before
the
pot
identity.
Settles
I
wanted
to
figure
out
what
we
could
do
outside
of
the
critical
path
of
pot
identity
or
to
remove
identity
from
the
critical
path.
This
seems
like
a
way
forward.
I,
don't
know
if
you
guys
saw
the
vault
kubernetes
integration.
E
J
J
D
By
just
as
a
heads
up,
my
name's
Andy
minovsky
I'm,
the
product
manager
for
vault,
so
just
to
clarify
the
integration
point
that
we
have
when
vault
is
in,
like
an
initial
rebbe's.
So
stuff
like
this
is
definitely
things
that
we're
interested
in
learning
about,
as
we
try
to
iron
out
better
ways
to
integrate
the
within
the
authentication
infrastructure,
crudities
yeah.
A
F
Options
that
could
have
integrated
but
I
think
for
now
I
think
the
one
thing
and
I'm
looking
through
this
now
to
make
sure
you
know
Mike
is
the
whole
audience
thing
and
I.
You
know
the
big
thing
is
like
who
is
jewelry
minting
this
job
for
and
then
how
do
we
actually
enforce
that
when
people
verify
the
job
they're
actually
verifying
it
in
a
way,
that's
that
that
makes
these
things
be
pairwise,
instead
of
being
able
to
sort
of
pass
them
around
and
I.
Think
that's
going
to
be
an
important
part
of
the
ecosystem
here.
J
J
Are
two
integrations
one
integration
is
Fault
and
when
in
integration
is
GCP,
those
are
example
integrations.
But
basically
what
happens
is
when
you
talk
to
a
API
that
trusts
you
or
the
Java
API
that
trust
you,
you
prove
yourself
to
the
Java
API
and
you
say:
I
need
a
job
for
this
amount
of
time
and
I'm
gonna,
send
it
to
this
person.
So
audience
is
at
the
is
requested
by
the
requester
of
the
jot
and
you've
aim,
your
audience
to
who
you
expect
to
send
the
job
to
you.
You.
J
F
I'm
not
worried
about
them,
I'm,
worried
about
other
folks
that
are
gonna,
follow
this
pattern
I
think
like
if
we
have
two
services
talking
to
each
other
and
they're
using
these
things,
the
general
pattern
is
just
copy
paste,
some
code
that
looks
to
work
and,
as
you
copy
paste,
a
code
making
sure
that
you
use
an
unique
audience
per
target
is
going
to
be,
is
going
to
be
important
part
of
it.
So
just
thinking
in
terms
of
the
ecosystem.
F
K
F
And
as
we
you
know,
if,
if
we
do
this
integration
using
something
like
Flex
volumes,
it's
kind
of
a
one-way
communication
and
so
specifying
all
the
audience's
that
you
might
want
to
talk
to
up
front.
Maybe
in
your
manifest,
is
gonna,
be
problematic
versus
actually
saying
well
now,
I
want
to
talk
to
this
new
audience.
Give
me
a
new
job
for
that
and
so
I
think.
That's
one
advantage
of
sort
of
the
lay
the
lay
the
the
creds
down
on
disc
approach
versus
the
offer
for
another
API
approach.
No.
H
K
I
was
mostly
approaching
this
from
the
end
when
we
think
about
how
we
do
this.
It's
this
trying
to
find
mechanisms
that
force
people
to
not
give
their
service
account
token
out.
It's
the
flex
volume
approach
at
least
one
of
them
is
that
we
can
do
examples
that
show
a
flex
volume
with
an
audience.
I'm
not
saying
audience
is
gonna
take
over
the
world.
Another
one
is
like
client
cert,
which
is
in
both
of
those
examples.
We
want
to
try
to
find
ways
to
make
the
pattern
that
you're
highlighting
be
sustainable
yeah.
K
F
J
F
States
so
I
have
an
entity
in
in
kubernetes,
which
is
my
service
account
and
I
want
to
actually
use
that
identity
to
authenticate
myself
against
vault.
Now
vault
is
happening
to
give
me
secrets,
and
maybe
we
have
you
know
other,
like
sort
of
intermediate
mechanisms.
It's
essentially
a
pairwise
identity,
translation
right.
It's
a
bearer
token
of
all
right,
yeah,
a
one-shot.
J
F
K
And
maybe,
as
a
concrete
thing
here
like,
we
actually
do
need
a
case
where
you
can
get
an
identity,
proving
token
that
the
server
does
something
better
than
what
it
does
today,
which
is
let
unauthenticated
users
verify
tokens
and
verify
that
they're
at
like
I.
Think
I
don't
feel
like
we're
that
far
apart
they're
like
we
want
a
way
to
non.
K
B
It's
another
case
where
you
really
would
like
to
talk
to
the
API
and
like
generate
token,
that
only
valid
for
the
dashboard
that
the
dashboard
can't
then
necessarily
I,
don't
know
that
feels
kind
of
messy
and
similar.
But
it's
also
different
enough
from
the
service
account
use
case,
because
in
that
case
you
have
humans,
reusing
the
dashboard
yeah.
A
All
right,
it's
2:30.
Let's
continue
to
discuss
this,
but
not
in
this
meeting
wanted
to
really
quick
get
a
sense
for
what
people
are
looking
at
working
on
four
one,
nine,
the
one
nine
release
is
actually
really
short,
so
the
schedule
is
so
being
discussed,
but
it
looks
like
they're
proposing
early
December
release,
so
that's
two
months,
which
is
basically
a
month
of
dev
time
starting
now.
A
So
my
guess
is
that
things
that
are
currently
in
progress
and
pretty
well
scoped
is
all
that
we're
we're
going
to
make
in
one
nine,
so
I
just
wanted
to
go
through
this
list.
Pretty
quick.
There
are
some
be
good
to
have
names
associated
with
all
of
these.
Some
of
these
crossed
sig
issues
would
be
good
to
identify
specific
people
we
can
coordinate
with,
but
I
know.
Tim
and
I
are
working
on
pod
security
policy.
A
Getting
that
a
couple
last
issues
around
undefined
behavior
with
multiple
matching
policies,
ironed
out
and
Tim
and
Greg-
had
been
working
on
policies
for
GCE
gke
for
about
a
release
now,
but
had
been
blocked
by
some
of
the
API
issues.
So
I've
got
pulls
open
to
resolve
the
and
to
find
the
behavior
when
multiple
policies
match
and
Tim
has
a
pull
open
with
policies.
That
would
let
us
enable
this
in
CI
ete
runs,
which
is
a
big
step.
That's
that's
a
good
thing
to
do
and
the
kind
of
big
question
mark
I
had.
A
I
know
we
are
trying
to
remove
the
extensions
API
group
and
positivity
policy
to
still
live
in
that
api
group,
and
so,
like
all
the
other
objects
that
started
life
there,
they
will
need
to
move
to
an
appropriate
API
group
and
I
wasn't
sure
what
what
that
would
be.
We
have
the
policy
API
group
which
currently
has
pod
disruption,
budget
objects,
so
it
kind
of
made
sense.
It's
populated,
API
policy
objects,
I,
wasn't
sure
how
other
people
had
opinions
or
we.
K
We
have
won
a
peg
group
for
every
API
I'm
going
to
kill
somebody
yeah
and
I
mean
so
maybe
we
should
say
we
definitely
only
want
to
put
things
in
the
same
group
if
they're
logically
related,
and
we
could
convince
ourselves
that
they
are
fundamental
to
kubernetes
and
logically
fundamental
to
each
other
like
you're
right,
like
the
bucket
of
cause.
Anything
this
pod
relating
gets
ugly
disruption.
K
A
The
next
item
was
the
node
label
on
taint
restriction
and
I
actually
split
the
label
on
taint
restriction
out
from
the
address
restriction,
because
I
think
the
label
and
taint
restriction
is
much
better
scoped
and
has
a
pretty
reasonable
path
forward.
The
address
restriction,
stuff
gets
into
like
cloud
provider
like
who's
the
authority
of
the
addresses
on
the
node.
Is
it
no
controller
or
cloud
provider?
What
do
you
do
in
non
cloud?
Provider
or
situation
is
just
a
little
Messier,
so
I
actually
split
those
into
two.
A
F
G
So
one
of
the
our
back
has
been
great,
but
one
of
the
problems
we've
had
with
it
has
to
do
with
I
had
a
custom
resource
definition
or
I.
Had
a
user
API
server
now
I
have
new
resources
and
I
want
to
be
able
to
provide
our
back
rules
around
them,
and
I
would
really
like
to
have
a
normal
admin
role.
Do
what
I
wanted
to
do,
where
I
have
an
admin
for
a
namespace
and
now
I
had
an
operator
to
it,
and
they
should
go
to
create
one.
G
G
A
A
G
B
So
I
so
yeah
I
discussed
with
we
had
a
discussion
with
Daniel
here
as
well
too,
and
we
talked
about
the
the
kind
of
out
of
process
extension
point
and
making
that
so
there's
an
open
issue
for
that
which
we
also
discussed
a
lost
ago.
So
I
think
the
agreement
was
the
that
that
volt
could
go
in
as,
like
a
you
know,
getting
getting
a
second
implementation
of
this
thing
is
a
good
thing,
but
there's
definitely
gonna
be
resistance
to
more
of
them
without
this
extra,
without
this
extra
kind
of
had
a
process
API.
B
Having
said
that,
I
don't
think
that
API
is
super
complicated
and
so
Jacob
on
outside
is
going
to
take
a
look
at
working
on
that
this
quarter.
But
if
there's
others
that
kind
of
potentially
going
to
be
blocked
by
that,
and
they
probably
want
to
think
about
helping
out
and
helping
drive
that
that's
why
I
left
a
lot
I.
Look
this
as
tentative
there's.
Also
a
bug
filed
for
an
azure
version
as
well.
I'm,
not
sure
if
that's
actively
being
worked
on,
but
there
is,
there
is
a
there
is
a
bug
open.
A
All
right
you
mind
a
kind
of
adding
a
note
with
names
of
folks
who
were
looking
at
that
out
of
process.
One
I
think
if
we
want
to
ask
people
to
wait
for
a
out
of
process
method,
we
at
least
need
to
be
clear
about
the
process
or
the
progress
and
kind
of
expected
arrival
date
of
that
yep
I'll.
Do
that
all.
E
This
is
just
very
early
stages:
I
want
to
make
some
improvements
to
our
current
container
isolation
story,
a
lot
of
its
kind
of
grown
ad
hoc
over
the
years
and
is
very
hard
to
use
some
of
it
feels
sort
of
bolted
on,
and
so
I'd
like
to
take
a
step
back
and
figure
out
how
all
the
pieces
fit
together.
What
is
the
kind
of?
E
What
is
the
story?
We
want
to
build
around
that?
How
do
things
like
the
M
based
pods
fit
into
that,
and
so
I'm
hope
that
this
release?
It's
not
really
part
of
the
release
exactly
but
to
put
out
some
kind
of
design
vision,
type
documents.
So,
if
anyone's
interested
in
this
topic,
please
reach
out
to
me,
it.
A
A
All
right,
I,
one
thing
that
I
noticed
here
it
wasn't
here
was
some
of
the
cert
rotation,
clients,
rotation,
so
I
know
that
we
kind
of
hit
some
issues
around
the
one.
Eight
release
and
I
know:
Clayton
has
been
digging
into
looking
looking
into
using
it
on
the
open
ship
side
and
how
to
pull
open
with
some
changes.
Jacob
or
Mike.
Do
you
know?
Did
you
have
plans
to
look
at
this
more
and
the
one
nine
release
this.
L
Somebody
wants
to
send
that
to
me
or
make
a
reference
I'll
see
what
I
can
get
some
more
contacts
on
that,
but
we're
still
working
on
this
and
and
adding
to
it.
I
didn't
add
any
information.
I
didn't
add
the
link
in
time,
but
we
do
have
a
significant
pull
request
for
a
new
controller
to
clean
up
old
certificates
and
I.
J
It
is
up
in
the
links
for
this
meeting
I
think,
there's
a
lot
of
testing
to
be
done
around
the
specific
failures
that
Clinton
started
to
uncover,
and
one
of
the
one
of
the
questions
is
how
to
fall
back
once
the
cubelet
client
certificate
is
is
expired,
so
these
are
things
to
ponder
over
the
next
release
or
well,
the
API
still
beta
and
they're.
Definitely
on
our
radar
to
figure
out
yeah.
A
L
A
There
were
three
issues:
one
was
that
the
upgrade
instructions
didn't
add
the
permissions
for
a
node
to
automatically
rotate
its
client,
sir,
and
so
you
had
to
go,
approve
it
manually.
So
there's
on
the
very
first
start,
the
node
would
start
up
and
try
to
rotate
and
then
block
waiting
for
manual
approval.
Once
we
got
past
that,
then
we
hit
B,
it's
persisting
them
in
a
transient
directory
that
goes
away
on
reboot
issue.
There
it's
been
a
fun
week:
okay,.
J
L
I
do
remember
the
so
that
I
in
the
context
of
the
current
implementation,
we
would
essentially
be
using
the
original
certificate
and
using
that
to
request
the
new
certificates.
However,
the
idea
is
that
that
a
better
implementation
would
make
the
original
certificate
replaced
by
a
more
a
better
mechanism
like
on
GCP.
It
would
be
some
information
about
the
node
itself
that
will
allow
us
to
authenticate,
instead
of
trying
to
use
that
long-lived
certificate.
But
the
idea
what,
instead
of
perpetually
renewing
based
on
the
existing
certificate.
F
F
A
Kind
of
gets
into
immediately
into
like
well.
What
does
it
look
like
on
this
cloud
or
that
cloud
or
this
provider
that
provider,
which
isn't
to
say
we
can't
do
it,
but
I
I
think
we
need
to
make
progress.
I
expect
that
records
to
be
slow
as
soon
as
you
hit
a
and
then
it
looks
different
in
every
environment,
type
of
type
of
position,
right.
J
F
J
Well,
so
that
that's
why
it's
poorly
named
so
I'm
talking
about
the
node
bootstrap
identity,
is
in
the
I'm
talking
about
the
node
bootstrap
role,
so
the
node
bootstrap
role
is
a
role
that
allows
read
and
create
access
to
these
certificates
API
so
essentially
the
cubelet.
When
are
the
process
that
builds
the
cubelet
certificates
whenever
it
needs
to
refresh
or
it
initially
create
a
cubelet
certificate,
it
uses
a
separate
identity.
What
we
have
today
is,
after
the
initial
creation
of
the
cubelets
certificate,
that
cubelets
certificate.
It
assumes
that
role
and
we
reuse
that
cubelet
certificate.
A
J
A
H
A
Then
you
really
do
want
to
expire
or
revoke
that
token,
as
soon
as
you're
done
setting
up
your
node
group.
If
we
want
that
token
to
continue
to
be
valid,
to
submit
CSR's
long-term
or
as
a
fallback
or
a
bedrock
case,
then
we
need
to
be
approving
those
based
on
something
else,
like
additional
data
in
the
CSR
that
came
from
an
attestation
doc
that
only
the
note
had
access
to
well.
F
It
seems
like
there's
two
overlapping
concerns
here,
so
one
of
them
is
enhancing
security
by
making
sure
that
you
have
that
you
can
take
advantage
some
sort
of
out-of-band
bedrock
at
attestation
right
and
then
the
other
concern
is
making
sure
that
you
don't
strand
nodes.
If
something
happens,
you
don't
actually
rotate
a
time
right.
F
A
A
F
A
J
J
A
Long
as
we
can
get
good
coverage
of
the
good
exercise,
both
cases
I
don't
object
to
short-circuiting.
If
we
have
a
bet
right
at
a
station
to
go
back
to
you,
I
just
want
one
of
the
things
that
we
realized
this
week
was
we
don't
have
good
coverage
of
this,
and
people
are
starting
to
use
it
so,
but
whatever.
H
F
So
I
wanna
I
want
to
spend
five
minutes
to
talk
about
the
discussion
item
that
I
put
on
the
end
there.
Okay,
so
there's
this
token
review
API,
it's
essentially
undocumented
my
understanding
at
least
reading.
The
tea
leaves
is
that
it
was
built
for
the
cubelet
and
other
folks
has
started
using
it.
The.
A
F
See
so
somebody
else
can
implement
this,
that's
not
the
case,
yep
yeah.
That
makes
sense
so
it's
like.
So
it's
for
external
token,
auth
token
review,
and
then
it's
also
for
the
cubelet,
because
we
don't
have
a
good.
You
know
a
good
mechanism
short
of
trusting
the
couplet
to
call
back
with
this
stuff
right,
I.
C
I
think
they
got
it
pretty
much
right,
like
the
the
API
object
was
introduced,
that
we
could
have
a
web
hook.
We
going
through
that
we
didn't
really
breach
the
actually
serving
the
API
from
the
API
server
and
then
later
it
looked
like
it
would
be
a
useful
way
for
cubelets
to
be
able
to
delegate
service
account
authentication
without
having
to
pass
around
public
keys.
F
A
F
F
A
E
F
L
F
F
A
Alright,
we
are
out
of
time.
This
is
good,
keep
in
mind
the
timeframes
for
one
nine
design
stuff,
especially
let's
get
out
early,
so
we
can
get
feedback
and
not
be
trying
to
review
designs
and
implementations
at
the
same
time.
That's
not
that's
not
great
and
try
to
get
get
some
of
this
stuff
knocked
out
in
one
night,
I
appreciate
it.