►
From YouTube: Kubernetes SIG Auth 20190123
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20190123
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
A
A
A
B
C
B
So
yeah,
so
this
solution
is
only
to
address.
You
know
as
a
developer,
if
I
already
have
a
solution
for
all
my
application
secrets
and
we'll
like
kubernetes,
to
be
able
to
use
the
same
source
of
truth
for
those
secrets.
How
would
I
do
that
and
let's
say
you
also
want
to
avoid
manually,
creating
secrets
and
updating
certificates
to
your
kubernetes
cluster?
How
would
you
do
that?
B
So
so
this
demo
is
to
introduce
the
secret
store,
CSI
driver-
and
this
is
actually
you
know,
a
a
sibling
of
this
flex
volume
which
pretty
much
does
the
same
thing,
but
it's
a
predecessor
of
the
CSI
driver
and
we
decided
to
write
a
si
driver
since
it's
the
new,
the
next-gen
device
driver,
so
so
yeah
so
quickly.
I
would
like
to
show
a
demo
of
what
the
end
user
experiences
so
now.
B
I
have
a
cluster
like
what
three
with
two
Asian
notes,
and
so
basically
we
have
a
home
chart
specifically
created
for
this
and
I've
already
pre-installed
the
home
chart
and
what
the
user
will
have
to
do
is
basically
deploy
these
few
things.
So
first
it
would
have
to
create
like
a
a
PVC
that
looks
something
I'm.
Sorry
like
this.
B
Then
you
would
basically
do
something
like
this
and
then
that's
then
the
secret
that
is
stored
in
your
key
vault
will
basically
be
mounted
to
the
pod
as
a
volume,
and
then
you
can
actually
read
the
value
out
and
then
expose
it
as
an
environment
variable
or,
however,
your
application
needs
to
use
it
so
yeah.
So
that's
pretty
much
the
demo
and
then,
as
far
as
like
first
maybe
questions
does
anyone
have
any
questions.
I.
E
So
when
we
went
around
the
first
round
of
this
discussion,
we
asked
six
storage
to
make
sure
that
local
CSI
drivers
that
don't
require
you
to
hook
into
the
global
attached
PB
mechanism
would
be
functional.
How
much
of
the
design
that
you
have
depends
all
on
PBS
like
in
terms
of
having
some
global
object,
that's
shared
across
nodes
versus
could
be
implemented
or
should
be
implemented
if
there
was
a
local
C,
SCSI
provider.
Okay,.
E
B
So
currently
the
solution
is,
is
the
driver
is
deployed
on
every
single
node
and
the
reason
for
that
is
when
the
pot
is
deployed.
It
basically
needs
to
attach
like
a
local
volume.
So
it's
kind
of
the
same
way
as
like,
like
kubernetes
secrets,
work
like
where
you
would
have
to
mount
mount
the
the
content
as
if
it's
a
it's
a
volume,
but
it's
on
the
node
itself.
Ii
sees
it
as
a
as
a
local
file
system.
E
B
D
E
B
B
Yeah,
that
would
be
great
I
would
love
to
not
have
to
create,
like
TVs
and
PVCs,
but
yeah
to
your
point
for
the
Flex
volume.
This
is
what
looks
like
so
from
my
end-user
perspective.
The
Flex
vol.1
is
actually
much
easier.
Is
to
your
point.
You
just
define
it
in
your
pot
demo
and
it
just
works,
whereas
for
the
CSA
driver
you
will
have
to
you
like
someone
will
have
to
go
and
create
the
Peavey's
and
PVCs,
for
you
know,
for
anybody
who
wants
to
use
the
secret.
F
B
Is
am
I
seeing
this
right
hold
on
you,
it's
Mishra
on
the
call
yeah,
oh
yeah
I.
Think
you
want
to
talk
about
the
Hoshi
Corp
one.
D
I'm,
a
seeker
I've
been
working
with
Vita
on
kind
of
an
initial
version
for
supporting
Hachiko
quad,
as
basically
exposing
the
key
value
store
into
into
the
quad
as
well
very
similar
to
what
she
has
for.
Asher
are
currently
like
we're
just
like
doing
some
initial
kind
of
rounds
of
understanding
like
what
exactly
needs
to
be
done
to
make
sure
like
we
do
it
properly
in
terms
of
the
the
chicken
neck
problem.
D
That's
like
how
do
you
ask
against
well,
which
we
already
have
a
kubernetes
kind
of
path
mechanism,
but
is
that
appropriate
for
this,
this
kind
of
project,
and
so
on?
So
it's
still
kind
of
initial.
You
know
kind
of
groundwork.
There
sharing
some
notes
for
Drita,
and
then
hopefully
we
have
an
initial
version.
It
supports
just
the
key
and
the
key
value
stores
have
bought.
G
Why
might
a
question
is
just
in
general?
What
are
the
ways
that
we
want
to
support
for
secrets
going
forward?
I,
think
one
thing
that
communities
does
poorly
is
provide
a
recommended
path
for
users
and
providing
with
lots
of
different
options.
It's
great,
but
I
think
that
just
confuses
especially
a
lot
of
our
new
users.
B
And,
and
also
my
question
for
also
for
the
grouper
would
be
you
know,
some
of
the
comments
I
came
back
were
how
does
this
work
with
like
environment
variables?
What's
our
like
recommendation
right
like
if,
if
someone
wants
to
use
that,
and
how
would
this
be?
Actually
how
does
it
actually
work
with
environment
variables?
B
So
that's
one
question
the
second
one
would
be
like:
how
does
someone
update
the
secrets
so
once
in
volume
is
mounted
it
no
longer,
you
know
it's,
you
can't
change
it
unless
you
have
like
a
sidecar
that
watches
and
maybe
trigger
some
update
or
something.
So
those
are
things
that
came
out
of
users,
so
so
flex
volume
has
been
out
there.
You
know
for
a
few
months
now,
so
we
got
a
few
discussion
issues
out
there.
So
those
two
are
the
like
sort
of
the
big
ones
for
environment.
F
Variables,
in
particular,
even
the
existing
ability
to
take
secret,
like
kubernetes,
secret,
key
values
and
put
them
into
environment
variables,
is
not
really
the
most
recommended
thing.
Environment
variables
show
up
in
the
container
manifests
that
are
passed
to
CRI,
and
so
they
tend
to
get
logged.
They
tend
to
get
echoed
they're
a
lot
easier
to
extract
from
inside
the
container,
and
so
insertion
as
files
is
definitely
recommended.
F
B
So
I
think
those
are
the
you
know,
sort
of
the
recommended
path
for
people.
You
know,
even
if
we're
saying
no,
we
we
we
have
to
give
them
like
hey
here's.
What
you
should
be
doing
right
and-
and
just
if
you
guys
want
to
like
chime
into
this
issue,
would
be
awesome,
considering
it's
more
coming
from
the
community
right.
B
But
here,
as
you
can
see,
like
a
lot
of
people
are
asking
mainly
because
that's
sort
of
like
the
pattern,
like
the
12
factor,
application
pattern,
it's
always
using
the
environment
variable
and
also
a
lot
of
the
deployments
that
we
have
today.
Like
say
you
know,
sto
or,
like
anything,
that's
pretty
major
that
we
use
today
they
all
use
environment
variables.
So
so
that's
sort
of
like
the
blocker.
E
B
E
Think
you
know
with
there
was
someone
discussed
this
a
few
years
ago
about
a
an
environment
variable
projection
that
would
project
from
inside
the
container
image
or
the
file
system,
and
it
was
such
a
weird
use
case
that
at
the
time
we
kind
of
said
no
and
I,
don't
know
that
we
would
go
back
to
like
reading
from
the
file
system
to
put
into
the
environment
on
container
start
up
gets
into
a
really
weird
world.
So
I'd
say
it's
on.
E
It
seems
unlikely
that
we
would
ever
add
that
as
an
official
plug-in
to
kubernetes,
at
which
point
you're
looking
at
either.
You
know
something
at
a
lower
level
which
isn't
going
to
be
consistent
across
platforms,
so
it
may
kind
of
be.
This
is
the
best
that
it
could
ever
be.
I
know
that
there
was
some
discussion
like
sidecars
and
making
it
easier
for
people
to
wrap
processes
that
has
kind
of
languished
like
this
kind
of
shell
script.
Wrapping
there's
other
kinds
of
wrapping
that
people
are
doing
today
to
reload
config
variables.
You
know.
E
Certainly,
most
microservices
frameworks
are
using
something
like
proc
man
or
you
know
some
of
those
user
level
process
managers
that
actually
do
some
of
this.
So
there
is
something
that
could
be
said
for,
for
the
people
who
are
using
Microsoft
doesn't
have
a
pattern.
They
should
institute
a
pattern
that
you
know
handles
this
outside
of
the
apse
anyway,
like
kubernetes
was
not
designed
necessarily
for
the
pod
spec
to
solve
all
micro-services
use
cases.
B
F
F
G
B
Yeah,
that's
good
conformation,
because
we're
kind
of
supporting
both
at
the
moment,
so
it
would
be
nice
to
consolidate
efforts,
okay
and
then,
as
far
as
like
providers,
you
know
I
think
in
the
future
we
will
have
as
your
cable
provider
and
Hoshi
core
vault
provider.
Are
there
other
providers
that
you
think
would
be
a
good
idea
to
be
added
to
the
list.
A
F
A
A
G
A
F
F
The
content
of
runtime
interface
has
a
way
to
plumb
this
information
through,
but
there's
nothing
in
the
API
or
the
cubelet
that
oh
I
was
plumbing
this
through,
and
so
this
is
a
proposal
to,
as
a
first
step,
build
an
extension
that
lets
you
kind
of
have
these
credential
specs,
which
is
this
JSON
blob
that
describe
your
service,
account
in
a
custom
resource
and
have
a
web
condition.
Plugin
that
takes
a
symbolic
name.
You
say:
I
want
to
run
as
the
group
managed
service
account
and
they
mission
plugins.
F
Some
of
those
things
are
already
in
the
container
runtime
interface,
but
trying
to
kind
of
understand,
like
we
have
Linux
specific
things
already
like
you,
aid
in
group
ID
and
just
try
to
have
an
eye
towards
how
would
that
be
shaped,
as
we
have
different
stanzas
that
only
apply
to
a
particular
my
braking
system,
so
I
think
there's
a
pretty
reasonable
first
step
for
concept
and
then
some
open
questions
for
what
it
would
look
like
kind
of
being
brought
into
a
more
official
API.
Once
it's
proved
up.
A
F
So
we've
got
this
cap
here,
it's
gonna
speak
to
you
provide
a
way
of
web
books.
Skewing
outgoing
from
the
API
server
provide
a
way
of
authenticating
em
I,
specifically
I
did
the
dynamic
auditing
word.
If
you
have
something
you
know
running
on
a
cluster
you're,
sending
audit
events
to
proxy
I,
how
does
that
proxy
now
authenticate
the
API
server
to
make
sure
there
aren't?
You
know
false
events
getting
thrown
into
the
stream
or
something
like
that
so
I
Jordan
did
a
little
talk
on
this
at
the
last
cube
con.
F
He
laid
out
the
space
pretty
well
I.
I.
Think
that's
come
in
the
comments
here.
If
anyone
wants
to
look
at
it
there,
but
there
are
a
couple
challenges
kind
of
faced
as
you
try
and
do
this
soon.
These
proposals
just
intended
for
kind
of
cluster
aware
web
hooks
I
and
the
idea
is
we
would
provide
a
mechanism
I
expose
it
through
the
API.
That
would
basically
say
I
didn't
add
a
token
to
each
response
as
its
outgoing
and
then
that
token
can
be
checked
back
through
the
API
server
I
using
the
auth
token
API.
F
This
is
kind
of
a
simple
way
of
doing
it.
We'll
see
kind
of
a
bigger
one
here
at
some
point
would
be.
How
do
we,
you
know,
do
secret,
based
authentication
and
actually
be
able
to
provide
secrets?
We
ran
the
issue
there
for
aggregates
running
in
different
namespaces.
How
do
you
differentiate
across
them?
How
do
you
share
secret
cross
namespaces?
How
do
you
provide
authorization
to
do
that?
So
there
are
a
lot
of
issues
that
kind
of
did
our
analysis.
I
I
So
the
file
that
you
use
to
indicate
what
should
be
submitted
is
actually
done
as
a
file
on
disk,
so
you
can
use
a
secret
mount
again
if
you
wish
to
okay,
not
reread
so
it's
not
reread
I
mean
like
I,
could
certainly
see
room
for
improvement.
I
could
see
the
idea
of
getting
a
particular
token
with
the
right
audience
would
be
valuable,
but
that
kind
of
mechanism.
Why
is
this
one
different
I.
F
G
F
Was
kind
of
the
minimum
thing
that
could
work
I
think
separating
the
authentication.
The
description
of
how
you
authenticate
from
a
web
book
to
a
web
hook
from
the
actual
registration
of
the
web
book
is
not
great.
It
makes
it
really
hard
to
look
at
a
configuration
and
understand
what
what
is
going
on.
So
you
say:
I've
got
to
this
web
of
registered.
Are
people
authenticating
to
it?
Are
they
not?
How
are
they
authenticating
to
it?
I
F
I
Keep
those
coherent
the
other
thing
is
that
I
also
see
a
need
to
be
able
to
provide
tokens
or
client
sorts
that
for
web
hooks.
That
are
not
cluster
aware
right,
because
the
whole
point
of
me
having
what
book
is
that
I
can
choose
whether
I'm
gonna
run
it
as
something
cluster
aware
or
plug
into
some
other
system.
F
I
Not
prescriptive
for
how
you
actually
do
it
simple
as
cases
to
create
four
different
secrets
and
and
mount
them,
but
I
I
think
I
need
both
I
think
having
something
cluster
aware
that
does
this,
that
can
wire
it
up
automatically
with
you
know,
restricted
audience.
This
is
really
useful.
I
also
need
the
ability
to
just
say
like
this
is
the
one
when
you
talk
to
this
Web
book.
Use
this
token,
because
my
IT
department
made
it
right.
F
I
Think
that
the
design
needs
to
tolerate
I
want
to
be
able
to
see
something
overall,
they
can
that
can
functionally
do
both
there.
We
go
okay,
okay,
let
me
think
I
guess,
even
if
it
were
like,
and
you
either
do
this
or
you
do
that
it's
it's
just
that
we
already
have
web
hooks
today,
they're
already
handling
some
of
these
cases.
I
want
to
be
sure
when
you
add
the
next
one
that
we
don't
just
end
up
with
the
11th
standard
right
sure,
yeah.
F
A
C
Unseen,
you
can
scrub
out
basically
I'm
gonna,
be
really
quick,
because
I
want
you
guys
to
have
as
much
time
to
discuss
what
you're
actually
gonna
work
on
and
114
as
possible.
My
name
is
Mike
I'm
on
the
release
team
on
the
loose
and
clicking
burger
is
the
really
sweet
of
you
are
probably
familiar
with
there.
Basically,
there
are
two
things
that
we're
doing
different
this
release,
and
you
know
between
the
release,
lead
group
and
the
release
enhancements.
C
Lead
group
were
kind
of
talking
to
as
many
SIG's
as
possible,
making
sure
that
everyone
understands
the
timeline
and
the
new
implications
of
some
of
the
changes.
So
basically,
the
first
thing
that
we're
doing
differently
in
1:14
is
that
there's
no
code
slush
code
slush
historically
has
been
one
week
before
code.
Freeze,
nobody
really
used
it
for
anything
other
than
like
a
two-minute
warning
that
code
freeze
is
coming
so
that
so,
if
you
were
relying
on
that,
you
know
keep
that
in
mind
and
then
the
other
more
significant
thing.
C
That's
changing
for
114
is
that
all
proposed
enhancements
must
have
a
cap,
and
you
know
we
can
talk
more
and
talk
more
about
what
what
a
cap
is
or
what
an
enhancement
is
what
enhancements
require
a
cap
and
what
happened?
What
should
be
in
a
cap?
And
what
have
you,
if
any
of
you
aren't
familiar
happy
to
talk
about
that
offline?
But,
basically,
you
know
the
release.
C
Schedule
for
114
has
the
enhancements,
freeze,
On,
January
29th,
which
is
six
days
from
now,
and
basically
the
enhancements
freeze
is
saying
that
if
you're
going
to
work
on
enhancements
in
140
and
ship
them
to
some
degree,
that
enhancement
must
must
have
a
cat
that
submitted
reviewed,
landed
and
trapped
in
the
114
milestone
by
Tuesday.
So
it's
possible
for
a
lot
of
old
enhancements
that
don't
have
cats
yet
really
the
most
important
thing
about
the
cat
that
needs
to
be
articulated
is
the
graduation
criteria
and
testing
of
the
future.
C
If
you
need
help
with
this,
if
you're,
like
wow
I,
have
a
bunch
of
enhancements
that
I'm
working
on
that
are
just
about
to
go,
GA
or
they're
just
about
to
go
beta
and
I
have
never
written
kept
for
them
or
something
feel
free
to
hit
up
me.
My
paya
in
a
sig
release
or
been
the
elder
who's.
The
other
release
lead
shadow
or
see
Lawrence
Clare,
Lawrence
who's,
the
enhancements
lead
for
114.
F
C
F
C
Sure
I
mean
as
long
as
it's
merged,
and/or
I,
don't
as
long
as
as
long
as
it's
being
tracked
in
the
114,
milestone
by
Tuesday
I.
Think,
that's
generally
the
most
important
factor,
because
you
know
you
can
continue
to
work
on
articulating
what
the
enhancement
is
the
cap
and
stuff
throughout
the
release,
as
that
becomes
more
clear
during
implementation.
But
really
we
just
want
to
make
sure
that
you
have
the
graduation
criteria
and
your
dashboard
set
up.
C
You
know
how
you're
going
to
test
this
thing,
and
you
know
what,
like
the
decision
you're
going
to
make
when
it
comes
time
to
like
flip,
a
switch
or
ship
this
for
114
or
not,
and
you
know
what
your
understanding
of
the
enhancement
itself
could
change
over
the
release.
But
as
long
as
your
graduation
criteria
is
consistent,
that's
what
the
release
team
is
really
worried
about
and
if
I
understand
correctly,
there.
F
There
are
checklists
and
things
that
should
be
considered
either
in
the
template
or
their
pulls
open
to
update
that.
So,
as
people
are
kind
of
updating
old
Docs
or
trying
to
make
these
criteria
available,
is
there
a
place,
they
can
go.
Look
to
get
the
list
of
things
they
should
consider
and
provide
there.
Well,
there's.
C
Updating
the
cap
template
in
K
enhancements,
so
hopefully
that
has
landed
but
yeah
when
you
go
to
submit
and
issues
check
any
enhancements,
but
I
believe
the
issue.
Template
is
the
cap
template
and
that
will
have
all
the
sections
of
it
will
have
more
than
it
will
have
a
lot
of
sections
in
it,
including
graduation
criteria
and
testimony.
C
F
A
F
So
part
of
what
I'm
trying
to
do
this
year
is
help
push
things
that
have
kind
of
languished
in
beta
towards
b1
or
GA,
and
so
CSR
got
to
the
point
where
we
needed
to
be
and
then
stopped,
and
so
this
issue
had
some
shortcomings
and
things
described
and
so
for
114.
My
goal
is
to
start
putting
together
the
plan
to
address
some
of
these
and
figure
out
what
is
required
for
b1
I.
F
F
Client
clerk
acute
rotation
right
now,
the
cumulant
is
the
consumer
of
that
client
rotation
has
been
exercised
quite
a
bit
and
so
I
think
we
should
look
to
graduate
this.
There
is
not
a
cap
outlining
test
and
documentation,
but
I
will
be
working
on
that
for
serving
cert
that
has
been
available,
but
not
as
well
tested
and
so
I
think
the
first
step
is
outlining.
F
How
has
it
been
used
house
of
integrity?
Are
there?
Are
we
happy
with
the
level
of
the
feature
right
now?
The
feature
is
limited
to
the
cubelet.
All
approval
has
to
be
done
out
of
band.
You
have
to
decide
whether
to
approve
these
requests,
based
on
your
knowledge
of
what
hostname
is
that
cubelets
should
have
access
to,
and
we
don't
have
anything
in
the
project
today.
That
gives
us
that
information
in
a
consistent
way
across
environments.
So
this
is
an
optional
feature
that
you
can
turn
on.
A
K
So,
as
part
of
the
follow
up
work
from
the
token
request,
API,
one
of
the
things
that
we
can
start
working
towards
is
making
the
service
counts
that
are
used
by
controllers
to
start
sort
of
optionally
using
that
API.
If
it's
available,
I
think
that
there
is
still
some
conversation
we
had
on
how
we
make
it
so
that
generated
secrets
by
the
token
controller
aren't
being
set
out
for
these
clients,
because
the
goal
would
be
that
these
clients
only
have
their
ephemeral
secrets
and
memory.
K
K
A
A
A
F
Had
actually
gotten
copied
into
the
coke
that
was
a
tendon
tip
and
wrote
this
I
think
this
is
a
good
example
of
what
we're
looking
for
in
sort
of
kept
that
are
standardizing
features
already
in
progress
like
just
making
really
clear
what
is
tested.
How
is
it
tested?
How
do
we
know
what
is
the
current
support
for
it,
and
so
this
has
been
in
progress
for
a
while.
There
are
tests,
but
just
pulling
that
together
making
sure
we
have
coverage
and
we're
confident
in
the
future
before
we
promote
it.
F
H
H
H
H
I
H
F
Rather
than
inventing
our
own
sort
of
API,
if
they
were,
if
there
were
more
standard
ways
to
consume
that
either
from
from
pipes
or
from
across
the
stree
direction,
or
if
they
were
some
of
those
process,
managers
have
I,
don't
know
about
standard
ways
that
have
ways
that
we
could
learn
from
in
how
they
provide
secret
material
to
processes.
I,
don't
know
if
you've
done
any
survey.
What
was
already
out
there.
No.
H
I
hadn't
looked
because
I
was
really
just
focusing
for
this
on
the
heavy
Fanning
rather
than
like
certificate
reading,
because
I
was
then
yeah
for
the
original
implementation
it
could
have
been
yeah.
Maybe
could
just
read
over
a
pipe
for
like
a
certificate,
but
it
really
wanted
the
objective
for,
for
what
I
really
wanted
was
to
be
able
to
support,
like
rotating
the
key
out
for
the
API
server,
without
having
full
api
server
restart.
K
Is
there
some
reason
we
wouldn't
simply
do
the
approach
that
a
cube,
CTL
and
then
have
about
or
I
guess
not
do
CTL,
but
can
we
not
make
it
just
cash
to
the
token
and
then
keep
rereading
and
keep
updating
the
cache
every
so
often
like
I
can
see
benefit
of
not
having
the
secret
on
disk
I.
Do
you
realize
that
with
the
UNIX
domain
socket,
but
is
it
worth
it
to
build
an
entire
like
pseudo
API,
for
how
you
transfer
this
data
to
the
cube
API
server?
For
what
is
effectively?
Please
don't
restart
me.
H
K
K
F
F
You
know
supported
clusters,
but
you
just
stumble
into
this
and
not
realize
that
you're
using
something
that
is
still
experimental,
right,
I
think
when
we
worked
through
some
of
the
kms
stuff,
we
wanted
to
have
a
pretty
good
understanding
of
the
field
like
who
who
would
be
plugging
into
this
and
have
some
level
of
confidence
that
this
was
not
an
extension
point
with
like
one
consumer,
so
it
would
probably
be
good.
You
solicit
feedback
on
this
from
people
who
be
potential
users
and
say
what
would
you
use
this
board?