►
From YouTube: Kubernetes SIG Auth 20170531
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20170531
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
C
Sure,
there's
enough
people
to
talk
about
it.
It
would
be
great
if
we
could,
at
least
like
arrive
on
some
interim
guidance
for
folks
building
api's,
and
if
we
can
at
least
agree
that
some
of
the
language
in
the
roadmap
document
is
consistent
with
itself.
That
would
be
great
and
I
would
encourage
you
to
comment
in
the
road
in
that
document
as
well.
Yes,.
A
A
Okay,
let
me
just
run
through
kind
of
what's
been
going
on
the
last
couple
weeks:
a
lot
of
activity
around
the
cubelet,
as
you
can
see
so
Jacob
has
been
working
on
both
client-server
tation
and
serving
cert
bootstrapping
and
rotation,
so
the
serving
stuff
went
in,
which
is
great.
That
means,
if
you
start
up
your
cubelet
with
this
feature,
plug
on
instead
of
self
signing
a
serving
cert,
it
will
ask
the
API
server
to
make
it
one.
So
that
means,
if
you
have
a
cluster
that
has
a
signer
available.
A
A
Or
requests
merged
as
well,
so
that
means
we
have
a
new
authorizers,
that's
available
that
will
let
nodes
just
see
the
objects
secrets,
config,
Maps,
persistent
volumes
and
persistent
volume
claims
that
they
need
to
in
order
to
run
their
pods,
so
that
is
available
now
in
master
and
the
doc
PR,
for
that
will
be
open
shortly.
Jordan.
A
I'm
fine
with
allowing
it
to
be
enabled
it
hasn't
gone
through
all
the
scale
testing
that
I
would
like
it
to
to
be
on
by
default.
So
it's
considered
alpha
four
one,
seven
and
part
of
getting
to
beta
is
having
it
on
and
tested,
looks
like
the
acute
mark.
5000
I
have
benchmarked
it
at
those
scales
and
I,
don't
foresee
any
problems,
but
I
wouldn't
want
to
enable
it
by
default.
Until
we
have
do.
A
D
A
A
Yeah
we'll
have
it
on
as
soon
as
possible.
We
have
the
benefit
of
having
given
all
of
our
nodes,
distinct
identities
from
day
one.
So,
a
lot
of
the
concerns
around
making
sure
everyone
is
partitioning
out
their
node
I.
These
are
two
concern
for
us,
so
I
think
it'll
be
a
deployment
by
deployment
basis,
so
something
like
queue,
madam,
which
has
been
pretty
opinionated
about
how
it
sets
up
nodes
if
it's
setting
them
up
in
a
in
a
TLS
bootstrap
way.
A
So
that's
why
it's
an
authorization
mode.
If
you
are
a
deployment
that
gives
your
needs
distinct
identities,
then
you
can
use
this
and
if
you're
not,
then
you
should
keep
giving
your
nodes
permissions.
The
way
you
have
them
and
related
to
that
Mike
was
working
on
getting
good,
TLS
bootstrap
enabled
in
GC
gkt,
so
I
think
that
hole
is
close
to
being
in
as
well.
F
Yeah
I
think
that's
completely
functionality-wise.
That
question
is
whether
we
like
they
enabled
this
and
whether
we
want
to
enable
this
is
a
prerequisite
very
enabling
the
approver
by
default
in
one
not
serving
the
thing.
That's
kind
of
up
in
the
air
right
now
that
we're
trying
to
decide
on
the
main
thing
is:
is
enough
of
testing
a
good
enough
single
signal
to
post
this
as
a
beta
feature,
yeah.
A
A
And
then
the
last
one
on
the
list
was
the
way
the
CSR
approval
worked
previously
was
that
there
was
a
ecstatic
argument
to
the
controller
manager
telling
it
approve
everything
requested
by
this
group,
and
now
the
the
approver
controller
actually
does
an
authorisation
check
to
determine
whether
certs
that
are
shaped.
A
few
different
ways
are
allowed,
so
clients
search
for
nodes
and
clients
are
requested
by
a
node
for
itself,
which
is
used
in
the
Renewable
case
and
a
serving
search
for
a
note.
A
Those
three
specific
shapes
of
certificates
are
recognized
by
the
approver
and,
of
course,
you
can
run
an
approver
against
the
CSR
API,
based
on
any
criteria
you
want.
This
is
just
sort
of
the
three
built-in
cases
that
are
going
to
be
needed
by
most
clusters,
but
you
could
approve
based
on
any
criteria.
You
wanted.
D
Hey
Jordan
one
last
PR
that
I'm
about
to
send
out
I
like
to
turn
the
legacy
a
back
to
false
in
all
the
places
where
it's
hard-coded
to
tree
right
now
in
the
configs
see
any
problem
with
that
it'll
make
Cuba
create
non
ABAC
clusters.
I
think
it'll
also
make
up
great
GCE,
upgrade
SH
disabled
a
back.
We
think
at
this
point
a
release.
Note
stating
that
is
good
enough.
A
G
A
F
B
A
A
B
B
A
A
Out
like
how
we've
got
a
couple
main
use
cases
for
secrets
right
now,
what
the
first
one
is,
get
confidential
values
into
containers,
and
the
nice
thing
about
that
is
that,
as
long
as
we
end
up
with
the
value
inside
the
container,
the
container
really
doesn't
care
where
it
came
from.
So
we
have
a
lot
more
flexibility
about
integrating
with
an
external
secret
store
or
completely
changing
what
the
secret
API
looks
like,
or
you
know
doing
all
kinds
of
crazy
things.
As
long
as
the
value
ends
up
at
the
container
like.
A
H
C
A
A
The
note
authorizer
that
I
just
wrote
is
that,
like
it
will
let
a
cubelet
see
secrets
specifically
for
pods
and
then
pod
related
volume,
specs,
and
things
like
that
like
that,
but
that
doesn't
scale
to
any
arbitrary
controller
like
an
ingress
controller
or
an
engine,
X
ingress
controller
or
a
service
catalog
controller
like
as
soon
as
you
kind
of
open
the
floodgates
to
all
the
controllers.
You
could
write
against
the
guy
that
take
one
object
and
it
references
a
secret,
and
this
controller
wants
to
read
that
secret.
H
A
A
Yeah
and
we
already
have
a
split
between
like
cubelet
level,
volume,
stuff
and
attached
attached
controller
yeah.
If
all
your
stuff,
where
you
might
need
a
secret
in
order
to
attach
a
volume
to
a
cubelet
but
the
key.
But
it
might
not
actually
need
the
secret
on
the
on
the
machine
to
make
use
of
a
in
this.
C
Range
aside
from
like
the
cloud
provider,
Costco
they're
also
volume
types
that
are
not
a
function
of
the
cloud
like
radio
squawk
device.
That
I
believe
is
one
of
the
ones
that
needs
this.
So
even
if,
even
if
we
pulled
some
of
that
stuff
out
into
another
controller,
there's
still
cubelet
we'll
have
to
consume
some
of
those
secrets
because
it
does
amounts
so.
E
Paul
on
the
storage
stake
side,
we've
kind
of
been
driving
towards
a
model
where
plugins
are
going
to
be
completely
out
of
tree
rise
right.
The
thought
so
far
has
been
that
the
way
that
we
expose
secrets
is
going
a
secret
to
a
particular
volume.
Plug-In
is
basically
just
a
mechanism
that
we
have
today,
which
would
populate
a
directory
with
the
secrets
inside
the
container
and
then
plugin
has
access
to
them.
Now,
that's
that's
up.
If
that
includes
mount
right,
Sode
includes
mount
that
includes
much
detach.
C
Okay,
thank
you
for
pointing
that
out.
I
had
I
had
forgotten
about
a
little
driver
to
need
every
plugin
function
outside
the
cube.
Lid
I
do
think
that,
like
so
just
just
for
context,
folks,
like
the
reason
that
I'm
here
today
asking
about
this,
is
that
in
the
Service
Catalog
work
there
are.
There
are
three
different
API
resources
that
we
need
to
somehow
reference
secret
information.
C
There's
a
service
broker
resource
that
we'd
want
to
either
reference
a
secret
that
has
the
odd
credentials
used
to
talk
to
the
brokers,
something
that
manages
a
set
of
capabilities
that
it
offers
to
the
catalogue
and
then
there's
an
instance
resource
which
is
the
instantiation
of
a
service
that
you
might
ask
parameters
to
the
broker.
That
creates.
That
instance
are
themselves
great
in
same
thing,
with
a
binding
from
an
instance
to
a
particular
application,
there's
another
resource
for
that.
That
has
the
same
use
case.
C
So
the
some
of
the
language
that
I
found
to
be
confusing
in
the
roadmap
for
Secrets
is
that
there's
a
there's,
a
stanza
where
it
says
new
novel
uses
for
secrets
not
being
delivered
to
pods
should
be
avoided.
But
then
there's
also
stands
up.
It's
like
well
for
all
these
things
that
are
in
the
bucket
of
of
non
targeting
pod
use
of
secrets.
C
I
think
I
think
either
way
like
the
the
language
needs
to
be
disambiguated
but
I'm
trying
to
orient
myself
in
terms
of
where
does
catalog
fall,
and
this
continuum
abuses
its
to
me
it's
more
of
an
analogue
of
like
an
ingress
controller,
but
but
potentially
more
official
in
an
ingress
controller,
because
it's
something
that
we're
going
to
like
it's
an
extension
to
kubernetes.
It's
not
just
some
thing
you
might
be
running
from
who
knows
where
right?
C
So
it's
it's,
perhaps
a
little
bit
more
official
in
an
ingress
controller,
and
we
definitely
need
to
reference
secret
data,
somehow
guidance
that
I
kind
of
unofficially
heard
was
just
encrypt
the
entire
API
resource
and
store
secrets
directly
in
it,
which
presents
its
own
set
of
problems
I'm,
basically
looking
for
some
guidance,
so
that
I
can
build
an
API
with
confidence
and
take
that
API
to
beta
without
having
them
migrate
fields.
When
we
figure
out
about
loops,
we
did
it
the
wrong
way.
That
makes
sense.
I.
E
Think
down
to
is
that
there
is
two
kind
of
sets
of
Secrets.
There
are
secrets
that
we
don't
really
mind
if
everybody
within
the
namespace
has
access
to
which
is
kind
of
what
we
have
today
with
secrets,
and
then
there
are
secrets
that
are
super
duper
confidential
that
should
have
very,
very,
very
restricted,
hackles
and
I.
Don't
we
were
I
was
talking
to
CJ
and
Gregg
about
this,
and
we
weren't
certain
that
there
would
be
a
way
to
modify
the
existing
secret
mechanism
to
be
able
to
meet
that
need.
E
C
In
this
case,
I
think
that
the
the
two
different
use
case
is
one
which
is
like
the
broker
credentials
and
other
is
secret
parameters.
These
are
both
things
that,
like
inherently
need
to
be
recorded
somehow
in
the
API
surface,
because,
as
like
say
for
adding
a
broker
as
a
catalog
as
like
a
cluster
operator,
I
want
to
be
able
to
create
a
set
of
kubernetes
resources
that
encapsulate
everything.
C
I
need
to
all
the
information
I
need
to
add
in
order
for
the
catalog
to
integrate
with
that
broker,
and
if
I
have
to
do
some
kind
of
sideband
thing.
It's
it's
not
a
good
experience
for
me,
but
it
also
doesn't
have
parity
with
other
to
the
API
right
and
then
for
the
parameter
parameter
capture
like
a
same
thing
right,
if
I'm,
a
user
and
in
order
to
specify
a
secret
value,
I
have
to
do
something
how
to
be
into
the
API.
It
just
doesn't
sound
like
it's
gonna
end.
H
A
And
I
think
the
the
access
to
a
few
secrets
within
a
namespace,
but
not
all
of
them,
is
what
we
want
for
things
like
ingress
and
service.
Catalog
right
like
I,
don't
want
you
to
be
able
to
read.
I,
don't
want
the
ingress
controller
to
be
able
to
read
all
the
secrets
in
my
namespace
but
I'm,
okay
with
it
reading
the
one
that
I
said
held
the
assert
from
my
ingress,
like
I,
wanted
to
have
just
that
one,
and
we
don't
have
a
good
way
to
describe
that
and
manage
that
permission
today.
C
The
one
exception
to
that
is
that,
since
brokers
are
are
global,
it's
like
kind
of
the
same
arrangement
that
we
had
initially
with
storage
classes,
where
you
reference
the
coordinates
of
a
secret
in
the
namespace
from
a
global
global
resource.
But
as
far
as
parameters
for
instances
and
bindings
go
it's
100
percent
local
to
the
namespace.
So.
H
C
H
That
you
know
originally
a
few
config
map,
a
secret
as
just
two
sides
of
the
same
coin
and
I,
get
that
secret
smite,
I've
heard,
show
them
being
secret,
have
to
deviate
some
but
like,
as
a
user,
we've
done
a
lot
to
kind
of
make
you
somewhere
now.
It
seems
like
not
well
folks
to
reference
these
things
is
getting
it.
It
might
be
a
step
too
far,
in
my
view,
on
making
them.
G
Well
that
we
can
solve
this
with
some
conventions.
Can
we
have
something
along
the
lines
like
the
ingress
controller,
you
can
service
account
that
has
access
to
and
then
make
the
convention
that
if
you
want
to
make
a
secret
available
to
be
ingress
controllers,
you
have
to
leave
writing
out
our
back
rule
in
your
each
space
to
allow
that.
B
A
To
specific
resources
that
that
would
be
one
way
you
could
do
it
I
think
having
having
a
way
to
let
clusters
don't
care,
do
the
easy
thing,
but
then
let
clusters
that
do
care
say:
well,
you
don't
have
to
give
blanket
permission
to
your
ingress
controller.
You
can
run
this
this
component.
That
will
look
at
your
ingress
objects
and
see
what
secrets
they
reference
and
then
give
the
correct
access
to
the
ingress
user.
A
B
What
Jordans
suggesting
I
think
other
cloud
like
I
am
systems?
Have
we
have
two
levels?
We
have
cluster
and
name
spacing
the
actual
effectively
have
an
object
level.
Oh,
it
will
call
that
so
I
think
that
makes
sense
to
have
those
that
hierarchy
and
I
think
the
problem
the
sod
was
mentioning
is
really
different
than
the
problem.
That
Paul's
asking
about
sod
said:
if
you
don't
trust
cubelets
and
you
don't
trust
your
your
like
API
server,
then
they
should
handle
a
secret.
A
You
would
always
have
her
secret
access,
and
so,
if
we
avoid
building
things
that
require
list,
watch
on
secrets
and
have
them
prefer
getting
the
secrets,
they
specifically
need,
and
this
is
what
we
did
with
cubelets
right.
This
is
why
we
were
able
to
do
the
note
authorizer
we
just
did
was
because
we
said
a
couplet
should
only
get
particular
secrets
for
particular
pods,
and
eventually
we
will
be
able
to
authorize
them
per
secret,
and
now
we
can
so
if
we
have
them
at
access
api's,
that
will
let
us
do
per
secret
authorization.
A
A
So
just
now
what
go
ahead
and
if
you
are
active,
if,
when
you
need
secret
data,
you
are
always
doing
it
on
individual
gifts,
then
switching
to
use
the
sub
resource
is
not
burdensome
to
you.
It
makes
it
so
that
when
you
write
a
secret,
you
can
know.
I
am
writing
data.
Here,
that's
not
going
to
be
available
to
things
that
are
just
listening,
watching
everything
like
you're
gonna
have
to
get
this
sub
resource
and
the
authorized
to
get
a
sub
resource.
That
explicitly
gives
you
access
to
the
superior
data
in
this
secret.
I.
A
B
C
A
G
So
I
think
it
watches
our
problem.
So
I,
like
the
the
scheme
that
you
proposed
with
the
the
right
only
aspect
to
it.
The
problem
is:
is
that
you're,
assuming
that
secrets
only
ever
an
input
there
are?
There
is
other
code
that
will
be
writing
secrets
also,
and
so,
if
they're
writing
secrets-
and
they
want
to
do
a
controller
loop
to
make
sure
that
the
secret
is
correct
and
nobody's
messed
up
behind
there
and
they're
going
to
need
to
do
a
watch.
That
actually
does
include
the
secret
data.
C
Right
so,
as
far
as
let
me,
let
me
articulate
my
druthers
and
let's
see
how
much
of
this
is
covered
right
so
for
broker
I
would
I
can
get
live
for
now
with
just
yet
because
we
won't
continually
be
relisting.
Workers
it'll
be
fairly
infrequent
on
the
scale
of
like
a
reconciler
loop,
so
I
think
that
would
be
covered
the
as
far
as
the
parameters
ones.
I
would
like,
ideally
to
have
a
server
filtered
watch
so
that
I
could
get
update
events
about
a
secret
that
was
referenced
as
part
of
a
parameter.
A
Yeah
I
mean
this
is
all
like
in
my
head
yesterday
between
when
we
were
talking
and
now
so
definitely
need
to
involve
a
lot
of
people.
I
want
to
give
good
guidance
and
not
set
ourselves
up
like
for
to
get
in
a
situation
where
we
can't
go
fix
this
or
make
it
better,
because
a
lot
of
things
are
depending
on
global
list
watch
or
something.
What.
G
If
we
have
a
way
to
do
is
a
sort
of
a
sub
projection
of
a
list
sort
of
a
filtered
list,
because
the
only
like
we
have
types
on
Secrets.
What
if
we
could
say
that
you
could
write
our
back
rules
around
types,
you
could
write
our
back
rules
around
and
then
like.
We
could
have
a
projection
based
on
on
cubelet
bindings.
Also,
alright,
so
show
me
all
of
the
secrets
that
are
you
know
imported
into
this.
Cubelet
show
me
all
the
secrets
of
this
type.
G
A
G
C
So
I
think
that
what
I
could
do
for
now
is
I,
could
I
couldn't
hold
the
API
server
and
do
gets
on
secrets
when
I
reconciled
and
in
sensory
binding,
and
just
we
already
calculated
checksum
of
what
we
sent
and
I
can.
I
can
like
continually
recalculate
this
checksum
I
think
that
would
be
okay
for
now.
I
would
want
to
know
if
I
did
that,
that
I
would
eventually
be
able
to
move
to
a
server
filtered
watch.
A
C
A
A
But
I
know
at
least
two
use
cases
for
this.
This
sort
of
bulk
watch
like
stitching
together
a
bunch
of
watches
into
a
single
connection.
The
web
consoles
need
it
because
they're
running
up
against
WebSocket
limits
and
the
cubelet
needs
it,
because
it
wants
to
efficiently
respond
to
secret
and
config
map
changes.
So
I
expect
there
to
be
significant
interest
in
making
it
happen.
So.
C
Do
you
think
that
adds
up
to
for
now
it's
okay
in
this
case
to
use
secret
with
the
supreme
incentive
to
use
them
only
with
get
or
is
it
okay
to
use
watch?
And
we
know
that
we
know
there's
an
issue
watching
secrets
and
we
can
leave
ourselves
a
note
that
we'll
have
to
move
to
a
super
filtered
watch
which
does
know.
A
B
A
A
Any
secret
it
wanted,
it
happens
to
only
get
the
ones
referenced
by
cons
and
on.
Our
roadmap
was
eventually
tighten
this
down
so
that
we
are
authorizing
specific
cuts.
But
if
you
are
conforming
to
the
get
API,
then
we
can
transfer
to
you
right
the
thing
that
manages
the
authorization
rules
based
on
Service,
Catalog
instances
or
bindings
and
say
you
know
what
we're
only
gonna.
Let
you
get
these
and
if
you
try
to
get
something
else,
you're
gonna
get
your
hands
Mac,
but
of
course,
you're
willing.
So
you're
not
gonna
get
your
time
all
right.
C
C
That
sounds
good
to
me.
Let
me,
let
me
tell
you
my
version
of
this,
so
we
can
avoid
a
situation
where
we
all
shook
hands
and
said
blue
and
you
said
orange.
Is
it's
okay
to
use
secrets
in
API
surface?
We
should
use
them
only
in
a
context
where
we
do
again
and
if
that
means
that
we
pull,
it
means
that
we
pull
and
we
can
refactor
to
a
bulk
watch
when
the
machinery
is
available.
A
Accurately
I
think
that
seems
like
the
best
balance.
I
would
also
have
as
a
potential
future
refactor,
and
this
is
this
is
a
lot
more
hand
wavy,
but
I
would
really
like
to
be
able
to
separate
metadata
and
confidential
content.
Somehow,
and
so,
if
that
happens,
then
it
might
look
like
refactoring
to
the
confidential
sub
resource.
I
don't
know,
but
I
would
like
to
be
able
to
separate
those
things
so.
C
I
think
I
think
that
I
am
going
to
like
Service
Catalog
CID
needs
to
discuss
what
we'll
do.
But
it
sounds
to
me
like
another
option
for
capturing
printers
since,
like
indirection
via
resource
references,
and
this
API
is
makes
certain
things
like
way
harder
for
us
to
implement
that
an
alternative
would
be
to
encrypt
the
API
resource
and
just
have
have
a
raw
extension
field
for
the
parameters
which,
in
the
API
spec
we're
implementing,
there's
literally
a
a
place
where
parameters
exist,
and
it's
a
blob.
C
C
A
I'm
not
sure,
okay,
I
think
we
need
to
think
about
that
more
and
figure
out
how
it
fits
into
each
of
those.
Those
use
cases
like
yeah
spectrum
up
top
like
how
they
get
into
containers,
how
things
like
the
cubelet
use
it.
You
know
how
it
would
work
for
those
and
how
it
would
work
for
legacy
clients
for
those
things.
Yeah.
G
So
so
here's
a
suggestion
if
we
do
go
to
the
mode
where
we
separate
metadata
from
the
actual
data
exposing
to
users
as
part
of
the
metadata
hash
of
the
values
or
a
hash
of
the
value,
will
make
it
easier
to
detect
changes.
If
we
actually
have
a
deterministic
way
of
doing
that,
because
I'm
thinking
through
right
now,
the
bootstrap
designer
goes
through
and
it
actually
keys
off
of
the
value
of
secrets
and
watches
for
those
to
change.
Recalculates,
a
signature
based
on
that.
So
it's
actually
watching
the
value
of
sequence.
Yeah.
G
G
A
A
I
would
love
for
kubernetes
to
take
your
confidential
content
and
give
it
to
something
else
and
never
have
to
deal
with
it
again
and
then,
when
you
ask
for
it,
we
will
go.
Ask
that
thing
for
it
and
and
just
not
persist
it
not
have
to
deal
with
key
wrapping
not
have
to
deal
with
any
of
that.
I
know
in
the
secret
roadmap,
like
the
the
external
secret
store
stuff
is
again
pretty
hand
wavy,
and
it
isn't
clear
if
that's
going
to
be
like
an
external
thing
that
bypasses
the
API
entirely,
but
meseta
dand.
A
It's
clear
like
this
is
the
metadata.
That's
the
content
and
the
content
gets
chipped
off
somewhere
else
and
never
hits
that
CD
never
touches
the
API.
If
you
want
to
get
it
that
results
in
a
back-end
call
from
the
API
to
the
secret
manager
that
does
whatever
it
does
audits
it.
You
know,
I
would
love
that
I,
don't
know
how
realistic
that
is.
Are.
G
C
G
F
A
A
All
right,
I
didn't
have
anything
else.
I
will
try
to
write
down
some
of
the
things
we
just
talked
about,
but
I
didn't
have
anything
else
for
today
and
if
folks
are
probably
busy
trying
to
close
out
their
their
holes
and
reviews.
So
how
about
if
we
call
it
there
and
yeah?
Look
it
up
next
time
or
on
the
list.