►
From YouTube: sig-auth bi-weekly meeting for 20230913
Description
sig-auth bi-weekly meeting for 20230913
A
Hey
everyone:
this
is
the
Sig
auth
meeting
for
September
13th
2023.
We
have
a
few
items
on
the
agenda,
so
I
guess
we
can
get
started.
B
Yeah
I
can
do
a
very,
very
brief
review,
I've
gone
through
and
actually
updated
this
now
and
filled
out
a
lot
more
sections
and
a
few
additional
user
stories.
So
to
summarize,
it's
kind
of
in
two
parts,
one
of
them
is
including
well
yeah.
One
of
them
is
including
a
unique
identifier
on
every
token
service
account
token.
B
We
issue
our
bound
service
account
token,
that
we
issue
and
then
in
order
to
be
able
to
like
cross-reference
requests
that
that
token
makes
back
to
back
to
the
Token
itself
and
its
origin
in
the
audit
log,
and
then
the
second
half
is
actually
embedding
user
info
about
the
user.
That
requested
the
token
into
the
token
as
well
so
yeah
I've
added
a
couple
of
user
stories
for
it
as
well
as
kind
of
some
of
the
goals.
B
My
my
conquer,
my
big
specific
use
case
myself
is
user
Story
one
here
so
talking
about
being
able
to
cross-reference
requesting
a
token
in
a
service
account
token
presented
to
us
by
something
running
on.
C
B
It's
like,
alongside
the
cubelet
that
is
now
able
to.
We
are
able
to
then
cross-reference
that
token
to
see
that
it
was
issued
by
or
sorry
requested
by
the
particular
that
particular
cubelet
that
is
also
authenticating
to
us,
and
so
by
a
being
able
to
do
that,
cross-referencing,
we're
able
to
kind
of
anchor
trust
route
in
the
actual
nodes
identity
without
having
to
call
into
the
API
server
to
see
if
the
pawn
is
actually
meant
to
be
running
on
the
particular
host.
B
That's
connecting
to
this
external
service,
I've
tried
to
fill
out.
Yeah
I've
tried
to
fill
out
as
much
as
possible,
as
well
as
some
thoughts
on
different
types
of
tests
that
we
should
add
to
actually
make
sure
these
are
in
there.
It's
still,
certainly
a
draft
there's
a
few
empty,
empty
places
here,
I
if
anyone's
got
any
feedback
that
would
be
great
or
if
anyone's
got
any
other
similar
use
cases
too
I've
opened
yeah,
that's
kind
of
the
background
on
it.
B
I've
tried
to
jot
down
from
the
last
meeting
some
of
the
questions
that
came
up
and
concerns
so
that
we
can
kind
of
go
over
them
as
well
and
yeah.
That's
kind
of
what
it's
up
to
John
film.
Look
at
the
questions.
I've
got
to.
C
A
A
But
one
of
the
things
that
Jordan
had
explicitly
requested
was
that,
instead
of
not
in
addition
to
the
requester
user
info
that
we're
sort
of
discussing
here,
he
had
explicitly
requested
that,
just
as
we
have
a
first
class
like
pod
reference
that
we,
that
is
optional,
that
we
would
have
a
first
class
node
reference,
which
is
also
optional
but
I,
guess
I,
guess
it
depends
on
how,
if
it's
necessarily
tied
with
the
Pod,
when
or
not,
but
basically
I
think
his
feeling
was,
which
I
think
is
matches.
A
Reality
is
the
most
common
use
case
of
looking
at
the
Pod.
Ref
is
to
immediately
look
up
the
associated
node
and
then
do
validation
based
off
of
that,
and
while
we
can
get
that
same
information,
if
we
happen
to
have
the
requesting
user
information,
there's
no
reason
that
that
shouldn't
just
be
its
first
class
thing,
because
that's
literally
what
everybody
wants
to
do
with
it
like,
like
they're,
related
use
cases,
and
so
maybe
we
should
specifically
and
just
say,
here's
the
node,
here's
the
name,
here's
the
uid
and
it
looks
you.
A
C
B
B
If
that's,
if
that's
something,
that's
possible
that
solves
that
use
case
too,
and
if
that
also
then
means
that
we
don't
have
to
you
know
if
it
sidesteps
some
of
these
questions,
we
have
around
the
privacy
on
the,
including
your
username
of
requesting
user
I.
Think
that's
good
as
long
as
you
know
that
the
other
use
case
on
there,
you
know
the
the
jti
use
case
is
Satisfied
by
JTA,
which
I
think
it
is
and
I
think
it's.
A
Yeah
I
mean
so
I
think
at
least
my
feeling
was
that
these
will
all
be
things
sort
of
in
addition
to
themselves
so
I
don't
know
like
yes,
I
think
the
node
ref
solves
the
lookup
problem
like
I.
Think,
like
I,
think
this
statement
right
here
is
correct,
but
maybe
overly
strongly
worded
like
just
because
you
have
the
node
information
like
the
node
name
and
the
node
uid
doesn't
mean
that
you
might
not
need
to
make
further
checks
against
the
API
server,
so
it
doesn't
necessarily
inherently
mean
that's
offline.
A
It's
just
that
the
most
common
lookup
is
skipped
right
and
and
that
lookup
isn't
trivial
to
do
right.
You
do
basically
need
like
a
full
list
of
all
pods
on
the
cluster
to
then
cross
reference
to
full
nodes
right,
like
that's
kind
of
a
decent
amount
of
work
for
something
that
might
be
a
common
check,
especially
if
all
you
needed
was
the
node
name,
yeah
yeah,
so
I
think
those
are.
Those
are
good.
A
I
I
think
my
concern
about
just
saying
that
it
solves
all
of
the
problems
is
that
that
means
you
do
have
to
have
like
the
full
audit
stack
and
keep
the
data
for
significant
periods
of
time
and
like
unless
you
build
tooling,
you
would
manually
do
the
correlation
so
on
on
the
full
chain
thing
I
think
we
were
okay,
saying
that
it
would
never,
or
at
least
not
necessarily,
never
I,
think
we
were
okay,
saying
that
it
wouldn't
be
the
full
chain,
at
least
to
start
off,
with
we're
already
limiting
the
size
explosion
by
just
saying
groups
and
extra
just
aren't
there
you're,
just
not
even
gonna.
A
B
I
guess
yeah
I
think
so
the
thing
on
the
size
thing
I
currently,
if
I'm
wrong,
how
would
we
actually
be
able
to
assemble
because
I
think
one
of
the
proposals
was
that
we
only
have
the
initially
issuing
user
like
either
end
of
the
chain,
but
I
don't
quite
see
how
we
would
construct
that
without
persisting
all
of
these
things,
and
also
that
kind
yeah
that
almost
does
raise
more
privacy
concerns
because
it
kind
of
highlights
who
the
rootest
users
are
right.
If
you
do
have
that
chain
up
to
the
top.
A
Right
so
I
I
think
on
the
privacy
concerns
like
I,
do
think.
They're
valid
and
we'd
probably
have
to
come
up
with
some
story
there
I
don't
know
if
the
immediate
answer
would
be
that
we
just
don't
include
non-system
users
like
I,
suspect
what
we'll
end
up
having
to
do
depending
on
the
feedback
we
get.
When
we
sort
of
ask
people
around
is
probably
provide
an
option
to
the
API
server
admin
to
redact.
A
A
So,
like
you
know,
for
example,
there
could
be
a
flag
that
says
hey
if
you
have
a
system
colon,
a
non-system,
colon
username,
we'll
hash
it
before
we
put
it
in
here.
So
it's
still
clear
like.
If
you
have
the
full
list
of
users,
you
can
trivially
figure
out
which
user
it
was
in
a
basically
in
an
offline
way,
but
there's
nothing.
In
the
token
that
really
helps
someone
that
doesn't
know
the
full
list
of
users
already.
A
But
on
the
constructing
the
chain,
nothing
prevents
us
from
when
we
get
the
service
account
like
when,
in
the
authentication
there
right,
when
we
authenticate
a
service,
account
token
or
an
identity
right
like
we,
we
know
that
identity
right
and
when
we
look
at
a
particular
service
account
which
has
a
service
account
token,
which
has
existing
right.
Nothing
prevents
us
from
keeping
that
within,
like
the
request
context
and
then
reusing
it.
A
A
The
way
I
would
model,
it
is
probably
a
list,
and
just
you
know,
have
the
first
and
end
ones
be
there,
but
what
it
allows
us
to
do
in
the
future
is
if
we
decide
that
we
need
more
than
that
information
that
we
can
add
more
without
changing
the
schema,
because
it
was
always
just
a
list
like
the
the
other
thing
I
could
see.
Someone
saying
is
no
I
like
I.
Don't
understand
why
you
preemptively
truncated
this
list.
D
A
C
A
Identities
against
other
systems,
like
you,
are
in
a
place
of
privilege,
right,
like
you
can
you
can
be
like
yeah
like
I'm,
okay
with
these
sizes,
because
the
things
that
I'm
willing
to
let
you
integrate
with
are
over
there
and,
like
I'll,
make
sure
they're
within
some
bounds
right,
like
it's,
not
perfect,
right
like
if,
if
I'm
configuring,
my
AKs
cluster,
to
talk
with
AWS
I
control,
the
AKs
cluster,
but
I
have
no
influence
over
AWS
right
other
than
being
a
customer
and
being
like
hey.
D
Like
it,
but
if,
like
yeah
like,
if
the
limit
was
was
okay,
they
say
it
was
5K
or
four
I
think
it's
4K
like
if
you
bump
up.
If
you
start
bumping
up
against
that
you
as
the
as
the
cluster
maintainer,
are
you
gonna
give
your
customer
the
option
to
flip
this
flag
or
not
like?
Are
you
gonna
just
turn
it
on
and
break
stuff,
like
you
kind
of
don't
know
right.
A
Yeah
I
I
think
my
feeling
there
is
probably
we
would
end
up
defaulting
to
the
you
get
the
first
and
the
last,
so
it's
most
likely
to
work
and
then
it's
up
to
a
cloud
provider
if
they
want
to
let
their
customers
tweak
it
further
than
that,
because
if
they
want
to
have
that
information
and
same
with
the
redaction
stuff
right,
I
think
all
of
these
are
API
server,
knobs
right,
so
it
foundationally
comes
down
to
the
cloud
provider.
A
E
C
So
I
don't
think
we
can
redact
them
just
by
hashing
them
right.
That's
not
a
it's,
not
very
robust.
A
F
A
I
mean
I
I
think
it's
sort
of
like
a
bug
today,
right
that,
like
you,
you
don't
have
this
information
right
like
if
you
look
at
our
audit
logs
today
right,
they
very
explicitly
contain
contain
first
class
impersonation
information
because
you
don't
want
to
lose
that,
but
this
can
give
you
a
mechanism
where
you
can
grant
all
of
your
own
privilege
to
a
service
account
and
then
use
it
to
do
stuff
on
your
behalf,
and
you
leave
no
trace
of
yourself
anywhere
all
right,
yeah.
A
It's
that's
that's
kind
of
broken,
so
I
I
I'm,
not
saying
that
like
a
customer
is
asking
for
this.
But
these
are
not
the
type
of
things
I
ask
expect.
Customers
to
ask
for
I
do
think
customers
might
be
like
well.
Why
doesn't
it
like?
Why
does
it
work
like
that?
Doesn't
seem
sound.
C
What's
the
path
here
that,
like
you
know,
Ahmed
TD
would
end
up
in
this
list.
Inside
the
token.
A
It
would
be
you
made
a
like
you
used,
Cube
CTL,
create
token
as
you're
like
you
were
logged
in
as
yourself,
you
did
Cube
CTL
create
token.
You
got
that
token
and
you
started
using
that
token.
So
today,
once
you've
started
using
that
token
you're,
basically
Anonymous,
you
were
that
service
account,
but
your
identity
is
kind
of
wiped
from
the
system.
A
Unless
you
very
carefully
go
look
at
audit
logs
and
if
that
service
count
is
shared
by
you
and
someone
else
at
best,
the
audit
logs
tell
you
that
one
of
you
guys
did
it,
but
now
who
so,
for
example,
if
you
and
to
another
person
are
cluster
admin
on
an
environment,
we
don't
know
which
one
of
you
did
that
after
a
certain
point,
once
the
audit
logs
roll
over.
A
Remember,
though,
if
it's
being
carried
within
the
payload,
even
if
your
audit
logs
roll
over
your
use
of
that
token,
contains
that
information
still
enough
of
it
to
give
a
sense
right,
but
but
to
your
question,
you
do
Cube
CTL,
create
token
you
get
a
token
and
then,
when
you
try
to
use
it,
it
will
obviously
be
that
service
account.
A
But
within
that
token
it
will
be
a
record
that
you
are
the
one
that
provisioned
it
like
for,
for
example,
like
I'll,
give
you
like,
in
the
case
of
like
the
whole
privacy
thing
right.
This
has
exactly
zero
privacy
concerns
and
AKs,
because
AKs
uses
the
uids
for
everything,
usernames
or
uids
groups
are
uids
and
obviously
UI
user
IDs
right.
So
there's
literally
nothing,
that's
private!
It's
just
a
bunch
of
goblet
group
anyway,
so
like
for
us,
it
would
be
totally
safe.
We
already
do
all
the
mapping
lookups.
A
Right
yeah,
so
the
jti
stuff
would
be
purely
specific
to
service
account
tokens
if
you're,
if
you're
authenticating
a
different
type
of
token,
that
has
a
jti.
It's
purely
up
to
your
authentication
stack
to
contain
that
information
and
future
things.
C
A
A
So
obviously,
in
the
traditional
like
workload,
identity
flow
of
I
have
a
cubelet.
It's
got
a
bound
service,
counter
volume,
Mount
and
everything.
None
of
this
shows
up
because
it's
just
cute
little.
It's
all
system
identity.
So
it's
like
oh
okay,
I
see
right.
So
in
those
cases
it's
totally
100
safe
and
we
already
have
no
chain
of
who
made
the
Pod
like
this
just
game
over
like
whoever
deployed
the
Pod
or
the
deployment
that
caused
all
this
to
happen.
That
is,
nobody
knows
really,
unless
you
very
carefully
piece
it
together.
B
The
one
so
it
makes
sense
to
me
it's
just
clicked
all
together
as
well,
a
bit
more.
What
you're
saying
they're
about
having
the
initial
requesting
you
like
either
end
of
the
chain,
because
at
the
top
of
the
chain
is
always
going
to
be
some
non-service
account
entity,
so
you're
going
to
actually
yeah
you're
you're
going
to
be
able
to
yeah
yeah
well.
B
That
helps
you,
because
someone
can't
request
one
to
request
one
to
request
one
to
request
one,
but
you
just
also
I've
just
thought
about
one
other
thing
we
need
to
consider
is
impersonation
there,
because,
if
I
as
a
user,
because
it's
really
nice
that
property-
like
you,
say
that
this
lasts
longer
than
the
audit
log,
but
if
I
can
impersonate
a
user
who
can
then
create
a
token,
we
do
actually
lose
the
impersonation
like
unless
we
are
also
going
to
embed.
B
A
Because
yeah
we
do
because
edit
level
access
and
the
namespace
lets
you
impersonate
any
service
account
in
that
namespace,
so
it'd
be
very
trivial.
Oh
you
just
impersonate
that
and
then
go
on
yeah
it'd
be
very
trivial
to
redact
yourself
out
of
the
log,
so
I
think
we
have
to
solve
that
somehow,
which
is
unfortunate.
B
B
B
If
you
actually
include
the
impersonating,
like
that
top
level,
impersonating
user
as
the
first
entry
in
that
list
right,
because
then
the
second
entry
who
you're
impersonating
gets
thrown
away
and
then
that
the
rest
of
the
chamber,
ultimately
the
very
first
one
is,
unless
you
impersonate
and
impersonate
to
impersonate.
Is
that
what
you're
saying
you.
B
So
if
you
always
include
the
actual
user,
making
the
impersonation
requests
on
that,
like
I,
think
the
very
first
request,
I'm
impersonating
someone
and
creating
a
bound
token
that
context
is
available
to
us
at
the
point.
We
issue
that
token
right
who
the
top
level
you
the
first
real
user,
is
if
we
actually
put
that
as
the
it.
Basically,
it
kind
of
changes
the
rules
of
what
we
put
in
there,
because,
instead
of
putting
the
actual
requesting
user
we're
putting
the
requesting
user
or
whoever
is
impersonating
them
that
information.
So
it's.
B
A
B
Sense
like
to
go
back
to
the
question,
I
think
that
a
while
back
like
are
there
use
cases
that
the
node
thing
doesn't
solve,
like
I,
think
they're
obvious.
Yes,
there
are,
which
is
like
what
we're
talking
about
here,
for
what
originally
set
me
down
this
path,
the
node,
a
node-based
like
a
node
field
in
there
solves
solves
kind
of
like
my
initial
user
Story
one
but
I
think
you're
right
in
saying
that
there's
there
is
definitely
something
to
be
desired.
B
For,
like
it's
highlighted
to
me,
how
easy
it
is
to
actually
hide
your
tracks
in
the
audit
logs
today,
as
it
is
just
through
bound
service
camps.
B
B
D
B
Think
I
wonder
if
how
do
we
retain
this
like
actual
end-to-end
capability
to
check
through
this?
Maybe
that's
like
a
maybe
that
is
actually
a
separate
thing,
because
right
now,
as
it
is
like
you
need
to
maintain
your
audit
log
in
order
to
see
I
think
we're
in
a
net
better
position
without
adding
any
features
that
we
don't
want.
I
think
there's!
Oh!
Unless
we
can
come
up
with
a
solution
to
this
kind
of
like
end
of
the.
B
B
Yeah
I'm
wondering
if
maybe
we
should
do
the
jti
and
then
a
node
entry,
and
then
we
should
actually
possibly
even
filter
more
like
feedback
on
like
who,
like
are
the
current
things
sufficient,
and
what
do
we
want
to
provide
with
kind
of
that
end
to
end
I?
Think
because,
there's
an
argument
to
be
said,
you
know
it's
actually
useful
to
include
that
impersonating
user
along
the
way
as
well
and
stuff
like
that.
A
Yeah
also
one
one
thing
that
wasn't
100
clear
on
the
Node
ref
part
was:
if
the
expectation
would
be
that
the
node
ref
is
pulled
from
like
the
I
guess,
the
node
ref
can't
be
the
the
gist.
Was
that
because
we
would
expect
it
to
include
uid,
is
that
you
would
use
the
API
servers
like
node,
Informer,
yeah,
actually
fetches.
So
that's
not
wired
up
today,
but
it
wouldn't
be
hard
to
wire
it
through.
B
B
I
did
notice
that
that
wasn't
in
there,
so
that's
at
the
time
made
implementing
requesting
user
far
simpler,
but
it
does.
Actually.
You
were
right
in
saying
that
we
then
have
to
do
some
kind
of
a
mapping
from
requesting
username
back
to
no
like
no
any
simple
like
we
can
do
that
by
stripping
bits
off,
but
there
is
still
some
mapping
going
on.
So
it
is
quite
neat
to
have.
A
A
My
gut
says
that
maybe
it's
just
okay
to
limit
this
to
a
first
class
node
ref
and
a
I
guess
jti
is
already
first
class
in
jots,
but
like
just
include
that
in
there
and
just
maybe
scope
the
cap
like
yes,
it
would
be
a
non-goal,
but
it
might
make
more
sense
to
State
it
as
like,
deferred
goals
and
basically
just
say,
whoa.
We
couldn't
figure
out
how
to
make
impersonation
and
everything
else
work
with
a
chain.
Well,.
B
Yeah
and
I
mean
I
think
today
actually
having
jti
brings
some.
You
know
significant
improvements
for
people
like,
especially
if
you
are
aware,
like
you
could
actually
say.
Well,
you
know
what
token
token
request
audit
logs
we're
going
to
retain
for
even
longer,
specifically,
so
that
we
can
do
this
cross-referencing
back.
B
That
does
provide
meaningful
benefits
on
that
front
too
right
and
it's
a
very
small
change,
and
it
is
a
small
like
this
proposal
is
quite
simple.
If
you
replace
the
node
bit
with
that
bit
and
to.
A
Yeah,
so
if
I
go
back
to
my
PR,
if
I
can
remember
so,
let's
see
so,
we
would
have
jti
like
just
like
this.
We
would
not
have
this
part.
Instead,
we
would
have
a
new
thing
that
looks
exactly
like
this,
which
would
be
like
node
yeah,
and
it
would
be
like
every
name
and
you
would
just
a
name
and
you
would.
C
A
Node
and
then.
A
My
feeling
is,
it
would
stay
exactly
like
this.
The
the
reason
we
include
this
is
because
these
are
immutable,
their
permanent
aspects
and
fully
generic
aspects.
So
I
think
that
is
a
a
much
longer
ask
if
you
want
to
start,
including
other
parts
of
the
metadata
and
I
would
just
prefer
to
not
try
that
conversation
right
now
and
I
guess
if
you
really
need
that
information
I
feel
like
having
a
node
Informer
is
much
less
work
than
having
all
your
pods
with
backed
references
to
nodes.
It's
like
at
least
half
the
work.
A
A
We
can
ignore
this
question
by
saying:
maybe
we
just
don't
include
requesters
today.
We
can
also
ignore
this
question
by
saying
we
don't
include
requester
same
here
and
then
in
the
previous
discussion
about.
A
A
Yeah
so
I
don't
know
where
Mike
is
and
then
Jordan
is
at
the
doctor.
So
it's
just
you
so
I
guess:
I'd
fill
you
in
I
meant
to
cap
this
conversation,
but
we
couldn't
really
have
any
of
the
other
conversations
without
somebody.
C
A
Than
like
me
on
the
call,
so
we
were
talking
about
the
enhancements
to
bound
service
account
tokens
and
all
the
stuff
and
The
Proposal
that
James
was
making,
which
I
generally
felt
like
was
kind
of.
A
Okay
was
what,
if
we,
what
if
we
limit
the
changes
for
now
to
include
the
jti
stuff
that
shows
up
in
audit
logs
and
user
info
and
to
add
a
first
class
node
reference,
which
also
shows
up
in
audit
logs
and
user
info,
and
just
stop
there
for
right
now
and
basically,
we
will
prevent
the
concerns
around
token
size,
token,
privacy
and
we
weren't
sure
how
to
make
the
chain
work
exactly
correctly
with
impersonation
in
the
mix
like
if
you
impersonate
a
service
account
to
make
another
token.
A
So
so,
basically,
today
this
is
the
struct.
We
have
minus
line
57
that
exists
and
we
would
basically
add.
E
A
And
we
would
I
guess,
use
the
node
Informer
on
the
API
server
side
when
we
see
the
node
user
to
go
ahead
and
like
if
we
see
the
username
is
the
node
we'll
go,
look
it
up
and
put
it
in
there.
A
A
So
the
the
reason
for
doing
it
that
way
was
that
we
would
not
include
this
at
all.
For
now,
we.
E
E
A
E
F
E
A
Yeah
I,
I,
yeah,
I
I
think.
The
reason
we
include
uids
in
these
things
is
because
when
you
delete
and
recreate
the
same
name,
it's
not
the
same
thing
anymore,
at
least
as
far
as
auth
is
concerned,
and
so
I
would
expect.
The
deletion
of
a
node
object
to
invalidate
all
the
tokens
that
were
issued
for.
C
B
So
that
sounds
good.
The
one
thing
that
I
like
I,
really
it
sounds
like
a
very
clean
design,
but
if
I've
got
a
set
pods
running
on
a
node
and
I
delete
the
node
object
and
then
restart
the
cubelet
cubelet
talks
to
the
CRI,
it's
going
to
go
and
recreate
node
object,
What
hap!
Does
it
resync
and
my
workloads
keep
running
because
we're
now
changing
the
behavior
there
right,
like
that's
all
of
a
sudden.
A
token
that
was
valid
is
no
longer
valid.
Like
what
happens
today.
B
A
B
E
F
A
B
A
F
A
Yeah
I
mean
I,
guess
one
way
to
make
it
less
breaking
is
like
when
the
cubelet
starts
up
and
it's
going
to
adapt
these
pre-running
pods
or
whatever
the
term
is
because
I
know
almost
nothing
about
the
cubic
code.
It
has
to
figure
out
by
looking
at
the
volume
mounts
like
when
it's
supposed
to
refresh
stuff
right
like
supposed
to
know
that
right
so.
C
F
B
B
It
because
it
reduces
that
window.
Oh,
it
makes
it
automatic
itself,
heals.
E
E
I
would
go
ahead
and
enumerate
that
in
the
notes,
so
that
we
can
make
a
note
when,
when
we
review
it
to
decide,
do
we
actually
want
that
or.
E
D
E
D
E
E
F
F
Even
if
it's
like
not
really
the
best
way
to
do
something
and
we'll
we
will
get
tickets
for
that
when
we
break
it
sometimes
it
it's
usually
not
catastrophically
disruptive,
but
sometimes
it
is,
and
we
I've
seen
enough
of
them
to
worry
about
breaking
something
like
that.
F
A
network
yeah
it
it
would
be
a
weird
workflow
like
no
doubt
right,
I
mean
usually
the
reason
a
node
gets
deleted
is
because
the
vm's
been
deleted
and
it
hasn't
heartbeated
or
it's
just
so
unhealthy
that
it
needs
to
be
repaired
and
node
controller.
Does
the
right
thing
and
goes
and
deletes
the
node
and
that's
the
only
reason.
I
know
it
gets
deleted,
but
it
I
don't
think
we
can
rule
out
human
or
scripted
workflows
that
might
be
messing
with
it.
B
Yeah
I
will
certainly
ask
some
of
our
sres
internally
exactly
this
question,
so
hopefully
we
can
help,
but.
B
C
A
I
I
guess
one
reason
the
node
might
not
exist
is
if
you're
like
this
node
is
compromised,
I'm
going
to
delete
it
now
and,
like
start.
B
A
But
again,
though,
if
you're
doing
offline
validation
of
any
kubernetes
service
account
token
artifact,
oh,
it's
expired
the
level
of
verification
that
you
care
about
because
we
can
be
controlled.
If
you
do
token
review
or
not,
certainly
we
can
recommend
it
because
it's
guaranteed
to
keep
up
with
our
latest
guidelines.
But
today
the
most
common
thing
I
see
people
do
is
like
there's
the
signature
validate
cool
is
the
subject.
Vaguely
look
like
the
subject:
I
expected
cool,
that's
good
enough!
Here's!
Here's
your
bad
identity,
they're,
not
they're,
not
checking
the
bar
they're,
not.
B
B
B
E
All
right
so
I
think
it's
going
to
be
a
behavior
question
Mo.
If
the
desire
is
to
actually
expire
these
when
the
node
gets
deleted,
which
I
could
see
is
reasonable,
then
adding
the
node
field
makes
a
lot
of
sense
if
the,
if
that
doesn't
actually
do
what
we
need
it
to
do,
then,
having
a
user
that
we
restrict
to.
We
only
fill
this
information
in
when
we
have
when
it
is
a
qubit,
because
we
can
recognize
what
those
look
like
that
that
could
be
narrow
enough
for
people
to
be
comfortable.
E
Doing
saying
that
there's.
E
I,
don't
think
I
like
that.
I
I
think
that,
on
the
call
everyone
here
looked
and
said
it's
in
there,
I
would
expect
it
to
be
validated.
A
Yeah
I
guess
that's
fair
if
there
is
a
first
class
field
with
a
kubernetes
specific
meaning
like
service
account
and
secret
and
pod,
those
do
get
validated
with
every
10
seconds.
Basically,
because
that's
the
token
cash
yeah,
so
okay
I
can
see
where
you're
coming
from
so
either
either.
We
include
it
as
a
first
class
thing
and
we
validate
it
in
the
same
way
that
we
validate
other
existing
references
that
are
first
class
or
we
include
it
as
like
this
opaque,
requester
and.
A
Yep,
okay,
cool
I,
don't
think
we
have
much
time
to
discuss
anything
else,
I
guess!
James!
Do
you
have
anything
else?
You
want
to
ask
about
this.
B
No,
that
sounds
good
like
go
ahead
and
update
the
cap
with
talking
about
adding
a
node
field
and
then
in
Alternatives
considered
maybe
talk
about
some
of
the
requester
info
stuff
and
say
that
this
is
something
we
want
to
explore
as
a
separate
set
of
goals.
In
order
to
make
sure
we
can
do
that
securely
and
then
possibly
touch
on
this
token
review
stuff.
B
So
we
can
discuss
how
we
want
to
enable
that
how
we
I
don't
know
if
we
can
do
that
tomorrow
or
what
yeah
sorry
by
tomorrow,
I
mean
the
next
release.
All
in
one
go
well
whether
we
need
to
actually
have
like
a
gradual
tightening
of
that
Behavior,
which
maybe
Jordan
will
have
some
more
input
on
too.
B
So
yeah
cool,
no
more
questions.
Thank
you
for
this
15
minutes
that
you
promised
me
at
the
start
of
the
meeting.
Yeah.
A
All
right
well
I
mean
nobody
was
here,
but
so
I
was
like.
We
can't
really
talk
about
this.
The
split
David
you
weren't
here
for
the
last
conversation
around
the
split
right.
A
A
Okay,
cool
the
the
gist
for
I.
Think
some
of
the
folks
on
the
call
were
on
that
last
discussion
is,
we
were
trying
to
add
offline
support
to
secret
CSI
after
discussing
it
with
the
folks
that
wanted
that
and
all
of
those
things,
we
basically
came
to
the
conclusion
that
those
people
just
want
kubernetes
secrets
anyway.
A
A
A
Okay,
cool
I
think
we'll
bring
this
up
next
time
to
discuss
in
a
bit
more
detail
because
there's
a
relatively
long
design,
dock
yeah
I'll
just
move.
Basically
everything
up
to
the
next
next
meeting's
agenda,
all
right
cool!
Thank
you.
Everyone
for
joining
and
we'll
see
you
in
two
weeks.