►
From YouTube: Kubernetes SIG Auth 2019-12-11
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 2019-12-11
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
B
So
we've
been
talking
about
various
pieces
of
functionality
required
to
move
the
CSR
API
to
your
smooth,
going
absolutely
nuts
to
to
GA
on
that
list.
There
are
multiple
items,
but
one
of
them
was
being
able
to
multiple
different
centers
I
went
through
and
described
a
kept.
How
you
could
do
this
using
our
existing
API
in
the
backward
compatible
way
and
identified
the
different,
logical
signers
that
we
already
have
today
Oh.
B
Logically,
there
is
a
signer
needed
to
sign
culet,
servings
or
tickets
so
that
the
queue
API
server
can
trusts.
The
look
at
the
other
end
of
certain
kinds
of
connections
like
logs,
there's
a
need
to
and
there's
a
need
to
be
able
to
sign
client
certificates
that
are
good
against
the
queue
API
server.
B
There's
a
subcategory
of
that
which
can
automatically
approved
by
the
queue
controller
manager
for
cubelet
client
certificates.
I've
enumerated
the
different
cases
here
then
there's
a
category
of
we
don't
really
know
what
it
is
anything
today
that
someone
marked
approved
was
signed
by
the
cute
controller
manager.
Signer
is
that's
an
unknown
all
right,
so
I
described
in
the
update
to
the
cab,
how
we
can
transition
to
this
changes
to
defaults.
A
B
Hadn't
I
guess
I
might
have
passed
over
that
and
the
noise.
You
were
thinking
that
you
would
have
a
special
permission
to
allow
someone
to
sign
for
say
a
jet-set
signer
yeah
hae-sun
name
yeah
I'm,
fine
with
that
that
would
be
something
fairly
easy
to
do.
I
would
probably
want
to
do
it
as
an
admission
plugin,
so
it
could
be
turned
on
and
off.
Mm-Hmm
is
that
something
you'd
want
to
see
instead
in
the
strategy
for
the
resource,
I
can
never
be
turned
off.
I
think.
A
A
B
A
A
It's
a
good
point:
I
think
the
jet
stack
example
versus
the
cubelet
CA
example.
As
you
get
it
there's
a
good
one.
I
want
to
have
deployed
the
jet
stack
as
our
stack
into
my
cluster,
but
I
don't
want
the
de
sac
CSR
stack
to
be
able
to
approve
giggling
credentials
or
no
credentials.
I
I
could
go
either
way,
whether
that's
a
field
and
the
approval
approval
condition.
B
A
D
B
Only
planning
the
beta
changes
we're
only
playing
there
is
no
v1.
Yet
it's
just
that
I
know
as
we
move
forward.
I'm
gonna
want
to
have
fields
that
used
to
be
optional,
become
required
and
remove
any
defaulting,
and
we
have
experience
doing
this
with
series
and
I
think
the
transition
there
and
with
admission
Web
books
was
valuable.
C
B
C
B
C
D
D
C
C
C
A
C
C
A
A
G
G
The
reason
you
can't
rely
on
that
alone
is
because
connections
can
be
very
long-lived
and
if
it
expires,
while
the
connections
open,
that's
problem,
so
I
guess
you
know
like
I,
wanted
to
hear.
If
there
are
any
other
opinions
about
work
and
yeah
talk
about
how
it
fits
you,
and
maybe
with
the
Cooper
stuff,
does.
G
A
C
G
B
B
B
C
A
F
G
C
C
G
Could
we
could
just
completely
remove
the
like
the
connection
stuff?
Well,
it's
completely
like
that.
Only
advantage
of
that
is
it
I
mean
there's
not
much
advantage
of
it.
To
be
honest
with
you,
we
could
just
remove
that
burden.
I
don't
know
I
do.
Are
we
aware
of
any
cases
100
connections
with
used
to
me,
like
there's
a
connection
pool
in
the
client
for
like
API
server
connections,
and
it
tends
to
just
keep
them
open,
maybe
in
like
a
failure.
G
A
A
G
Great,
that's
we'll
have
to
save
them.
Oh
the
other.
Any
other
thing
is.
We
can
probably
reflect
the
Kubler
stop
to
just
work
based
off
of
this,
so
Kubler
handles
his
own
connection
rotations
right
now.
We
could
just
instead
tell
the
couplet
rotation
stuff
just
write
to
disk
and
let
this
do
the
rest.
Oh
yeah.
That
sounds
like
a.
A
B
C
I
D
J
A
J
F
I
I
If
there
is
any
way
we
can
maybe
steer
developers
to
not
rely
on
this
pattern
and
use
different
api's
for
getting
their
secrets
and
it's
kind
of
difficult
right,
because
this
is
kind
of
a
nice
general
way
of
exposing
secrets
without
application
code
having
to
call
into
a
specific
API.
But
on
the
other
hand,
that's
basically
exactly
the
problem.
That's
that
they're
not
doing
that.
A
What
I
would
like
to
do
is
to
have
an
option
for
secrets
meds
where
cubelet
encrypts
the
secret
and
then
stores
the
encryption
key
in
an
X
adder
extended
attribute
for
the
file,
and
that
way
the
consumer
of
the
seco
would
have
to
read.
It
read
the
extended
attribute
which
are
not
usually
available
from
director
traversals
and
unencrypted
file.
A
I
Think
either
one
of
these.
What
would
address
this
problem
because
it
would
basically
require
that
an
application
that
wants
to
access
this
secret
has
to
use
some
kind
of
special
piece
of
code
that
typically
wouldn't
be
in
the
code
path
of
something
that
that
is
usually
vulnerable
to
to
directory
traversal
I
mean
it's
possible
that
somebody
will
basically
write
a
library
wrapper
and
then
it
close
that
to
untrusted
input.
I
But
it
seems
like
that
these
are
things
that
an
application
will
typically
read
at
startup
and
that's
a
difference
tends
to
be
a
different
code
path
from
from
code
path
that
accessing
files
later
on,
based
on
external
write.
So,
for
instance,
they
might
have
like
it
might
have
an
application
that
reads
like
a
language
specific.
I
It
looks
that
up
based
on
from
a
local
file
based
on
a
parameter
that
indicates
a
language
and
if
they
make
a
mistake,
when
they
build
that
file
path
and
don't
sanitize
that
parameter,
they
might
be
walkable
to
directory
traversal.
But
that's
something
that
layer
in
I
mean
that
happens
at
runtime
right,
and
so
hopefully
they
wouldn't
be
using
the
same
library
wrapper
that
lets
them
read
encrypted
secrets.
Right,
I
mean.
I
A
I
Mean
another
way
of
doing
it,
I
mean
do
they
all
kind
of
you
know
things
that
won't
reliably
prevent
exploitation
or
prevent
mistakes,
but
they
sort
of
go
a
reasonable
way
towards
that
right.
I
mean
one
other
way.
That
might
work
is
that
you
have
a
mechanism
where
the
secret
files
are
read
once
or
something,
or
they
can
only
be
read
until
the
application
signals
that
is
ready
or
something
like
that,
because,
typically,
these
need
to
be
read
at
startup
or.
D
I
Could
have
like
a
read
ones,
file
that
contains
the
key
that
then
allows
you
to
decrypt
everything
else
right,
so
you
might
have
a
thing
that
you
might
have
one
one
particular
file
name.
That's
the
application
has
to
basically
read
first
thing
and
can
be
read
only
once
that
contains
the
key
there.
Encrypts
I
was,
but
that
might
work
as
well
might
be
more
I
know.
F
I
I'm,
not
you
know,
I,
probably
not
the
right
person
to
suggest
implementations
because
I
don't
really
know
the
underlying
machinery
very
well.
But
although
these
things
are
seem
kind
of
roughly
equivalent
right
in
the
sense
that
the
main
goal
is
to
make
it
to
that
normal
file,
read,
that's
might
be
subject
to
directory
traversal
can't
can't
access
those
files,
and
you
have
to
do
something
special
too
yeah.
C
I
need
to
be
fair,
the
a
lot
of
the
motivation
behind
this
method
of
providing
secret
data
to
applications.
This
way
is
because
a
lot
of
them
aren't
easily
adapted
to
using
something
custom
like
some
custom
code
or
something
so
there's
a
pretty
large
category
of
applications
for
which
improvements
here
like
read
an
X,
adder
or
call
with
an
extra
library
wouldn't
actually
be
usable,
yeah.
I
Mean
I
think
this
is
not
really
making
a
current
situation
worse
right,
because
it's
it's
somewhat
common
pattern
to
have
secrets
in
configuration
files
right
like
for
a
full
web
servers,
it's
common
to
put
database
passwords
in
there
or
like
the
exercise,
encryption
key
or
assigning
key
and
stuff
like
that.
But
you
know
at
least
providing
like
a
better
way
of
doing.
This.
F
I
think
if
we
one
way
if
this
comes
up
in
our
applications,
a
lot
like
you
said
about
applications
that
aren't
ready
to
consume
this
stuff
right
now,
you
can
only
do
the
get
environment
variables
out
of
config
maps
and
secrets.
You
can't
you
can't
get
environment
variables,
plucked
out
and
say
arbitrary
volume
is
melted,
and
but
if
you
could
and
we
it
would
allow
us
to
do
more
things
like
fetch
that
data
in
memory
and
hand
it
back
to
the
couplet.
A
A
A
F
Right,
alright,
so
yeah
in
that
way,
and
you
can
also
then,
if
you
get
in
the
environment,
you
can
jam
it
into
the
command
line
flags,
so
in
other
words,
applications
can
be
written.
Saying,
I,
don't
know
where
this
data
comes
from,
but
I
think
I
think
I
want
to
hear
you're
arguing
for
is
they
really
should
be
written
in
a
way
that
says
hand
me
a
config
file
and
I'll
read
it.
Yes,.
A
D
I'm
trying
to
understand
what
we
can
do
here
right
because,
like
the
whole,
like
reading
environment
variables,
are
reading,
files
off
of
disk
as
Jordan
said,
basically
exists
to
meet
applications
where
they
exist
today,
if
you're
willing
to
change
your
application
right,
like
you,
could
just
no
use
alt
or
whatever
and
make
an
API
call
your
secret
I
know
is
it's
I
think
it's
somewhere
in
the
agenda
for
the
whole
CSI
drivers,
though
yeah
next
yeah,
but
if
you,
if
you
had
a
flow
where
you
can
use
your
you
know,
like
your
token
request,
bound
service
account
token
to
sort
of
these
chapters
identity
and
then
have
some
external
system
authorize.
D
A
Yeah,
so
I
don't
think
we
can
change
defaults,
I,
agree
with
you,
I,
don't
think
we
can
remove
any
of
the
less
than
ideal
ways.
Plumbing
secrets,
however,
I
think
there
is
our
ways
that
we
could
improve
secrets
that
would
benefit
core
kubernetes
components
and
then
I
guess,
and
then
they
would
go
on
to
benefit
people
in
running
on
kubernetes,
who
had
the
flexibility
to
update
code
and
yeah
modify
cut
to
consume
secrets
from
a
different
Oh
was
a
different
mechanism.
Yeah.
C
D
C
C
I
One
other
question
that
sort
of
relates
to
that
is
to
what
extent
there
are
mechanisms
that
allow
like
a
security
review
or
auditor,
or
you
know,
security
organization
to
ensure
that
these
best
practices
are
actually
followed.
Right,
so
is
there?
Is
there
a
way
to
say
I
mean
it
would
be
kind
of
nice
to
have
a
way
to
say
either
at
a
cluster
level
or
some
kind
of
top
level
that
you
know
this
best
practice
is
say
all
the
secrets
secret
mounted
here.
A
A
C
C
A
C
C
C
A
A
I
F
I
am
I've
spent
time
over
the
last
couple
of
days
implementing
the
groveling
around
here
that
that's
mentioned,
where
I've
got
to
see
a
sign
driver
that
I
suppose
path
melts
and
when
it
gets
a
volume,
publish
request.
Sorry
I
know
to
publish
request
for
a
pod.
It
goes
out
and
does
one
of
two
things.
F
If
you
pass
it
a
context
value
where
you
you
give
it
a
mount
name,
you
know
you
sell
it
use
this
projected
service,
a
tell
account
to
can
mount
it
goes
and
it
tries
to
read
a
token
out
of
the
melt
path
that
it
can
Cox.
Otherwise,
if
you
don't
give
it
that
hint,
it
tries
to
figure
out
if
you've
got
the
default.
Token
Auto
mounted
goes
and
reads
the
pod
and
reads
the
service
account
to
figure
out.
F
A
F
F
It
yeah
it's,
you
know,
a
lot
of
people
have
not
even
tried
using
the
the
projected
tokens,
but
that's
something
we'll
certainly
put
for,
because
we
can
send
an
audience
value
on
them
and
configure
vault
to
only
accept
tokens
with
that
audience.
But
you
know
as
a
way
of
accepting
people
where
they
are
today.
We
have
a
lot
of
people
just
using
normal
service
account
tokens
yeah.
C
But
this
issue
and
Porco's
for
wanting
to
make
that
sort
of
handoff
of
an
API
credential
part
of
an
API
or
part
of
something
that
the
kubernetes
components
of
the
CSI
explicitly
did
for
you,
and
so
that
that
seems
a
step
beyond
like.
We
gave
you
an
API
token
and
if
you
want
to
send
it
to
vault,
like
that's,
not
a
great
idea,
but
you
and
that's
different
than
we
will
give
you
an
API
field.
That
will.
C
E
F
Would
expect
that
it
would
be
some
sort
of
flag
like
I
I'm,
one
of
those
volume
context
flags,
because
the
pot
author
I'm
talking
about
for
a
federal,
CSI
volumes
here.
So
the
pot
author
melts
the
CSI
volume
nominates
the
driver
and
it
also
pass
flags
through
a
map
of
string
to
string.
So
if
there
was
some
sort
of
flag,
like
you
know,
publish
published
opium
to
driver
or
whatever
and
even
nominate
one
of
the
mounted
two
Akins.
C
F
F
Besides
my
driver
to
do
you
know
to
be
able
to
hand
that,
to
my
driver
to
say
the
pod
author
offered
to
you
this
token,
you
know
and
then
I
would
be
able
to
just
get
the
token
bytes
rather
than
needing
to
go.
Read
those
files
off
of
disk
kind
of
snooping
around
the
back
of
where
volumes
are
melted
on
the
file
system.
H
H
H
With
the
current
mechanisms,
there's
not
a
way
to
say
like
that,
this
drive
you
would
have
to
grant
access
to
the
driver
to
get
any
service
count.
Token
essential
seed,
one
some
sort
of
proxy
in
there
that
says
you
know
you
can
only
get
tokens
for
pods
on
the
same
node
that
are
actually
using
this
volume.
F
D
And
I
think
that's
the
primary
use
case
right.
You
have
one
path.
So
as
long
as
that
path
is
protected,
you
don't
have
to
build.
A
separate
path
then
has
to
go
and
right,
like
I,
could
imagine
another
admission
plug-in
that
says.
Oh,
this
is
a
CSI
driver
using
a
token
request.
So
let
me
make
sure
that
it's
allowed
to
do
this
particular
instance
of
turbine
process.
A
I
can't
tell
if
you
guys
can
hear
me
now
again
awesome
all
right.
Sorry
about
the
background.
Noise
I
searched
Mike's.
What
do
you
think
about
house
specifying
this
at
teach
like
driver
level?
I?
Think
there's
a
like
a
global
driver
object
say:
the
vault
driver
needs
tokens
for
vault,
that's
configured
once
the
when
the
driver
is
installed
in
the
cluster
and
the
CSI
volume
specs
remain
basically
the
same
yeah.
D
I
think
the
only
negative
of
that
is
there's
not
even
a
negative.
It
might
be
weird
for
a
person
making
a
pod
that
then
uses
a
CSI
volume
to
like
give
a
token
to
that
CSI
driver,
and
maybe
it's
okay
like
if
it's
audience
scoped
and
maybe
there's
controls
on
the
actual
audience.
So
instead
of
requesting
a
particular
audience
you're
requesting
like
a
postfix
and
like
the
API
server
will
always
or
sorry
the
cube
will
always
look
like
a
prefix
that
sort
of
guarantees
that
you
can
take
an
audience.
That's
good,
yeah,.
A
A
A
D
D
C
C
A
F
H
Between
the
few
times
is
to
just
mount
the
cubelets
credentials
into
the
CSI
driver,
it's
not
great.
It's
we're
probably
going
to
break
someone
at
some
point.
When
we
scope
down,
we
look
permissions,
but
yeah.
We
had
a
proposal
earlier
in
the
year
for
kind
of
we
call
it
nude
scope,
daemon
sets
and
where
that
left
off
was
just
kind
of
used,
the
cubelet
credentials.
H
F
D
Okay
right,
so
the
cubelet
is
authorized
to
make
token
requests
for
all
service
accounts
that
are
currently
scheduled
on
it.
Based
on
positive
okay,
we
make
a
token
request
for
the
actual
service
account.
I
don't
know
if
you
know
that,
but
let's
pretend
that
you
do.
If
you
know
the
service
account
that
you'll
be
able
to
go
ahead
and
make
a
token
request
with
a
specific
audience
and
use
that
directly
I
think.