►
From YouTube: Kubernetes SIG Auth 2019-10-02
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 2019-10-02
Meeting Notes/Agenda: https://docs.google.com/document/d/1woLGRoONE3EBVx-wTb4pvp4CI7tmLZ6lS26VTbosLKM/preview
Find out more about SIG Auth here: https://github.com/kubernetes/community/tree/master/sig-auth
A
A
A
Essentially,
it
proposes
adding
a
Jukes,
URL
and
also
an
obviously
discovery
document
to
the
API
server
to
make
discovering
the
keys
and
the
issuer
of
the
service
account.
Token
issuer
easier
for
in
cluster
clients
has
a
I
wanted
to
make
sure
that
everybody
got
around
to
reviewing
this
and
was
wondering
if
there
any
thoughts
or
suggestions.
B
Have
not
reviewed
it
or
looked
at
it?
I
do
have
a
question,
though,
is
this
compatible
with
what
Amazon
has
done
with
their?
Was
it
like?
A
service
account
workload,
identity
that
is
somehow
related
to
the
identity
of
the
workload
on
Amazon?
They
have
directions
for
overriding
things
like
the
service
account
key,
an
issue
or
an
audience
as
I
recall
in
one
of
their
help,
dogs.
A
A
B
B
A
Maybe
Amazon
from
hosting
the
or
using
an
issue
or
URL.
That
is
not
that
is
not
directed
at
the
kubernetes
master,
so
you
get
still
host
one
on
food,
AWS,
comm,
slash
well
known,
open,
ID
configuration
that
should
still
be
possible.
I
think
this
is
like
the
easy
way
out.
If
you
have
a
connection
to
the
master
you
know
where
it
is,
you
can
discover
that
information
I
think
David
to
your
question.
I.
A
If
I
understand,
if
I
remember
the
history
correctly,
this
came
out
as
a
desire
to
sort
of
meet
people
where
there
were
people
being
Amazon
and
various
other
providers
that
you
can
tell
them
all
right.
Here's
an
issuer
URL
anything
from
the
village
trusted
to
do
whatever,
or
at
least
trusted
in
the
sense
of
you
can
verify,
and
this
is
a
desire
to
make
cube
API
server,
basically
compatible
with
that
flow.
Okay,.
B
A
Good
I,
don't
think
either
I,
don't
think.
Aws
will
move
their
issue
or
URL
off
of
a
hosted
API.
Even
with
this,
the
existence
of
this
API,
but
if
you
have
a
maybe
in
AWS
client
that
needs
to
know
what
that
issue
or
URL
is
running
inside,
a
cluster
will
have
an
easier
time
to
discover
that
information.
If,
if
we
made
this
available
from
the
kubernetes
api.
A
Mike
is
other
than
obviously
funneling
all
the
information
out
of
like
the
token
Authenticator
and
the
stuff
that's
fed
into
the
cubit
guy
server.
There's
nothing
technically
missing
right,
because
we
got
the
key
IDs
now,
there's
like
nothing
else
missing
from
what
any
anything
that
prevents
us
from
omitting
all
the
information
we
need
from
this
endpoint
nope
I
think
this
is
the
last
bit
the
jukes
and
the
issuer.
Url
are
the
two
places
missing.
Thank
you
all
right.
B
B
There
are
some
details
about
this
that
are
worth
explaining
it.
It
means
what
at
one
of
the
key
pieces
is
that
a
cubelet
cannot
replay
the
cube,
API
servers
credentials
or
an
evil
qubit
rather
right.
We
use
a
in
MPLS
connection,
so
it
can
proxy
you
somewhere,
but
it
cannot
choose
the
URL
that
you
proxy
to
write
so
you're
always
going
to
be
proxying
to
a
particular
set
of
container
locks,
and
it's
if
you
were
to
intercept
to
try
to
rewrite
you
would
be
terminating
it,
so
you
would
no
longer
have
those
credentials.
B
B
I
was
hoping
to
not
try
to
rewrite
the
path
for
a
TCP
proxy
mean
evil
cubile.
It
creates
a
TCP
proxy
right.
It
would
allow
you
to
redirect
it
to
a
different
IP,
but
I
don't
believe
that
it
would
allow
you
to
rewrite
the
content
of
the
request,
because
that
gets
terminated
at
the
final
endpoint
right
yeah.
Well,
just.
A
B
B
He
does
point
out,
but
if
someone
has
cluster
admin
rights
and
can
modify
the
node
object
directly,
you
can
redirect
it
with
a
particular
pod
and
name
space
again,
if
you
can
create
a
pod
in
this
other
namespace,
and
that
if
someone
has
a
deployment
apology
where
they
have
shared
the
credentials
for
a
cube,
API
server
across
two
different
clusters-
and
you
have
rights
to
write
into
any
namespace,
then
you
could
targets
and
you
had
network
connectivity.
You
would
be
able
to
and
you
how
to
evil
Cuba
powers.
B
You
would
then
be
able
to
control
where
the
test
server
sent
his
credentials.
It's
it's
a
pretty
significant
series
of
Ann's
christen
doing
this
is
already
high
powered
I
think
he
even
noted
that
yet
even
noted
it.
The
next
comment
down.
You
already
have
the
power
to
send
these
credentials
somewhere
else.
A
I
think
that
we
are
certainly
saved
by
this
name:
space
I'm,
just
considering
that
the
upgrader,
where
proxy
still
uses
the
API
server
user
users
Authority.
It
does
scare
me
for
bugs
that
might
pop
up
and
we
had
that
confused
deputy
problem
with
the
API
server
earlier
this
year.
I,
don't
think
that
there
is
a
problem
with
allowing
users
to
pick
their
own
level
of
security.
For
for
something
like
get
logs
and
I
see.
This
is
probably
a
useful
feature
during
an
incident.
A
B
It's
certainly
worth
being
extremely
explicit
about
I,
agree
and
I.
Didn't
try
to
sidestep
it
right.
It's
it's
written
down,
I
called
it
out
explicitly
I
added
more
detail
because
Stefan
was
also
concerned
about
it
and
he
wanted
people
be
sure
that
I
was
right
about
a
TCP
proxy
is
not
able
to
rewrite
the
request.
A
B
Expired
is
me,
is
the
only
one
that
I
know
of
at
this
instant
that
I
want
to
bypass
it's
the
specific
one
that
bit
me
when
we
chose
to
add
this
power,
ooh
cute
control
and
to
our
aggregate
of
API
servers
as
it.
For
instance,
we
didn't
try
to
subdivide
it
based
on
like
the
name
matches,
and
the
thing
is
expired.
B
A
B
B
D
B
A
A
B
I'm
pretty
sure
we
build
the
verify
options
and
then
run
it.
How
you
would
expect
right,
you
build
verify
options,
run
standard
verify
after
the
fact
I
will
I
will
have
a
look.
I
am
I,
am
certainly
willing
to
explore
the
option
yeah,
but
I
were
I.
You
I
would
not
get
my
hopes
up
that
it
was
practical.
Okay,
I
feel
like
I.
Remember!
Writing
this
code
once
before
in
a
dial
function
and
thinking
to
myself,
I
really.
D
B
Pretty
bad,
so
you
had
to
go
through
and
create
a
bastion
with
a
different
set
of
credentials
which,
in
this
case,
didn't
exist,
go
through
and
get
the
people
who
were
experiencing
the
problem
to
agree
that
it
was
a
safe
thing
to
do,
to
create
the
bastion
to
then
give
that
SSH
access
into
the
the
individual
master
nodes
connect
to
the
master
nodes.
To
then
look
at
the
data.
It
was
there
only
to
realize
that
wow.
A
A
A
In
general,
I,
don't
think
this
is
a
problem
as
long
as
it
doesn't
hurt
users
that
are
not
using
this
feature
and
I
think
that
we
should
explore
relaxing
this
as
little
as
possible.
For
this
specific
scenario,
where
certificate
rotation
is
failing,
but
other
than
that
and
see
any
I,
don't
have
any
okay.
B
A
B
B
A
B
Certainly
agree
I'd
like
to
ship
as
beta,
so
that
it
can
be
turned
off
in
case
something
unexpected
happens.
It's
not
a
statement
that
I
think
something
unexpected
is
gonna
happen.
It
is,
if
I
happen,
to
write
a
bug
for
the
first
time
in
my
life
there
there
is
a
way
to
to
recover
that
and
I
figured.
This
group
would
be
happy
with
our
would
be
pleased
to
see
that
as
an
option,
yeah.
B
A
A
A
Certainly
we
could
try
to
fix
a
back
one
of
the
things
that
Mike
you
had
mentioned
from
that
was
do
we
do
we?
Can
we
just
deprecated
a
back,
and
you
know
we
I
send
out
an
email
to
the
mailing
list
asking
for
people's
opinions.
That
sort
of
people
certainly
was
like
it's
fine.
Our
back
is
better
and
we
can
use
Web
books
to
do
anything
else.
A
You
know
it's
just
a
file
passing
the
cube,
API
server
and
there's
no
way
once
the
clusters
running
to
mess
with
it
other
than
changing
the
file
and
restarting
the
cube
API
server.
I
am
Not
sure
that
I
that
I
worry
about
those
distinctions
existing
you
can
always
create
a
cluster
or
binding
today.
If
our
back
is
enabled
to
grant
system,
:
authenticated
and
unauthenticated
any
permission
you
want
and
effectively
bypass
all
authorization
across
all
users.
A
I
do
expect
that
most
clusters
use
our
back
even
if
they
use
a
web
hook
for
more
fancy,
authentication
and
authorization
schemes.
So
I
don't
know
Mike
what
your
feelings
are.
If
you
think
we
should
like.
Obviously
it's
weird
that
we
have
a
beta
feature
that
we
basically
have
no
plan
to
GA,
but
we
probably
should,
if
we
don't
want
to
ever
remove
it
I.
A
A
Like
I
can
kind
of
see
a
stronger
argument
for
saying
that
I
want
an
a
a
auditing
system
that
effectively
can't
be
turned
off
in
the
normal
means.
It
because,
like
I,
always
want
like,
like
baseline
metadata
audit
logs
coming
out
of
the
system
and
I
use
a
dynamic
audit
to
sort
of
pinpoint
more
specific
failures.
A
I'm
trying
to
investigate
I,
don't
necessarily
see
anyone
really
doing
that
with
a
back
I,
don't
know
like
you're
gonna
assign
static
Commission
to
all
your
users
and,
like
just
turn
off
our
back
and
any
webhook,
and
say
that
that's
how
your
permissions
are
done.
I
guess
I
mean
that
might
work
I,
don't
know
how
scalable
or
maintainable.
That
is
an
approach
versus
just
having
our
back.
B
Like
ok,
so
a
little
more
imagination,
you
can
imagine
yourself,
as
maybe
a
cloud
provider
and
for
some
reason
you
want
to
have
a
way
for
a
certain
identity
to
always
have
access,
and
so
you
aren't
dynamically
changing
it.
But
it
is
a
configuration
flag
on
your
queue.
Api
server
that
you
can
set
that
a
user
cannot
remove.
They
can
add
someone
else,
but
I
can't
remove
you
I'm,
not
gonna
clean,
whether
I
think
that
is
a
good
idea
or
a
bad
idea.
But
that
seems
like
a
more
plausible
use
case.
A
A
A
Yeah
yeah,
nobody
knows
right,
like
that's
the
thing.
Nobody,
no
nobody
in
the
mailing
list
said
hey,
please
don't
remove
a
vac.
No
one
has
shown
up
to
this
deprecation
notice,
saying
please
don't
remove
a
back,
but
we
don't
know
cuz.
Obviously
we're
not
gonna
necessarily
reach
the
people
who
care
I.
Think.
E
A
Was
gonna
say
that
as
well,
if
the
supported
deny
it
would
be
more
useful,
so
I
guess
the
the
tos
trail
of
sorrow.
What
is
the
name
of
that
company
trail
abyss?
It's
a
great
eye
trail
of
bits.
The
recommendation
was
that
the
sent
the
a
config
file
was
not
of
a
standard
format,
so
I
mean
we
could
fix
that
we
could
and
then
add,
deny
or
we
can
deprecated
and
remove
this.
F
F
You
know
balancing
that
against
the
time
to
just
bring
it
to
GA.
As
it
is
and
say
it's
GA
is
should
be
Wade
because
it
does
offer
capabilities.
I
kind
of
agree,
though,
with
it's
like
B,
we're,
not
very
good
at
understanding
what
our
user
base
is
using
and
it's
very
hard
to
gather
that
data
like
I'm,
not
aware
of
a
large
set
of
people
using
me
back,
but
I
can
absolutely
buy.
F
A
F
D
A
A
Send
that
out
to
announce
I,
don't
know
if
that's
worthy
of
an
ounce,
probably
not
yeah
all
right
sounds
good.
Send
deprecation,
email
to
kubernetes,
dev
I,
see
if
we
get
any
more
responses,
if
it's
crickets
again,
then
it
might
be,
is
the
right
thing
to
deprecate
it
otherwise
doesn't
seem
like
cotton.
No,
it
doesn't
seem
too
costly
to
bring
to
GA
all
right
next
item
on
the
list.
De
slabs
secret
store
si
si
driver
to
kubernetes
SIG's.
This
would
be
adopted
by
the
sing-off.
A
A
C
Yeah
so
yeah,
as
you
can
see,
I've
opened
an
issue
for
this.
I
really
appreciate
the
feedback
so
far
and
and
I
think
the
next
thing
I
would
like
to
do
is
in
in
that
list
of
to
use
to
get
a
group
consensus
on
my
grading
this.
So
we
can
link
to
approval.
C
So
some
of
the
things
that
I
would
like
to
get
feedback
on
is,
if
you
scroll
up
the
list
of
you,
know
owners
right
now.
These
are
folks
that
are
contributing
to
the
project,
but
I'm
wondering
if-
and
you
know,
if
the
sig
auth
owners
will
want
to
be
part
of
this
as
well
and
obviously
any
other
questions
that
I
can
answer
right
now.
I.
C
A
C
Think
one
of
the
issue
is
that
it's
you
know
days:
it's
not
a
C&C
F
thing
actually
I'm,
not
really
sure,
but
the
other
thing
is
also
just
discovery
to
make
sure
people
can
find
the
project.
Well,.
B
Then
that's
a
really
good
way
to
get
name
recognition
from
queue,
but
I
mean
I,
don't
see
why
we
want
to
trust
Deus
to
continue
doing
the
right
thing.
This
was
built
using
the
extension
mechanisms
that
were
designed
to
be
used
to
build
these
extensions
out
of
tree
I'm
a
little
surprised
to
see
it
collapse
back
in
but
I
mean.
Maybe
if
you
can
find
me,
the
recording
I
can
listen
to
the
old,
recording
and
and
I'm
hearing
the
answers
to
these
questions.
So.
B
I,
don't
see
a
need
if
the
project
is
built
and
it's
working,
fine,
I'm
I,
don't
see
a
need
to
move
it
to
kubernetes
SIG's
like
I'm
I'm.
Looking
at
it
saying,
there's
plenty
of
useful
CSI
drivers
and
useful
extension
features
and
admission
web
hooks
and
other
pieces
that
we
wouldn't
bring
in
I'm,
not
clear
on
what
makes
this
one
important
to
adds
a
sub-project.
A
Yeah
I
think
that
if
we,
if,
if
it
has,
if
it
gains
critical
mass
for
people,
writing
integrations
with
it,
so
it
is
not
a
it
has
a
plug-in
mechanism
such
that
it
can
be
plugged
into
vault
or
as
your
secrets
or
if
AWS
wants
to
write.
One
and
GCP
wants
to
write
one
that
integrates
I,
think
that
there's
value
and
having
a
neutral
place
to
to
write
code
with
shared
ownership.
A
C
A
Integrations
live
separate
from
the
plug-in
system,
so
vault
owns
their
own
integration
at
so
it
there
is.
Some
need
to
make
sure
that
the
interface
that
this
plugin
exposes
to
integrators
is
consistent
and
driven
through
that
API
is
driven
through
a
community
process,
so
I
I
think
there
is
value.
I
guess.
A
A
So
I
want
to
ask
a
bit
more
of
a
meta
question.
What
what?
What
does
the
exactly
mean
to
have
a
cig
project?
That's
owned
like
like,
for
example,
if
there's
a
serious
bug,
is
it
expected
that
someone
from
the
stake
should
as,
for
example,
if
there
was
a
serious
bug
in
the
odd
stack
instead
of
poor
cube,
I
am
sure
someone
in
this
say
go
fix.
It
I
think
that
that
is
basically
the
question
that
Tim
had
been
asking
about.
What
the
responsibilities
of
the
Sagan
is.
C
A
E
E
B
Didn't
seem
the
I'm
trying
to
add
this
mailing,
this
thread
I,
think
I.
Remember
a
mailing
list
thread
and
like
a
PM
responded,
but
not
anyone,
not
anyone
from
this
from
the
sig
I
think
I'd
like
to
see
a
response
like
Mike.
If
you
think
this
should
go
in,
if
you
could
read
response
on
nailing,
let's
thread
and
we
can
talk
it
out
there,
what
it
mean
to
bring
it
in
sort
of
the
conversation
we're
having
here,
why
it's
better
to
bring
it
in
then
let
it
look
where
it
is
it.
A
C
It
definitely
helps
with
the
community
discussion
and
contribution,
because
I
think
one
of
the
issues
that
came
up
was
I
mean
I,
think
the
Hashi
core
vault
provider
needed
to
be
pulled
out.
That
was
one
thing,
but
the
second
thing
was
it
being
in
dais
labs.
It
makes
it
hard
for
people
outside
of
Microsoft
to
contribute
to
I
think
that
was
one
of
the
feedback
yeah.
B
I'd
like
to
understand
that,
because
I
will
say
that
that
at
a
high
level,
I
look
at
this
and
it
looks
like
an
attempt
to
trade
on
our
name
and
I'm,
not
clear
on
on
why
that's
a
good
thing
for
the
sig
I
can
see
being
a
very
good
thing
for
the
project.
It's
not
clear
to
me
why
it's
good
for
the
sig,
so.
B
A
A
H
F
Have
I
also
share
a
lot
of
Jordans
concerns
with
us,
just
to
speak
up,
which
was
I.
Think
all
of
the
things
that
we're
saying
basically,
is
this.
This
makes
the
problem
we
have
around
Secrets
worse
rather
than
better
and
secrets,
are
a
problem
for
a
whole
host
of
on
clusters,
security,
escalation
issues.
So
that's
why
I
like
I
think
Jordan
has
a
couple
of
perspectives.
F
I
think
the
one
that
I'm
most
concerned
of
with
this
is
the
cluster
secrets,
would
implicitly
be
powerful
and
valid,
and
so
that
it
makes
even
more
potentially
power
powerful,
cross
cluster
secrets
available,
which
feels
like
the
wrong
pattern.
We
should
make
a
pattern
that
makes
it
easy
for
only
this.
Only
the
consumers.
You
want
to
get
access
to
the
secret,
which
would
be
valuable
for
regular
secrets
as
well.
A
A
A
Secrets
are
handled
differently
than
config
as
far
as
encryption
and
for
a
while,
as
far
as
how
the
cube
cube
latest
author,
or
still
how
the
cube
load
is
authorized
to
pull
them
and
cache
them
so
that
they're
not
they're,
not
just
semantically
different
they're,
not
just
name
different,
they
actually
have
different
handling
within
the
system.
I
think
those
are
my
main
concerns.
B
You
mean
other
than
the
usage
today,
where
you
can
place
them
in
a
node,
keyring
and
specific
nodes
or
different
subsets
of
nodes
that
you
could
choose
based
on
the
scheduling.
Namespace
labels
for
nodes
would
then
just
have
them
there,
so
you
could
then
subdivide
based
on
namespace
and
never
expose
the
credentials
to
the
cluster.
I
So
with
that,
that
would
require
you
to
have
access
to
the
node
configuration
or
I'm
not
familiar
with
that
pattern.
Yeah
would
where
we're
trying
to
create
a
product
on
top
of
kubernetes,
where
we
wouldn't
have
access
to
the
creation
of
the
cluster
itself
like
if
it
was
in
gke
or
e
KS
or
something,
but
we
would
need
to
be
able
to
pull
containers
from
private
registries
for
that
cluster.
A
I
F
We
have
discussed
a
number
of
approaches
for
it,
I
think
as
we're
starting
to
grow.
The
flexibility
of
CSI
local
volume
amounts
there's
some
arguments,
maybe
that
this
is
also
something
that
could
be
managed.
They
were
required.
Cubelet
changes
as
well.
It's
not
enough
for
us
to
go.
Do
cluster
secrets
and
I.
Don't
think
that
has
a
the
cluster
secrets
wouldn't
help
because
we
still
have
to
go.
A
F
Yeah,
because,
like
adding
image
poll
secrets,
is
even
more
complex
than
cluster
secret,
so
this
is
really
cluster
secret
for
poles,
which
is
maybe
distinct
from
cluster
secret
for
and
honestly
like
if
we
were
scope,
this
down,
for
instance,
to
pull
secrets
only.
That
might
be
something
we
could
consider.
For
instance,.
F
A
H
F
This
is
Clayton,
I
mean
like
I
think
this
is
something
that
we've
also
wanted
to
see
happen
for
a
long
time
in
68,
81,
oh
and
I,
think
there's
an
appetite
for
this.
It's
just
it.
We
have
to
be
somewhat
cautious
about
it.
We've
never
really
been
able
to
get
critical
mass
of
brains
plus
use
case
plus
scoped
down
enough
that
it
didn't
feel
risky,
and
so
that's
one
of
the
that's
one
of
the
challenges
with
this
kind
of
work.