►
From YouTube: Kubernetes SIG Auth 2019-06-12
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting
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
B
Looks
like
mica
is
on
the
at
this.
One
has
been
out
for
a
while:
I
think
that
it's
pretty
close
to
being
merged
and
potentially
worked
on
is
another
feature
in
116
does.
If
anybody
has
anything
else
to
say
it
looks
like
there
were
no
strong
objections
and
discussion
and
dried
up
a
little
bit
so
hop
on.
If
you
have
any
less
objections,
but
I'll
probably
try
to
lgt
em
this
sometime
before
next
aghast
meeting
so
that
we
can
start
working
on
the
116
alpha.
B
D
C
B
B
B
So
currently
I
just
assigned
it
to
the
two
sub
project
owners,
but
if
anybody
else
is
interested
or
has
questions
or
thinks
that
stuff
should
be
explained,
more
or
stuff
should
be
included,
please
take
a
look
and
read
through
it
and
hopefully
once
this
emerge.
This
will
be
a
place
where
we
can
start
to
propose
its
proposed
pad
to
GA.
C
And
I
think
the
time
frame
for
that,
since
this
is
really
just
hoisting
current
state
into
cap
format,
this
will
likely
go
in
once
we're
convinced
that
it
is
accurately
reflecting
the
current
implementation
and
then
over
the
next,
probably
two
or
three
weeks
like
to
work
on
pinning
down
what
we
intends
to
do
for
b1.
So
when
the
discussions
Docs
or
PRS
around
that
get
opened,
we'll
send
that
out
to
the
list
as
well.
So
people
can
keep
keep
up
to
date
with
that
and
weigh
in
with
any
questions.
B
E
E
But
right
now
you
would
still
have
to
manually
approve
the
CSR's
I'm
wondering
so
there
for
context.
They
approached
the
coop.
That
kind
of
takes
is
that
the
controller
can
be
configured
to
sign
like
automatically
signed
Cooper
certificates
if
they
have
like
the
exact
right
kind
of
group.
For
that
node
and
I'm
wondering
long-term,
could
the
controller
be
allowed
to
just
always
allow
renewals
like
you,
can
allow
a
specific
group
to
okay
sounds
like
there's
already
an
issue
for
this
thanks
Mike.
B
Some
sort
of
external
credential-
and
there
needs
to
be
an
external
trust,
set
up
between
the
Machine
and
the
API
in
order
to
validate
that
certificate.
Signing
request
for
things
that
are
running
on
the
cluster
we
can
chain
up
from
that
trust
and
use
the
service
account
tokens
as
input
to
authorizing
the
CSR
for
things
running
out
kind
of
outside
the
cluster,
like
maybe
a
static
pod
that
runs
I,
can
control
our
manager.
It's
a
little
bit
more
difficult.
E
So
that's
the
components
that
I'm
kind
of
interested
in
or
maybe
static,
pods
yeah,
I
agree
with
you
on
the
service
account
front
I'm,
not
a
house
I'm
sure
like
like
what
do
you
mean
when
you
say
that
you
need
some
kind
of
external
trust?
Like
do
you
mean?
Because
you
have
to
issue
it
like
an
initial
certificate,
yeah.
E
From
yeah
I
mean
I
can
only
really
speak
from
my
experience
so
like
we
are
doing
everything
on
a
vault
where
possible,
but
obviously
we
still
have
a
signing
CA
to
sign
the
CSRs,
and
then
we
just
issued
that
initial
certificate,
like
one
off
the
vault
and
then
after
that
it
gets
reissued,
obviously
from
a
signing
CA,
which
is
not
involved.
Although
a
long-term,
it
would
be
really
cool
if
we
could
sign
this
at
a
vault
as
well,
but
so
like
for
us.
E
F
F
E
So
the
approach
that
I
was
taking
in
my
PR
is
it
pretty
much
exactly
mirrors
the
way
that
the
couplet
works
with
the
rotate
certificates
flag,
which
is
basically
it
uses
whatever
coop
config
it
boots
with
which
has
whatever
privileges
it
has
and
then
once
it
starts,
it
starts
using
that,
but
they
a
synchronous,
Li
immediately
tries
to
rotate
it
out.
I
think
this
is
how
cool
admin
works
as
well,
and
then
once
it's
rotated
it
out
and
then
keeps
it
fresh.
So
it
never
like
blocks
on
that.
First,
initial,
issuance
yeah
I
think.
C
C
Client
go
can
consume
token
credentials
or
certificate
credentials,
and
if
you
give
it
a
token
file,
it
will
actually
read
in
the
token
from
that
file,
but
then
set
up
a
background
thread
to
watch
that
file
for
changes
and,
if
the
token,
that's
in
that
file,
changes
it'll
start
getting
used
by
the
clients.
You
great
doing
the
same
thing.
C
E
Program
I
dream
solution
to
be
honest
with
you,
I
guess,
I
kind
of
assumed
it
that
I'd
been
deliberately
decided
not
to
do
it.
That
way.
No
okay
yeah
because,
like
for
example,
if
I
compare
it
to
EDD,
which
relates
the
certs
on
every
request,
roughly
compared
to
vault,
it
reloads
its
own
tailor
certs
on
a
sick
heart
like
that's
so
easy
to
work
with,
and
then
kubernetes
is
the
only
one
where
I
have
to
like
docker
restock
containers,
and
it's
the
only
tricky
one.
E
So
probably
my
dream
would
be
like
a
periodic
reload
of
full
it
like
a
file
watch
falling
back
to
periodic
reload.
It
would
be
probably
ideal
or
doing
it
on
a
signal.
It's
probably
okay,
as
well
yeah,
but
I'm,
happy
to
implement
that
I.
Just
I!
Guess
that's
such
a
simple
solution,
like
I,
said
just
assume
that
wasn't
the
plan
no.
F
E
The
rest
I
couldn't
flush
that
up
and
see
where
it
goes.
Okay,
okay,
so
if
that's,
what
we
think
is
the
best
solution
for
now
that
sounds
good.
I
mean
honest,
think
that
couplet
thing
is
like
highly
complicated
and
frankly,
because
I've
already
had
to
build
my
own
certificate
distribution
mechanism,
that's
kind
of
not
necessary
for
me
to
use
it
so
yeah.
The
ideal
thing
for
me
would
be
just
allowing
it
to
reload
from
disk.
B
E
C
And
honestly,
if
we
got
reload
from
disk
working,
the
way
we
envisioned
I
would
probably
be
in
favor
of
at
least
isolating
the
rotation
logic
inside
the
cubelet,
so
that
the
rotation
happens
in
its
own
little
side
loop
and
when
it
has
a
new
circuit
happy
with
it,
drops
it
on
to
disk
and
then
the
normal
who
is
right.
Rom
disk
takes
over
yep.
C
E
C
In
order
to
make
that
right,
you
still
need
that
and
you
need
the
the
custom
get
certificate
implementation
so
that
when
a
new
certificate
gets
picked
up,
you
can
drop
open
connections
and
force
them
to
reestablish
so
that
they
don't
get
hung
with
a
established
connection
with
an
expired.
Sir
seized
building.
E
C
C
G
E
B
B
A
A
B
D
You
want
to
do
this
to
here,
or
should
I
I
can
kind
of
go
over
to
look
so
basically,
what
this
is
is
when
we
issue
a
service
account
token
it's.
This
PR
is
going
in
and
adding
a
key
ID
to
the
token
that
tells
us
which
key
the
token
was
signed
with,
and
that's
to
help
the
open,
ID
relying
party
lookup,
which
key
it
can
use
to
verify
the
token
without
having
to
try
all
of
them.
B
D
B
Do
not,
but
there
is
a
proposal
to
do
so:
okay,
so
yeah.
These
would
have
to
correlate
with
those
I
think
that
we
would
also
like
and
I
know.
We
would
want
an
external
signer
that
proposes
a
key
ID
to
have
that
key
ID
make
it
into
a
signed
token
I
think
in
general
that
having
defaults
for
the
like
file
RSA,
like
PEM,
encoded,
RSA,
private
keys,
would
be
useful.
I,
don't
see
a
huge
downside
in
picking
a
default
derivation.
The
key
ID
I
think
that's
the
main
question
I
had
for
people
in
here.
H
B
H
One
comment
on
this
to
the
it's
a
different
issue,
but
the
the
open
feature
P,
the
CAF
PR-
that
I
have
actually
adds
the
key
ID
well
over
an
external
signer.
It
adds
it
lets
the
signer
determine
the
key
ID
on
the
entry.
It
doesn't
it
just
that's
an
empty
key
ID.
So
I
guess
is.
Is
this
proposal
to
have
like
a
derived
heat
like
a
Shaw?
Some
of
the
key
always
be
the
key
ID.
No.
B
B
C
D
Not
aware
of
any
so
I've
looked
in
the
spec
and
there's,
actually,
it
doesn't
actually
mandate.
It's
that
the
only
places
that
it
talks
about
it
is
in
one
example.
It
kind
of
gives
the
example
Mike
gave
where,
if
you
see
an
unknown
key
ID,
that's
your
trigger
to
go
back
and
refresh
your
your
the
keys
from
the
issuing
party
or
the
identity
provider,
and
then
the
only
other
place
it
talks
about
key
IDs
is,
when
you
add,
verdice,
multiple
keys.
When
the
identity
provider
advertised
multiple
keys,
it
must
put
a
key
ID.
C
B
C
D
D
B
Kept
to
do
it
is
probably
not
a
kept,
yet
it
would
probably
be
the
token
accounts,
or
this
service
count
talking
one
where
we
started
to
flesh
out
some
of
the
Jukes
URL
stuff.
That
would
probably
be
a
good
thing
to
turn
into
a
cap,
although
there's
like
three
different
features
at
this
point
related
to
that
kept,
you
kept
support,
having
three
different
features
that
have
different
levels
of
maturity.
At
a
given
time.
We've.
C
Done
in
roll-up
type
things
around
some
of
the
CR
D
and
admission
webhook
stuff,
where
there
were
different
pieces
at
different
levels
once
the
primary
feature
goes
to
GA,
it's
probably
worth
starting
a
new
one
for
additional
things,
that
kind
of
make
its
way
through
the
lifecycle.
But
if
the
whole
thing
is
still
beta
level
and
we're
just
kind
of
fleshing
out
different
pieces
of
it,
expanding
in
the
current
design
kind
of
helps,
keep
it
coherent.
That
doesn't
seem
bad.
Okay,
if
it's
gonna
be
a
big
thing.
C
That
has
a
lot
of
different
considerations
and
we're
going
to
want
to
do
be
able
to
like
merge
and
iterate,
then
probably
split
it
out.
Just
because,
once
you
merge
into
something
that's
already
an
implementable,
it
gets
impossible
to
follow.
So
if
it's
a
small
thing
that
we
can
probably
get
agreement
on
in
the
life
of
one
PR,
then
just
do
it
in
the
same
dock.
Otherwise
split
it
out
sounds
good.
I
B
I
B
A
All
right,
I
think
at
next
week's
bi-weekly
meeting
we
should
probably
start
talking
about
or
run
through
our
plans
for
116.
There
are
a
lot
of
things
that
were
originally
slated
for
1:15
that
got
punted
to
116
and
so
I
think
would
be
a
good
idea
to
just
kind
of
get
this
all
documented
and
see
what
we
need
to
do
for
each
of
those
all
right.
We've
got
about
half
an
hour
left.
A
F
B
B
C
B
C
K
C
C
B
J
C
B
C
L
C
B
C
A
C
C
I
L
C
So
this
is
allowing
opting
out
of
a
service
account
took
in
her
container
I
thought
if
it's
only
opting
out
and
not
trying
to
mount
distinct
service
accounts
into
different
containers,
I'm
I
would
say,
I'm
neutral
on
that
I'm
not
necessarily
opposed
to
it.
I,
don't
feel
that
strongly
either
way.
I
could
see
that
being.
A
A
C
L
C
A
A
I
C
At
the
very
least,
doing
some
authorization
check,
which,
in
the
past,
we've
sort
of
hacked
up
into
fake
sub
resource
checks,
like
do
you
have
access
to
the
finalizer
sub
resource,
even
though
the
finalizer
separation
which
doesn't
exist,
run
an
authorization
check
against
it,
yeah,
possibly
something
along
those
lines.
Cool
thanks.
B
A
B
B
B
C
C
It
is
I
think
the
intent
was
around
the
grow
lot.
When
you
change
a
secret
or
config
map
like
you
would
generate
a
new
name
so
that
the
same
content
would
be
M.
You
have
an
immutable
era,
I
did
with
it
name,
and
then
you
changed
the
content.
The
name
would
change
and
you
update
the
deployment
to
point
to
the
new
name,
so
that
rolling
back
would
point
you
back
in
the
old
data
I
think
in
the
two
and
a
half
years,
since
this
was
done
out.
There
were
coaches,
like
some
of
the
stuff.
A
C
C
I
A
K
K
Mean
the
original
goal
for
all
of
this
was
to
get
the
cubelet
out
of
the
loop
and
replace
it
with
something
that's
purpose-built
to
carry
gigs
of
traffic.
If
you
try
to
run
it
back
up
through
the
exec,
so
I
like
Mike
and
I,
had
a
discussion
at
Q
Khan
in
December
and,
like
I,
understand
the
point
of
view
of
trying
to
get
to
the
most
secure
option
possible.
I.
Just
don't
think
the
cubelet
is
the
right,
funnel
from
a
new
perspective
to
run
gigs
of
data
through.
If.
K
Problem
which,
which
is
which
was
something
Mike
and
I,
were
kind
of
like
discussing
I
mean
whatever
we
do
here,
is
going
to
be
more
involved
than
just
something
at
the
cubelet
and
so
I
I
guess,
like
I,
think
I
view
the
current
situation
as
ugly
and
hacky.
The
right
solution
probably
is
to
move
law,
hogs
exact
port
forward
out
of
cubelet
and
api
server
into
something
that
can
be
orthogonal
e
scaled.
That's
a
much
bigger
chunk
of
work,
yeah.
C
H
C
C
A
A
B
K
A
Yeah,
on
a
related
note,
we're
working
on
Adaline,
adding
throttling
to
a
lot
of
these
flows,
which
also
affects
this.
We
wanted
to
get
to
the
issue
that
was
especially
I'm.
Glad,
let's
get
do
you
know,
maybe
let's
just
skip
ahead
to
that.
Let
me
see
if
I
can
find
my
chat
window
just
six
six
three
one,
one.
A
I
A
Okay
sounds
good
yeah,
just
one
one
comment
on
this,
so
in
order
to
use
this
to
isolate
nodes
from
each
other,
this
form
needs
to
be
used
with
them.
That
includes
the
node
name.
The
problem
there
is
that
any
component
talking
to
nodes
would
then
need
to
manage
a
separate
token
for
every
node,
which
gets
problematic
for
something
like
the
metrics
server,
which
is
potentially
scraping
thousands
of
nodes
in
a
cluster
and
I.
A
B
K
I
would
ask
on
this.
Tim
is
like
so
we're
basically
defining
an
API
of
strings
within
the
audience.
What
other
name
spacing
would
we
need
to
preserve
in
the
future
for
other
audiences
and
wouldn't
want
to
fill
out
some
examples
here?
So
we
could
discuss
it
by
only
the
audience
is
you
know,
audience
is
a
little
weird
in
a
lot
of
respects,
but
things
along
the
lines:
/
namespace
scopes
or
/
API
server
or
control
plane
or
a
specific
worker.
G
K
Which
group
I,
just
it
would
be
good,
hey,
guy
and
David,
can
like.
We
certainly
had
wanted
scope
tokens
for
a
while
I
think
use.
Cases,
for
this
are
a
little
bit
different,
but
certainly
I
just
want
to
see
like
a
little
bit
more
like
what
are
the
other
things
that
we
would
ever
shove
in
here,
and
could
we
have
enough,
like
potentially
use
cases
that
we
could
make
sure
we
don't
shoot
ourselves
in
the
foot.