►
From YouTube: Kubernetes SIG Auth 20171115
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20171115
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
B
B
B
Someone
opened
a
open,
ID
connect
user
login
flow
for
coop
CTL
authsub
command.
This
is
a
so
today
in
with
the
coop
config
and
coop
CTL.
We
have
a
way
of
configuring,
something
called
an
auth
provider.
The
available
off
providers
that
I'm
aware
of
are
an
open
I
did
connect
one
a
GCP
one,
a
asher
one
and
a
keystone
one.
What
the
author
editors
do
is
they
look
at
your
environment
or
environment
or
they
are
configured
in
some
capacity
to
be
able
to
rotate
bearer
tokens.
B
So,
as
you
are
using
coop
CTL
plugin
we'll
grab
a
bearer
token
from
your
configuration,
rotate
it
if
necessary,
and
do
that
kind
of
thing
so
you're
always
authenticated
against
the
API
server.
What
well
it
does
allow
you
to
to
set
that
up
in
some
way.
It
has
always
been
an
idea
that
these
off
providers
would
eventually
allow
you
to
actually
log
in
to
your
to
your
to
your
provider
in
the
first
place,
to
get
a
bearer
token.
B
So
what
this
PR
does
is.
It
adds
a
new
sub
command
to
coos
ETL.
The
exact
sort
of
interaction
with
sig
cry
hasn't
been
specked
out.
Yet
it
turned
out
that
this
wasn't
this
PR
at
least
wasn't
didn't,
go
through
the
proposal
process
for
sig
fly
yet,
but
it
certainly
is
kind
of
interesting.
It
just
does
a
basic
sort
of
hola
to
flow
launches,
a
browser
you
do
your
redirects
and
get
redirected
to
localhost,
so
I
think
it's
at
least
definitely
worth
taking
a
look
at
I.
B
D
A
The
the
local
device
flow
is
not
really
a
concern
for
me
at
this
point.
I
I
do
think
for
this
we'd
probably
want
a
cleaner,
so
operation
between
the
type
of
rotation
mechanism
and
an
actual
login
mechanism.
Getting
interactive
commands
popping
up
in
the
middle
of
what
you
thought
was
a
non
interactive
call,
probably
isn't
great,
so
I
think
a
design
and
treating
those
two
bits
as
separate
and
letting
off
providers
contribute
some
sort
of
interactive
flow
either
via
mechanism
like
this
or
I.
E
There's
a
mechanism
for
GCP
for
plugging
in
a
command
to
refresh
a
token
I
started
working
on
like
an
AWS
sort
of
Authenticator.
He
said
I
demoed,
it's
it
gonna,
be
us
a
couple
weeks
ago
and
really
wanted
a
similar
kind
of
plug-in
interface
and
the
coop
in
coop
CTL
to
like
I,
run
this
command
to
generate
that
token.
There
right
now
I
think
I'd
like
to
make
sure
it
covers
that
use
case
as
well.
It's
not
not
OID
see
it's
yeah.
F
B
It
got
better,
alright,
yeah,
oh
yeah,
yeah
I,
definitely
know.
I,
definitely
think
that
there
are
is
definitely
more
Oh
Louis
than
I
can
name
that
are
possible.
So
that's
something
we
should
discuss.
I
think
Wheatley
for
this
one
not
getting
in
for
1/9.
We
can
sort
of
respond
or
I'll
respond,
that
this
needs
to
think
about
these
sort
of
issues
and
hopefully
come
up
with
the
proper
proposal
for
something
for
one
time.
So
I
think
it's
a
great
thing
to
solve,
also
by
the
way
so
yeah
I
just.
C
H
Also
Mike,
we
we
can
all
right
sorry
it's
having
some
mic
problems.
I
wanted
to
weigh
in
and
just
say
that,
I
think
it
would
be
a
very
nice
to
advance
our
off
provider
plug-in
mechanism
a
little
more
than
it
is
today.
Specifically,
we
have
like
36
companies
that
are
now
conformant
to
they
have
joined
the
kubernetes
conformance
effort
and
I.
Don't
think
it's
a
scalable
to
build
non-generic
like
a
GCP
or
AWS
integration.
H
It's
off
providers
anymore,
so
I
was
looking
and
considering
how
to
move
some
of
this
stuff
out
recently
that
the
API
is
for
building
auth
providers.
Very
generic
today
and
I
also
wanted
to
extend
off
provider
support
not
just
for
acute
control
but
for
authenticating,
the
bootstrap
line
and
in
cubelet
for
use
cases
like
that,
so
I
think
the
auth
provider
framework
needs
so
a
bit
of
work
that
said
I
think
OID
C
is
a
reasonable,
reasonably
standard
enough
that
it
makes
sense
to
include
it
as
a
first-class
LinkedIn
integration,
yeah.
E
I
think
there
are
elements
of
this
where
it
makes
sense
to
think
about
it
for
coops
ETL,
because
there's
some
user
facing
interaction
that
you
want
to
like
a
CLI
kind
of
interaction.
You
want
to
go
straight,
but
then
there's
also
use
cases
like
in
client
go
we're
cooler
or
something
where
you
want
to
plug
in
at
that
point
too.
So
I
think
potentially
there's
two
layers
of
of
interface
that
need
to
be
added
and
some
of
its
already.
There.
B
B
I
added
these
other
two
items
to
the
puzzle:
no
just
four
because
I
know
they'll
be
interesting
to
some
people.
I
didn't
actually
have
any
specific
things
that
I
wanted
to
talk
about
for
the
km/sec
web
hook,
but
that
was
added
or
a
pull
request
for
that
was
submitted.
At
least
this
is
part
of
the
effort
to
enable
AMS
providers
that
are
external
to
the
API
server,
and
not
just
the
sort
of
built-in
kms
providers
that
were
actually
removed
recently,
I'm
told
I
mean.
B
B
F
F
Posted
an
issue
in
the
chat
I
mean
there's
this
ongoing
discussion
around
the
mission
controllers
in
terms
of
what
is
the
forum
for
web
hook
calls
there
now.
Obviously,
this
is
in
some
ways
a
little
bit
of
a
different
beast,
but
there
is
this
question
of
like
how
many
different
sort
of
forms
of
api's
do
we
have
when
people
are
implementing
web
hooks.
F
Isn't
a
admission
controller?
No,
no
okay!
So
admission
controllers
as
we
went
as
as
API
machinery
was
going
towards
mutable
admission
controllers
via
web
hooks.
There's
a
discussion
spawned
from
that
is
what
is
the
form
of
the
web
hook?
Should
it
actually
use
our
traditional
spec
status,
or
should
I
actually
move
to
a
more
gr,
PC
based
response
request,
type
of
thing
this
hit
last
minute?
If
we're
going
to
talk
about
it,
it's
a
Gorka
texture
and
it
spawned
the
issue
that
I
linked
here.
C
F
Don't
get
me
wrong,
he
may
be
a
different
beast.
I
think
it's
just
worth
looking
to
see
like
this
is
yet
another
new
way
in
a
new
form
and
a
new
sort
of
way
that
the
API
server
is
calling
out
I
think
we
fact
that
there's
going
to
be
there's
already
a
format
in
terms
of
how
the
cubelet
calls
out
and
that
has
different
requirements.
This
is
interesting
because
it's
not
a
traditional
web
hook,
but
it's
also
more
akin
to
I,
don't
know
CD
in
some
ways
right.
F
D
Another
one
we've
got
so
we've
got
CNI
flex,
volume
is
exact,
CSI
is
jerry,
CRI
is
authorizer,
admission
offer
all
of
the
typed
ones
or
actual
API
calls
in
a
node
format.
The
admission
one
is
a
generic
format.
This
is
definitely
not
generic,
so
we
would
definitely
need
to
go
through.
The
like,
like
ERP,
seems
convenient
because
they
didn't
want
to
invent
a
new
API
Machinery
style
on
the
node,
which
has
really
prepare
the
scenery.
But
we
are
reinventing
we're
using
all
the
extension
mechanisms
as
possible
using
a
shared
library.
I
A
F
G
Hey
Joey
that
you
posted
on
the
zoom
trap.
That's
new
to
me!
Daniel
and
I
worked
on
this
proposal
that
we
just
saw
on
GRDC
Base
kms
plugins.
If
you
want,
if
I
I'm
struggling
with,
what's
what's
the
curated
set
of
mechanisms
that
we
should
pick
from
and
we're
building
these
it's
fine
to
change,
it
I'm
perfectly
happy
to
do
that.
But
if
there
is
a
curated
list
of
mechanisms,
point
me
edited
we'll
go
figure
out
how
to
use
one
of
those
so.
F
F
Can
we
actually
start
describing
these
patterns
and
making
it
easier
to
distribute
the
knowledge
around
sort
of
what
works
when
and
where
and
how
a
part
of
that
also
is
you
know:
can
we
bring
some
of
the
sort
of
API
review
stuff
that's
been
happening
also
in
a
sort
of
one
on
one
ad
hoc
manner
into
a
sort
of
you
know
into
the
light
into
a
more
transparent
process
such
that
such
that
we
can
start
building
some
institutional
knowledge
across
a
wider
set
of
people
around
what
how
this
stuff
works.
Like
a
subject.
A
C
C
F
G
F
B
B
B
Sorry,
it's
a
noisy
in
downtown
San
Francisco,
the
the
next
one
is
about
the
about
nodes
being
able
to
impersonate
service
accounts
for
pods
that
are
bound
to
them.
So
this
is
part
of
the
node
authorizer
and
would
allow
nodes
to
act
on
behalf
of
that.
I
wanted
to
bring
this
up
because
it
seemed
like
there
was
a
little
bit
confusion
about.
Why,
specifically,
we
want
to
allow
this.
B
H
So
this
was
very
useful
in
my
prototyping
that
I've
been
doing
around
the
job
minting
I
wanted
to
publish
all
of
my
prototype,
so
I
decided
to
send
out
this
PR
I.
Don't
expect
it
to
get
in
when
I
know
or
in
script
form,
but
I
wanted
to
start
discussion
of
how
a
node
could
no
credentials
could
be
used
to
to
receive
pod
credentials
and
how
that
auth
would
flow
would
work.
H
The
node
authorizers
is
very
useful
in
this
situation
because
it
already
has
the
graph
of
node
to
pod
to
service
account,
so
it
was
easy
for
me
to
shim
it
in
there.
It's
I
think
I
would
have
had
to
duplicate
that
and
also
add
a
web
hook
authorizer.
If,
if
I
wanted
to
build
this
in
into
a
separate
process,
so
I
would
have
had
to
basically
copy
all
that
note
authorizer.
Could
the
other
thing
is
it's
not
particularly
easy
to
configure
multiple
webhook
authorizers?
H
So
maybe
that's
something
that
we
might
want
to
consider
supporting
if
we
want
to
support
stuff
like
this
outside
of
core
but
yeah.
So,
that's
basically
why
this
PR
exists
but
I'm
interested
to
hear
your
ideas.
So
what
I
was
doing
is
I
was
taking
the
node
credentials
using
that
from
a
node
agent
to
request
from
the
kubernetes
api
on
behalf
of
a
pod
that
was
starting
up
if
I
could
get
a
shot
signed
so.
H
That
seemed
to
work,
there's
no
context
on
there's
no
way
using
our
Becht
or
or
sorry
the
subject,
access
review
and
for
context
of
why
this
delegation
is
being
made
that
I
can
then
I
know.
If
so,
it
might
be
useful
to
have
carry
context
like
this.
Impersonation
is
happening
by
this
user
for
this
user
on,
in
this
specific
context
like
accessing
this
specific
API,
but
none
of
that
is
carried
forward.
H
So
if
we
wanted
to
add
constraints,
we
might
want
to
add
to
the
subject
access
review,
but
it
kind
of
goes
to
show
that
subject,
access
review
might
not
in
its
current
form
or
with
the
current
information
that
it
carries,
might
not
be
fully
suitable
to
make
all
authorized
ation
decisions
that
we
might
want
to
make.
But
that's
kind
of
the
point
that
I
got:
do
you
guys
have
any
comments.
C
C
Just
let
the
node
be
allowed
to
request
one
for
the
service
accounts
bound
to
as
the
just
have
to
duplicate
the
graph,
and
if
that
was,
the
concern
seems
like
you
could
do
a
secondary
check?
Are
you
allowed
to
sign?
Is
this
user
allowed
to
sign
for
this
other
user?
A
similar
that
the
secondary
author
check
that
the
impersonation
naive
use
so.
H
C
Seems
like
it
would
be
a
useful
thing
right,
I
mean
not
that
there
won't
yeah.
It
seems
like
that
would
just
be
a
generally
useful
thing
right,
like
a
user
who
has
the
power
to
use
the
service,
account
may
also
deserve
to
be
allowed
to
get
one
and
get
a
Johnson
for
it
or
other
identities
too,
like
maybe
some
way,
I
hate,
John
sign
for
a
note,
yeah.
The
use.
D
Case
so
and
like
I
think
when,
when
we
were
talking
about
this
too,
like
it
really
came
down
to
do,
we
want
to
say
that
running
a
pod
as
a
service
account
is
effectively
the
equivalent
of
being
able
to
be
the
service
account,
and
that's
kind
of
a
conceptual
thing
like
I
totally
agree.
Do
that
there's
other
ways
we
can
slice
it
that
was
kind
of
the
the
question
I
had
was
we
a
node
is
fundamentally
acting
as
the
pod
and
therefore
the
service
account.
D
J
A
D
A
Yeah
today,
absolutely
its
undifferentiated,
but
I
thought
the
goal
of
some
of
the
menteng
credentials
per
pod
per
service.
Account
was
to
get
away
from.
You
know,
one
secret
and
it's
shared
by
all
nodes
who
see
that
service
account
and
make
it
more
reasonable
to
loop.
The
chain
of
the
node
to
the
secret
for
the
service
account
so.
F
A
A
D
Credentials
to
do
only
the
thing
that
it's
the
same
node
can
do
is
a
huge
problem
right
now,
because
four
nodes,
where
the
node
can
only
do
certain
things,
you
have
two
choices:
if
you
have
a
daemon
set,
that
also
needs
access
to
the
pot
info.
You
can
the
node
credentials,
and
so
they
can
do
everything
the
node
can
do,
including
reading
secrets
or
you
can
give
it
a
service
account
token
that
lets
it
do
everything
which
completely
defeats
the
purpose.
Yeah.
F
A
F
A
A
And
my
if
I
can
see
it's
useful
for
like
requesting
a
job
or
a
credential
for
that
service
account,
but
I
think
David's.
Point
of
if
we
want
to
know
to
request
a
credential
for
a
service
account
I
think
having
both
of
those
parties
in
the
request,
rather
than
kind
of
modeling
it
as
an
impersonation
requesting
for
myself,
would
make
sense.
I.
H
I
think
that's
reasonable,
but
I
I
also
want
to
make
it
clear
that
I,
don't
I,
don't
see
you
in
the
short-term
or
ever
I,
don't
know
if
it's
possible
for
us
to
live
in
a
world
where
the
node
root
on
node,
with
no
credential
cannot
get
access
to
serve
a
service
account
credential
for
pods
running
on
that
note,
is
that
understood
by
the
group?
Or
does
anybody
disagree
with
that
because
we
could.
F
J
Belongs
to
the
service
does
to
the
node.
The
node
can
say:
hey
I,
don't
want
these
service
to
around
me
and
then
cure
the
service,
but
the
you
know
shouldn't
even
the
root
shouldn't
get
the
credential
of
the
service,
because
the
credential
of
the
service
belongs
to
the
service
model.
Note
right,
I'm,
saying
like
maliciously.
D
Difference
because
if
you
have
root,
you
can
read
memory
and
you
can
intercept
all
Network
calls
and
there's
nothing
that
you
can
do
like
we're,
not
trying
to
defend
against
that.
Unless
we
were
to
say
the
cubelet
wouldn't
run
his
route
and
that's
never
gonna
happen
like
the
cube,
would
I
admit.
Maybe
three
years
from
now,
but
like
in
the
short
term
like
I,
don't
see
the
distinction
as
being
useful.
Yeah.
F
D
We've
definitely
talked
about
the
cubelet,
rejecting
workloads
by
asking
a
trusted
party,
but
as
long
as
like
whoever
gets
to
run
route
processes
or
runs
this
route,
we
might
as
well
just
put
the
barricade
there
and
have
a
little
bit
of
an
internal
abstraction.
I
guess,
like
I,
feel
like
we're,
making
a
distinction.
That's
not
actually
gonna
lead
to
a
better
security
outcome
in
the
near
term.
D
If
we
don't
like
at
least
think
through
this
in
this
context,
that
the
node
is
is
asking
for
the
permission
to
get
the
credentials
to
run
a
workload
that
it's
been
told
to
run
in
order
for
it
to
run
those
credentials
and
now,
if
we
could
still
have
an
access
control
check,
the
mod
can
say:
don't
this
pot
doesn't
get
us
service
account
token
injected?
We
could
add
an
authorizer
check
to
say
we
refuse
to
grant
this
to
you,
because
this
pot
didn't
give
those
credentials,
but
it's
still
kind.
C
Of
aimless,
because
I
guess
I
look
at
it
from
the
perspective
of
what
I
want
the
information
to
be
able
to
accept
the
job.
Signing
request.
Do
I,
see
general
utility
in
the
idea
of
I
want
to
request
a
job
for
that
and
if
I
were
to
sign
for
a
job,
what
I
want
to
have
some
indication
of
of
true
origin
and
I?
Think
all
those
things
yes
yeah
and
I
don't
object
to
the
intent
right
like
should
have
no
to
be
able
to
get
it
yeah
absolutely
but
being
able
to
get
it
via.
D
David
like
in
this
case,
we
were
talking
about
you,
said
embedded
earlier.
This
would
not
be
embedded.
This
would
be
running
as
a
as
a
plug-in.
In
theory,
we
want
to
take
us
out
of
the
core,
and
so
then
the
API
did
admit
the
jots
and
the
the
web
hook.
Authorization
is
essentially
a
very
trusted
process,
but
it's
running
separately
so
because
the
nodes
are
talking
to
that.
D
D
You're,
saying
like,
like
that's
a
useful
way
to
think
about,
like
it's,
making
all
the
decisions,
it's
okay
for
it
to
do
additional
checks
that
has
to
I
kind
of
suggested.
The
impersonation,
because,
like
we,
keep
saying
that
permission
to
impersonate,
something
is
the
permission
to
go
act.
Is
it
and
this
the
node
is
acting
as
the
pot
and
I
just
does
a
hang-up.
For
me,.
H
B
Awesome
it.
B
H
H
Right
address
so
what
we
started
in
today
also.
F
How
do
we
extend
our
back
to
start
handling
these
extended
things,
including,
like
you
know,
secrets
in
a
sort
of
more
fine-grained
way
and
I
know?
There's
been
a
ton
of
discussion
there
and
I
haven't
paged
all
that
in
I.
Don't
know
if,
like
these
new
scenarios
are
worthwhile
to
you,
know
noodle
on
that,
some
more.
If
people
have
time
or.
F
Could
we
model
this
in
terms
of
actually
another
authorizer
a
way
to
essentially
have
an
alternate
representation
of
a
resource
that
is
essentially
other
information
that
goes
into
the
our
back
type
decision?
Is
there
a
way
that
we
can
actually
sort
of
have
a
bunch
of
things,
annotate
resources
with
extra
contexts
that
are
back
to
videos
if.
C
J
C
Had
a
list
of
other
things
you
were
thinking
about,
I'd
be
very
interested
in
looking
at
it.
Most
of
what
I've
seen
has
either
been
around
what
amounts
to
feel
or
label
selectors
on
resources.
I
think
that
that's
part
of
it
I
mean
even
something
like
with
secret.
The
secret
type
could
be
huge
right.
That's
a
field
selector,
so
so
yeah
I
agree.
You
can
get
big
benefits,
but
I.
Think
having
a
specific
list
to
talk
about
will
help
us
target
it.
A
A
couple
of
things
there,
one,
the
node
authorizer,
doesn't
actually
get
any
additional
context
on
the
incoming
request.
So
the
the
thing
is
it
makes
its
decision
on
could
be
done
already
with
a
manifest
at
our
back
policy.
So
it
what
the
shortcomings
but
the
the
gaps
that
we
see
where
it's
you're,
making
authorization
decisions
based
on
contents
of
requests.
We
actually
still
have
to
have
an
admission
plugin
for
the
okay.
A
F
A
The
fact
that
every
every
cluster
has
cubelets
and
scale-
that's
that's,
probably
gonna,
be
the
hot
spot.
That's
why
we
had
a
custom
one
but
for
lower
scale,
slower
moving
things
like
a
controller
that
needs
a
secret
for
an
ingress.
You
know,
you're,
probably
not
rotating
your
search,
hundreds
of
times
a
second
I
hope
you're,
not.
F
C
It's
really
useful
to
like
write
down
a
reasonable
stuff.
That's
already
there,
because
trying
to
make
authorization
decisions
based
on
the
content
of
the
thing
that
you're
retrieving,
which
I
think
is
what
I
heard
you
described,
is
something
that
is
well
both
not
possible
with
the
authorization
that
we
have
set
up
today.
But
even
the
deeper
levels,
like
admission,
isn't
wired
to
work
today
and
the
semantics
around
washing
something
like
that
are
far
less
than
obvious,
since
it
wouldn't
match
normal
queue,
semantics
as
things
and
if
you're
in
leave.
C
To
the
end
yeah,
and
having
a
write
up
that
describes
it
where
we
can
comment
and
point
out
likely
problems
and
conflicts,
we're
gonna
have
it's
going
to
be
helpful
right.
Openshift
actually
did
create
a
Knakal
filtered
view
on
some
resources
and
is
something
we
learned
a
lot
doing
and
it's
very
expensive
and
the
API
still
does
not
work
like
a
normal
cube.
Api,
so
I
think
is
going
to
need
some
deep
exploration
and
people
are
likely
going
to
need
some
significant
background.
F
G
F
D
Big,
what
on
that
is
what
Mike
was
doing
so
Mike
and
I
have
kind
of
sketched
this
and
Matt
has
been
that
we
talked
about
this
in
container
identity
as
well,
like
Greg's,
been
involved
a
bunch
of
discussions,
but
that's
take
service
accounts
out
of
secrets.
If
service
account
tokens
aren't
in
secrets
secrets
immediately
drop
from
being,
you
can
get
root
access
to
the
entire
cluster.
The
moment
you
have
secret
to
you
can
get
access
to
secrets.
That's
that's
step.
One
I'm.
F
D
F
D
C
Of
how
to
solve
that,
one
Jo
two
releases
go
Wojtek,
ruin
up
a
proposal
for
a
watch
on
a
specific
resource
right
so
that
you
would
be
able
to
say
I
want
to
watch
this.
One
I
want
to
watch
that
one
I,
don't
wanna
watch
the
other
one
and
for
an
ingress
controller.
I
think
that's
exactly
what
you
would
like
to
be
able
to
do
right.
I
want
to
be
I.
Have
the
names
I
want
to
be
able
to
watch
that?
One
of
that
one
of
that
one
and
he
had
a
proposal
to
do
it.
C
The
B
proposal
I
think
we
even
merged
it
and
we
merged
that
Clayton.
Remember
reviewing
a
centralized,
we
merged
said
it.
It
probably
needs
a
good
shake,
but
but
the
concept
there
was
very
good
for
that.
For
that
Hughes
case.
That
was
a
problem
that
we
didn't
solve
with
an
authorizer.
We
solved
it
with
a
new
concept
in
API
machinery,
a
specific
get
that
gets
MUX
and.
D
The
scope
of
that
is
typically
smaller
than
the
sub
of
every
other
resource.
Like
you,
if
your
ingress,
if
you're
giving
access
to
your
ingress
to
Alice
secrets
anyway,
you
have
a
problem.
The
onesy
case
has
to
get
easier,
though,
and
maybe
this
is
to
Mike's
point
like
if
it's
it's
still
hard
to
do,
one
Z
rules
because
you're
creating
a
role
and
the
binding
and
a
subject.
At
the
same
time,
there's.
E
A
Would
be
like
a
user
comes
with
their
object
and
in
this
object
schema
it
references
a
secret
and
then
as
part
of
the
controller
or
the
installing,
the
controller.
For
that
you
give
the
controller
permissions
to
access
secrets
reference
that
way,
and
so
it's
it's
manifesting.
A
policy
from
those
objects
that
kind.
E
D
Was
initially
intended
for
the
cubelet,
we
said
instead
of
solving
this
a
different
way.
Let's,
because
web
consoles
have
this
problems,
do
anybody
who
has
a
lot
of
controllers
has
a
watch
problem
and
if
you're
dealing
with
anything
less
than
cluster
scope,
you
still
have
a
large
problem.
You
have
lots
and
lots
of
little
watch
problems,
and
so
this
was
like.
Can
we
solve
these
all
together,
because
we
also
dirty
secret?
We
don't
recheck
authorization
after
you
open
a
watch.
D
F
Let
me
let
me
get
this
straight,
so
if
we
had
this
watch
mechanism,
what
I
would
do
is
I
create
a
new
ingress
object.
It
references
a
secret
that
holds
my
TLS.
Let's
ignore
cute
Lego,
insert
manager
and
stuff
like
that.
I
then
have
to
write
an
Arabic
rule
that
allows
the
service
account
that
that
unrest
is
running
under
to
get
access
to
that
particular
secret.
And
it's
it's
me
the
ones
who
has
to
actually
sort
of
explicitly
whitelist
the
service
account
for
the
for
the
ingress
controller
and
get
access
to
my
right.
A
A
I
E
A
Separate
it
from
so,
you
don't
have
to
put
it
in
the
same
place
as
your
ingress
controller,
which
is
exposed
to
you,
know
the
world
it
I
could
even
see
being
able
to
expel
that
thing
how
to
write
policies
in
a
generic
way.
Like
look
at
these
objects,
this
JSON
task
references
a
secret
granted
to
this
granted
to
this
component,
and
that
way
you
could
use
it
against
multiple
different.
So.
D
C
A
A
D
Edit
that
ingress
I
can
change
what
secretive
references
then
I
can
access
any
secret
by
name
because
there
has
to
be
a
policy
on
the
controller
side.
That's
giving
our
back.
That
says
who
do
I
give
our
back
to
so.
You
still
need
some.
There
has
to
be
a
two-sided
thing.
If
ingress
can
reference
any
secret,
then
you
can
yeah.
C
But
the
point
isn't
exactly
how
you
grant
that
our
mission?
The
point
is
that
you
could
actually
write
something
to
automatically
grant
that
our
that
permission,
the
Arabic,
if
you
want
to
do
but
the
ingress
patroller
in
particular
the
thing
that's
reading
the
secret
doesn't
have
to
have
full
access.
It
could
use
a
particular
like
get
me
this
one
or
watch
this
particular
one
is.
E
A
Benefit
of
this
approach
is
that
from
the
the
users
perspective,
they
don't
care,
they
just
here's.
My
ingress,
here's
my
secret
from
the
ingress
controllers
perspective.
It
doesn't
care
it
just
doesn't
get
today
and
hopefully
someday
soon
has
the
ability
to
watch
individual
secrets,
so
it
can
get
updates.
It
doesn't
know
that
it's
being
authorized,
it
doesn't
know
whether
it's
being
authorized
broadly
or
narrowly.
J
A
Just
following
links
from
ingress
objects
and
getting
the
data
it
needs
and
then
at
the
authorization
layer.
If
you
don't
care
about
this-
and
you
just
want
to
say
you
know
what
list
all
your
secrets,
whatever
you
or
you-
could
give
particular
access
based
on
one
way,
links
or
two-way
links
or,
however,
you
wanted
to
whenever
you
wanted
to
base
that
on
it.
It
makes
the
different
layers
not
have
to
think
about
each
other,
which
is
what
you
want.
There
is
an
issue
here.
F
A
Absolutely
and
I
mean
we
have
that
today,
right
I
mean
even
the
are
back:
authorizer
works
off
of
an
informer
fed
cache.
So
if
you
create
a
role
and
then
immediately
try
to
do
something,
you
might
get
forbidden
for
a
millisecond
or
two
if
you've
set
up
a
pod
that
references,
a
secret
and
the
qiblah
traces.
The
node
authorizer
before
the
graph
is
updated
and
tries
to
fetch
the
secret
yeah
it
might
get
forbidden
and
have
to
retry.
But
you
see.
D
This
is
the
e
logs
today,
every
cube,
API
server
has
a
whole
bunch
of
access
denied
at
the
beginning.
It's
it's
this.
This
problem,
I
guess.
The
one
point,
though,
is
if
it's
not
easy.
We
can't
explain
this
like
so.
The
easiest
thing
today
is
everybody
grants
access
to
all
secret
the
the
way
to
solve
that
is
to
give
someone
an
equivalent
that
feels
just
as
easy
that
they
start
doing.
C
The
idea
of
show
me
all
the
X's
that
I
can
see.
I
think
that
would
be
an
awesome
feature,
but
I
don't
see
that
as
directly
related
to
the
particular
kind
of
authorization
and
choice
and
I
think
that
a
lot
of
use
cases
can
actually
be
solved
differently.
So,
like
I
said,
when
you
write
think
I'd
be
very
interested
to
to
see
it,
read
it
and
comment
on.
A
D
E
There's
another
related
thing
that
we've
talked
about
in
a
container
identity
working
group,
which
is
having
service
account
tokens
mounted
per
container
instead
of
per
pod,
like
one
of
the
scary
things
about
ingress
controllers.
Right
now
is
the
process.
That's
proxy
and
user
traffic
is
also
the
thing.
That's
loading
secrets.
This
would
be
a
good
use
case
that
this
one
use
case
where
it
would
be
useful
to
split
apart
two
containers
in
that
pod
and
have
the
proxy
running
without
any
privileges
and
above
like
a
controller,
that's
not
a
controller
but
like
a
local
manager.
D
J
I
D
F
E
A
F
Thinking
specifically
the
issue
that
that
more
brought
up
around
the
fact
that
the
service
count
token
gets
mounted
into
the
thing,
that's
doing
the
proxy
as
a
reason
like
we,
we
wrote,
contour
I,
want
it
like
right
now.
Contour
runs
the
controller
that
actually
accesses
the
API
co-located
in
a
pod,
with
the
with
the
Envoy
instance.
I
think
it
makes
sense
to
maybe
break
that
out
into
a
separable
service
that
actually
doesn't
have
wide
access,
and
essentially
lock
down
that
envoy
that
you.