►
From YouTube: SIG-Auth Bi-Weekly Meeting for 20220928
Description
SIG-Auth Bi-Weekly Meeting for 20220928
A
B
B
A
B
B
B
So
the
goal
is
to
limit
this
somehow
to
specific
Fields,
and
so
the
I've
declared
it
a
non-goal
for
these
purposes.
Also,
reading
limiting
What
fields
can
be
read
so
because
I
think
that
makes
it
a
lot
harder.
If
that
is
too
much
of
a
non-goal,
we
can
talk
about
expanding
the
scope
of
this,
but
I'd
like
to
keep
it
as
targeted
as
possible
yeah.
So
today,
I'll
just
go
through
the
designs,
real
quick
today.
B
The
only
solution
that
we
have
really
is
to
use
sub
resources
to
make
a
sub
resource,
and
so
this
is
this
is
what
we've
asked.
This
is
what
David
is
asking
the
this
cap
author
to
do
is
make
a
sub
resources
for
this
proposed
liens
field
and
also
one
for
the
final
edges
field,
because
they
should
really
be
similar,
but
in
Reading
in
reading
that
kept
for
proposing
adding
a
sub
resources
for
sub
resource
for
finalizers.
B
I
realized
that
this
makes
life
very
inconvenient
for
clients,
because
every
sub
resource
implies
a
whole
new
set
of
functions
in
the
client,
like
not
just
an
additional
thing,
but
all
new
set
of
functions
like
you
can't
set
this
the
scale
subresource
without
calling
the
special
like
scale
functions,
and
you
can't
update
the
status
resource
without
calling
the
like
this
apply
status,
Etc.
So
if
we
make
three
or
four
or
five
new
sub
resources,
that
implies
like
a
bunch
of
functions
like
it's.
B
Like
that's
several
verbs
at
times
all
the
all
the
client
objects,
all
the
client,
all
the
clients
that
we
generate.
It's
a
lot
of
functions
and
it's
going
to
be
confusing
to
users
which
ones
they
need
to.
They
need
to
call
additionally,
when
you're
writing
your
controller.
You
have
to
write
it
in
such
a
way
that
it
uses
a
sub
resource
right
like
an
existing
client,
would
be
able
to
set
labels
through
the
labels
like
through
the
regular
object,
just
updating,
spec
or
whatever.
B
But
if
you
want
your
controller
to
be
able
to
be
controlled
in
this
way,
this
this
permissions
model,
you
have
to
make
it
use
this
separate
sub
resource
you
also
have
to
you
also
have
to
like.
If
you
want
to
update
multiple
Fields,
this
controller
has
to
make
multiple
calls.
You
can't
combine
that
right.
So
I
think
this
is
actually
super
inconvenient
and
I
hope
that
we
can
do
better
any
questions
so
far.
D
A
B
B
D
D
Okay,
so
you
talked
about
the
case
where
we
we
have
a
controller.
We
want
to
let
like
right,
you
know
finalizers
or
liens
or
conditions
or
some
specific
field,
and
we
don't
want
to
Grant
Broad
access,
or
you
know
some
a
couple
of
fields
and
we
don't
want
to
make
them
jump
through
hoops
to
call
like
n
different
sub
resources.
D
So
that
makes
sense
to
me
the
other
direction
is
sort
of
what
I
was
also
trying
to
understand,
which
is
we
have
a
field
like
liens,
actually,
where
users
have
broad
update
rights
today,
and
we
don't
want
update
to
automatically
give
them
the
right
to
do
lean.
Stuff
like
liens
are
like
have
implications
for
the
system,
and
so
we
we
want
to,
in
addition
to
update
you,
need
to
specifically
have
update
on
Lanes.
H
A
B
Problem
so
I
I
think
okay,
I've
I
have
like
two
answers
for
this.
One
is
like
this
is
a
mission
control
problem
is
here's?
Here's
a
here's,
a
lot
of
instructions.
Please
go
write
an
admission
controller
like
that
is
not
a
low
bar
to
entry
at
all.
Not
everybody
is
capable
of
doing
that
easily
or
within
a
small
time
constraint,
and
this
is
a
common
desire.
Right
like
like
this
is
solvable
with
admission.
Control
is
something
you
could
maybe
tell
a
cloud
provider.
B
My
second
answer
is
that
I
I
don't
know
if
anyone
else
makes
it
makes
this
distinction,
but
I
make
the
distinction
between
like
policy
and
authorization
and
I.
Think
like
permissions
and
policy
are
separate
things
and
I
think
ability
to
change
a
specific
field
is
pretty
tightly
scoped
and
it's
reasonable
to
have
that
covered
in
the
permissions
model,
not
necessarily
the
the
like
the
policy
layer,
I,
don't
know
if
anyone
else
thinks
of
those
things
as
different
layers,
but
I
do.
E
B
H
So
I
just
wanted
to
to
say
like
while
this
is
not
at
all
my
home
Sig.
They
I
took
interest
in
this
cap
because
I
do
a
lot
of
their
API
reviews
and
so
I'm.
Looking
at
this
from
the
API
review
perspective,
where
you
know
we're
trying
really
hard
to
give
people
good
advice
on
how
to
do
things
safely
and
securely
in
the
bad
old
days
that
was
do
whatever
you
want
and
now
we're
trying
to
be
more
like
secure
by
default
and
and
minimum
access
and
least
privilege
by
default.
H
H
I
do
think
that
as
our
life
cycle,
management
and
referential
integrity
options
get
more
sophisticated,
more
people
will
want
to
use
them,
and
that
will
mean
in
today's
model
granting
a
lot
of
spec
access
to
a
lot
of
actors
who
don't
really
need
spec
access.
They
just
need
the
ability
to
hook
life
cycle
events,
and
so
that's
why
I
think
this
is
going
to
just
grow
in
importance
in
how
we
solve
this
I
I.
Read
that
you
know,
I
read
the
doc
and
my
comments
are
there?
H
B
A
B
F
Yeah
so
I
guess
to
attempts
Tim
all
clear's
point,
but
I
guess
this:
we
weren't
he
wasn't
recommending
multiple
sub
resources.
I
think
he
was
recommending
writing
an
admission
control
for,
like
lean
specifically
and
I.
Think
that
makes
sense
for
anything
in
in
core.
That's
that's
what
we
do
for
signer
name,
that's
what
we
do
for
we
we
did
for
PSP.
F
B
F
B
Yeah:
okay,
why
don't
I
continue
and
since
I
think
this
is
relevant?
I'll
go
into
the
next
design.
I
was
going
to
skip
it,
but
the
design
two
option
is
basically
like
how
could
I
solve
this
without
changing
anything
in
tree,
and
it's
listed
a
design
how
you
could
solve
it
like
some
objects
that
are
analogous
to
crds
like
this
is
a
field
field,
selection,
expression
and
like
a
something
that
binds
into
users
or
groups
Etc.
B
So
the
the
reason
why
the
more
or
less
the
reason
why
this
design?
Okay,
there's
a
few
reasons.
Reliability
is
bad
with
web
Hooks
and
this
Mrs
David's
constraint
of
it's
on
everywhere,
because
this
can
be
turned
off
and
David's
David
and
mo
mentioned
this.
Also.
The
constraint
that
it
is
on
everywhere
lets
people
plan
for
it
and,
like
developers
like,
if
it's
on
everywhere,
it's
like
oh
yeah.
This
is
something
I
do
in
my
development
cluster.
B
C
That's
a
that's
a
good
expression.
I
would
I
would
like
to
see
the
check
that
is
made
be
something
that
is
in
conformance
over
time.
This
is
the
way
our
API
behaves
and
the
actual
permissions
themselves
could
be
granted.
You
know
someone
could
say:
oh
I,
don't
care
about
this
I'm
going
to
Grant
everyone
permission
yeah,
but
the
checks
are
always
made.
B
B
So
it
you
can
well,
you
have
to
do
something
that
passes
to
Performance,
but
you
can
turn
off
admission,
plugins
and
just
use
the
the
right
you
can.
You
can
turn
off
various
parts
of
the
of
the
chain.
If
you
turn
off
everything,
you
probably
won't
pass
conformance.
If
you,
if
you
turn
off
parts
of
it,
you
probably
can.
B
So,
like
people
configure
their
their
permissions
in
different
ways,
right,
like
you,
can
use
our
back,
but
you
don't
have
to
use
rbac.
You
can
get
the
you
can
pass
the
you
can
let
the
permissions
checks
gets
passed
on
to
to
a
plug-in
that
is
a
Web
book
and
calls
out
to
some
other
authorization
system
right,
yeah.
A
D
You
can
use
them
both
together.
The
two
examples
that
we
referenced,
like
the
CSR
signer
thing
and
the
garbage
collector
reinforcement
both
of
those
are
in
tree
admission,
plugins,
which
do
authorization
checks.
So
like
the
fact
that
an
authorization
check
is
done,
that's
codified
in
the
admission
plugin.
It
is
calling
out
to
the
authorization
subsystem,
so
you
can
satisfy
that
authorization
check
with
our
back
or
whatever
Authority.
You
have
hooked
up
so
so.
B
F
C
D
The
one
problem
that
like
just
implementing
a
new
admission
plugin
would
have
is
that
it
doesn't
satisfy
the
case
where
we
want
a
controller
to
be
limited
to
only
updating
a
few
fields,
and
we
don't
want
to
give
it
broad
update
permission
otherwise,
because
in
order
for
it
to
even
reach
that
admission
plugin,
you
would
have
to
do
that
controller.
Like
total
update
permission
and
then.
A
A
B
Yeah,
okay
shall
I
outline
the
the
like
what
is
recommended
which
is
designed
for
here
so
so,
basically
we're
going
to
do
a
couple
like
those
the
straw
proposal,
like.
Obviously,
this
needs
to
be
written
up
more,
but
the
the
Like
Straw
proposal
is
to
add
a
like
virtual
permission.
Verb
I
understand.
We
do
that
and
like
you
can
grant
the
permission
via
rbac
or
via,
like
some
external
system.
However,
you,
however,
the
system
administrator
is
in
the
habit
of
granting
remissions.
B
You
can
grant
that's
this
permission.
That
way
so
it'll
be
a
basically
a
it's,
not
an
edit
permission,
but
it
is
an
indication
like
if
you
have
this
permission,
it's
an
indication
that
we're
going
to
do
the
secondary
auth
checks
later
in
the
chain.
Once
we
know
what
is
changing,
so
you
tell
like,
like
the
the
flow
it
looks
like.
Okay,
you
does
this
person
have
edit
or
update
permission?
No.
Does
it
have
the
per
field
edit
permission?
Yes,
okay.
B
At
that
point,
we
proceed
down
the
request
chain
like
we
put
something
in
the
context
or
something
to
tell
us
to
tell
us
that
we
need
to
do
these
secondary
checks
and
when
we're
going
to
write
to
storage
at
the
point
where
we
have
both
the
Old
and
the
new
object.
It
is
at
that
point
pretty
easy
to
diff
the
two
and
figure
out
what
fields
are
changing.
B
We
can
use
some
of
the
some
of
the
code
written
for
server-side
apply
to
Express
this,
so
we
don't
have
to
write
a
bunch
of
structured
set
manipulation
right.
We
can
just
reuse
that
of
that
code,
so
I
wouldn't
look
to
like
this
is.
This
is
modifiable
like
how
exactly
we
want
to
express
which
field
somebody
is
able
to
have
right
here.
B
I
have
like,
like
you,
you
construct
a
verb
based
on
the
like
the
type
name
and
the
field
that
they
want
to
modify
and
do
a
regular
permissions
check
based
on
that
constructed
name,
and
you
do
this
for
every
modified
field.
There's
like
we
could
do
more
complicated
things
where
there's
intermediate
objects,
and
it
like
gives
you
a
set
of
fields
and
I.
Don't
think
that's
important
to
settle
right
now.
Okay,
we
could
even
have.
B
We
could
even
have
a
negative
permission
if
so
desired.
David
thinks
it's
a
bad
idea,
but
if
so
desired
we
could.
We
could
have
a
like.
You
could
only
modify
this.
You
can
only
find
modify
spec
if
you
don't
have
the
no
spec
permission,
of
course,
that
that
depends
on
other
things
in
the
authorizer
chain,
not
letting
you
do
it
anyway,
but
you
only
get
into
this
into
this
condition.
If
that's
the
case
anyway,
right,
okay,
yeah,
maybe
I,
should
stop
there.
B
The
properties
are
like,
obviously
it
it
works
with
your
existing
permissions
granting
system
whatever
that
might
be.
It
works
on
existing
resource
types
like
like
all
resource
types.
You
don't
have
to
do
something
special
for
crds
and
this
code
is
basically
all
API
server
codes.
We
don't
have
to
change
admission
plugins
or
anything
like
that.
H
B
H
A
B
E
So
I
think
this
is
related
to
the
thing
Jordan
had
said
earlier,
but
it's
sort
of
a
specific
sort
of
nuance
of
it,
which
is
I'll,
speak
by
example.
With
with
pot
security
admission,
we
were
really
careful
to
say
that
the
policies
were
versioned.
So
that
way,
if
you
needed
the
latest
meaning
you
could
ask
for
it.
But
if
you
built
your
stuff
around
a
particular
version
of
the
prospect,
that's
that's
where
you
can
sort
of
Point
things
at
the
the
thing
that
I
don't
know.
B
To
use
this
problem
to
use
this
mechanism
to
solve
the
problem
Jordan
asked
about,
you
would
have
to
not
Grant
users
update
and
then
grant
them
this
per
field
thing
and
Grantham
a
the
the
like
ver,
the
special
verbs.
That
means
the
field
they
want
to
to
change.
Now
you
as
as
written
it
is
a
recursive
check.
So
it
starts
at
the
root
of
the
object
goes
down.
So
if
you
have
permission
to
to
modify
spec
like,
and
we
check
that
first,
like
it's
only
a
couple:
extra
checks.
E
So
I
I
think
I
think
you
still
need
something
some
way
to
express
that
this
field
is
special
and
you
need
a
special
check,
no
matter
what,
for
this
field,
like
I,
think
I
think
it's
compatible
with
somewhere
in
this
design.
I'm
just
saying
that,
like
like
you
know,
if
I
add
some
new
lean
field
or
whatever
some
new
privileged
field.
Okay,.
E
B
I
mean
for
for
so
I
I
think,
that's
a
policy
question
and
not
a
like
per
field.
Authorization
question,
like
you
have
permissions
to
set
the
admin
pod
flag
or
whatever
it
is.
You
can
just
only
set
it
to
false,
like
I,
wouldn't
use
this
mechanism
to
enforce
that
you
can
get
the
you
could
always
get
the
default
value
because
you
can't
say
anything
about
the
field
at
all
like
like,
okay,
I
guess,
I
could
work,
but
why?
B
B
D
A
D
The
difficulty
of
the
the
like
can
you
modify
this
field
at
all,
is
when
we
are
talking
about
adding
a
field
to
objects
that
gives
them
sort
of
power
on
other
objects
or
on
the
system
that
they
didn't
previously
have
so
like.
The
liens
field
is
a
good
example
right
like
previously,
if
I
could
set
pods
like
I,
you
know
maybe
positive
example,
because.
D
Someone
has
to
decide
that
they
want
to
disallow
that
for
users
who
otherwise
could
just
create
and
update
these
things.
That
kind
of
goes
back
to
the.
If
it's
not
there,
by
default,
people
aren't
going
to
realize
they
need
it
and
then
someone's
going
to
do
something
clever
or
disruptive,
and
then
cluster
evidence
are
going
to
come
to
us
and
say
like.
Why
didn't
you
protect
me
from
this
like,
oh
well,
you
could
have
put
a
policy
in
place
that
you
didn't
know
you
needed
to
I.
D
D
A
B
B
But
then
I
think
that
also
is
incompatible
with
this
notion
that,
like
we're
going
to
introduce
new
fields-
and
you
have
to
have
a
special
thing
to
get
this
new
field
set
like
like
I-
don't
think
if
we
were
starting
from
scratch
today,
would
we
would
we
would
we
do
it?
That
way,
would
we
split
the
permission
Space
by
verb
and
field
like
like
you
have
create
on
spec,
okay,
great,
you
create
not
on
spec,
but
on
spec
dot
replicas?
What
does
that
even
mean
I'm,
not
sure?
B
Are
you
an
update
on
like
spec.reficas
but
create
an
all
of
spec
foreign
that
comes
out
to
be
like
you
get
very
fine
grain
control,
but
would
you
want
to
be
the
system
administrator
who
has
to
figure
out
who
should
get
which
of
our
thousands
of
potential
special
permissions?
Like
that
does
not
sound
too
easy
to
me.
B
I
I
realize
I'm
I'm,
also
adding
like
the
the
permissions
in
this
model
are
all
constructed
and
so
we're
adding
basically
a
combinatorial
large
number
of
them,
but
at
least
it
would
only
be
for
users
who
have
the
special
like.
Please
go
check
this
tree
of
combinatorially
large
permissions,
yeah
I,
don't.
A
C
D
I
am
more
focused
on
the
first
one
you
mentioned
where,
and
maybe
this
is
being
burned
from
finalizers
like
where
any
user
with
update
can
add
or
remove
any
finalizer
they
want,
and
so
finalizers
are
actually
unsuitable
for,
like
actually
ensuring
we
protect
things.
You
know
if
we
have
an
external
system
and
we
need
to
clean
up
a
reference,
International
System.
We
can
put
a
finalizer
on
there
with
a
controller,
but
any
user
with
update
can
take
the
finalizer
off
if
they
read
something
on
the
Internet.
D
H
So
I
I'm,
my
concern
is
with
David
I,
see
more
and
more
controllers
coming
up
and
people
granting
them
overly
broad
access,
which
just
scares
the
pants
off
me
I
hear
your
your
point.
Jordan
I've
certainly
seen
those
stack
Overflow
posts,
but
at
least
the
blast
is
localized
right
like
well.
You
you
blew
something
up
in
your
own
namespace
I
I,
don't
feel
too
bad
for
you
right
like
we
can
do
better
about
that,
but
take
into
its
conclusion.
H
In
addition
to
liens,
one
of
the
things
I
thought
was
interesting
was
and
I
know
that
it's
not
the
normal
kubernetes
sort
of
rest
semantic,
but
was
we
could
make
it
possible
through
sub
resources
to
say
this
person
is
allowed
to
add
annotations,
but
only
annotations
that
have
this
prefix,
right
and
and
actually
that's
kind
of
interesting
I
can
give
my
Fubar
controller
access
to
all
annotations.
That
start
with
fubar.com-
and
you
know
that
gives
you
some
limited
impact.
Finalizers
too
some
limited
sorry
limited
attack
of
what
you're
describing
as
a
problem.
A
B
H
B
B
D
A
A
A
D
I
mean
if,
if
we
saw
these
two
there's
two
different
sides
of
the
same
coin
like
sometimes
you
only
want
to
Grant
access
this
one
thing.
Sometimes
you
in
specific
Fields,
you
want
a
generic,
updater
or
Creator
to
also
specifically
have
access
to
this
field.
I
would
map
those
to
the
same
permission
check
so
that
the
controller
who
you're
going
to
give
targeted
access
to
that
field,
like
you
have
to
you,
have
to
give
access
specifically
to
that
field,
and
then
a
user
who
has
generic
update
access.
D
B
D
A
B
H
D
C
C
E
D
D
H
I
was
just
gonna
make
the
last
point
on
the
evolution
of
stuff.
I
mean
what
we've
done
in
a
few
other
places
is
decide
wow.
That
was
a
bad
thing
to
have
done.
Let's
make
it
possible
for
users
to
do
the
right
thing
in
the
future
and
recommend
to
them
they
should,
but
that
becomes
an
opt-in
thing
on
a
cluster
level.
H
Granule
with
well
documented,
escape
hatch,
I'm
thinking
about
stuff,
like
the
endpoints
manipulation
right
like
we
over
granted
that
permission
by
default,
and
now
we
say
we
don't,
but
you
can
turn
it
back
on
if
you
want
to
and
then
implementers
like
openshift
and
gke
and
NATO
eks
can
choose
whether
they
want
to
go
through
the
pain
of
moving
their
customers
over
to
the
new
model
or
not
I
mean
the
truth.
Is
we
have
to
support
both
forever?
A
A
A
D
I
mean
what
we've
done
with
other
stuffing
clients
like
any
any
Flags,
get
like
alpha
or
experimental
in
the
flag.
Any
dedicated
commands
get
put
under
the
alpha
sub
command
and
any
dedicated
configurations
like
the
API
version
on
the
config,
is
Alpha
so
like,
however,
you're
interacting
with
the
surface
area
of
it,
you're
typing
experimental
or
alpha
or
like
you're,
configurus
Alpha.
And
then
it's
like.
F
E
So
we
too,
Alpha
One
implies
that
we're
going
to
end
at
V2,
which
is
not
the
end
goal.
The
end
goal
is
V1.
With
this
new
field.
That's
perfect,
so
I
I,
don't
know
what
sort
of
like
the
project
level
guidance
on
something
like
this
is
and
but
I
think
there.
There
probably
should
be
something
that
I
I
think
you
should
not
be
able
to
accidentally
run
into
this
feature.
If
you
need.
F
F
A
D
E
E
Well,
I
I!
No,
my
concern
is
mostly
I
just
want
to
make
sure
that
until
this
is
I,
guess,
GGA
I
think
because
beta
is
still
is
supposed
to
be
off
by
default.
Now,
I
think
that
a
user
has
to
take
some
action
for
them
to
be
opted
into
this
Behavior.
That's
all
that's
the
main
thing:
it's
not
that
I
think
right.
So
we're
going
to
go
wrong.
I'm.
F
D
E
Yeah
I
think
this
is
fine
for
like
offline,
but
I.
Think
metrics,
for
this
are
interesting,
because
this
code
is
invocable
through
web
books
on
the
API
server.
So,
yes,
it
is
the
campus
scope.
Does
hey
I
have
a
client
that
wants
to
authenticate
to
the
API
server,
but
that
same
code
is
used
by
the
API
server
to
authenticate
to
external
identities,
so
it
can
be
turned
around
and
done
in
the
other
direction.
E
A
A
F
A
A
I've
gone
through
and
done
so
so
I
think
there
was
some
stuff
around.
It's
not
clear
why
there
was
mtls
Federation
stuff
in
there.
I
came
up
with
a
different
way
to
do
my
model
of
that
just
using
annotation,
so
I've
just
cut
all
that
stuff
out.
The
API
object
is
very
simple.
Now
the
cubelet
projected
volume
is
very
simple,
so.
A
E
G
Yeah
I
know
we're
super
short
on
time
here
and
don't
have
much
time
to
cover
reference
Grant,
but
I
wanted
to
just
spend
I
guess
the
the
few
minutes
we
have
left
trying
to
answer
a
couple
key
questions
here.
One
reference
Grant
is
used
widely
within
Gateway,
API
and
Sig
store
is
showing
interest
in
one
of
their
caps.
Is
there
interest
in
a
neutral
home
for
it
and
then
two?
If
so,
should
we
delay
our
plans
to
graduate
reference
Grant
debata
within
our
Gateway
API
and
networking
API
Group.
C
So
one
thing
I'm
not
clear
on
is
the
the
reference
Grant
is
is
a
way
to
say:
I
was
away
for
one
person
in
namespace
a
to
say,
I
own.
The
things
in
this
namespace
and
I'm.
Okay,
with
objects
of
this
type
in
namespace,
be
referencing,
I'm,
understanding
it
correctly
correct.
But
in
order
to
make
that
check
generic,
how?
How
does
some
generic,
let's
assume
admissions,
plug-in,
know
that
there
should
be
a
referential
match
like
do
you
have
to
specifically
like?
C
G
Yeah,
it's
hard
to
make
this
a
generic
and
Jordan
covered
this
in
one
of
his
questions
in
the
agenda
as
well.
It's
hard
to
make
this
truly
generic,
because
the
reference
could
come
from
any
number
of
things
right
now
in
Gateway
API.
It's
well
defined
because
it's
one
of
two
places
and
those
places
are
very
clearly
defined
in
the
six
storage
proposal.
It's
one
very
clear
place
as
well
and
in
all
cases
The
Proposal
is
for
it
to
be
implemented
by
the
implemented
controller
of
the
API.
G
D
Yeah,
so
it's
not
an
admission
time
check,
it's
a
runtime
check,
so
the
controller,
that's
following
the
reference
is
assumed
to
already
have
read
permission
and
it's
self-gating
on
the
presence
of
one
of
these
reference
grants
in
order
to
say
like
before,
I
follow
this
link.
You
sent
me
I'm
going
to
see
if
the
person
on
the
other
end
is
happy
with
that.
H
H
D
Yeah,
so
a
lot
of
the
a
lot
of
the
questions
I
had
were
sort
of
around
like
how
how
do
those
various
controllers
were
expecting
to
get
themselves
on
this
like
consistently
in
a
way
that
doesn't
leak?
Information
is
the
reference
fine-grained
enough,
and
so
Rob
and
I
were
kind
of
going
back
and
forth,
and
I
I
think
something
like
an
admission
check
or
a
storage
check
on
the
reference.
Grant
object
itself
to
say
like
if
you
want
to
allow
exposing
secrets
from
your
namespace
to
other
namespaces.
D
D
H
Do
we
have
do?
We
have
other
existence,
proofs
of
places
where
we
do
sort
of
controller
on
behalf
of
user
work,
and
we
verify
that
the
user
was
allowed
to
do
the
thing
that
the
controller
would
do
for
them
like
creating
pods
from
a
deployment
right
in
theory,
I
could
create
a
deployment
and
not
have
the
Pod
any
pod
permissions
and
still
get
pods
or
I
could
change
my
labels
in
my
pod
and
trick
a
deployment
into
adopting
me
and
then
deleting
it
like.
Have
we
done
clearly,
we
sh.
H
D
All
aware
of
is
in
certificate
API,
because
the
API
captures
the
person
that
created
the
certificates
on
request
and
then
the
controllers
do
like
approved
checks
based
on
the
identity
of
the
user.
But
that's
the
only
place.
I
know
that
we
capture
that,
and
even
that,
like
other
places,
are
like,
can
we
record
the
creating
user
or
the
updating
user
like
in
an
authoritative?
You
know
trustworthy
way
and
it
actually
is
kind
of
problematic.
D
D
That
is
set
from
user
agent,
not
from
Identity,
and
it
doesn't
explode
groups
and
it
I
don't
think
it
explodes
username.
It
might
make
special
cases
for
service
accounts.
I
can't
remember
the
derivation
Tim
to
your
question,
like
yeah,
we've
sort
of
hand
waved
over
like
yeah,
but
that's
sort
of
what
deployments
mean.
If
you
give
someone
deployment
right
permission,
you
are
giving
them
pod
write
permission
and
the
fact
that
it's
contained
within
the
same
namespace.
D
H
D
Yeah
I
know
we're
out
of
time.
I
I
would
encourage
people.
Look
at
this
ask
questions,
especially
with
an
eye
to
like
if
this
was
a
generic
thing,
that
multiple
projects
we're
going
to
use
like
what
assumptions
made
sense
in
the
context
of
Gateway
that
maybe
we
should
expand
or
rethink
or
refine.
If
it's
going
to
be
generic
so
and
Rob,
would
you
prefer
we
do
this
like
in
the
stock
or
on
the
list,
or
do
you
care.