►
From YouTube: Kubernetes SIG Auth 20180516
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180516
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
B
B
So
cig
PM
has
a
representative
list
that
is
largely
there
to
help
them
manage
the
features
and
have
an
idea
of
what
the
states
are
doing,
as
well
as
communicate
back
to
the
states
about
what
they
intend
us
to
do
in
terms
of
planning
and
road
mapping,
and
that
kind
of
thing.
As
part
of
that
there
are
some
requirements
around
the
SIG's
actually
having
somebody
going
and
attending
their
meetings
right
now.
B
Cj
Coleman
is
the
one
sole
representative
of
sig
off
in
that
group,
and
if
anyone
would
like
to
help
out
with
that
effort,
it
would
be
meeting
about
three
to
five
times
during
the
release
and
just
showing
up
to
the
Sapien
group.
And
if
anybody
wants
to
be
a
secondary
and
help
represents
a
goth
and
identify
what
our
feature
roadmaps
are
or
any
requirements
that
sig
PM
has
of
us.
That
would
be
really
helpful,
and
so
there
are
a
few
links
in
the
meeting
notes
to
talk
about
how
you
go
and
sign
up.
A
C
So
if
anyone
has
used
GK
de
Coster
in
particular,
one
of
the
things
you
will
notice
is
that
when
you
first
start
up,
your
I
am
user,
has
quality
operations
by
virtue
of
the
gke
webhook
authorization,
but
if
it
tries
to
do
anything,
are
back
related
like
create
some
cluster
roles,
you're
deploying
a
manifest
that
has
some
cluster
roles.
It
gets
forbidden,
that's
an
error
that
says
you're
trying
to
grant
permissions
that
you
don't
have.
C
It
requires
you
to
have
all
of
the
permissions
that
you
are
trying
to
add
into
the
system,
and
it
requires
you
to
have
those
permissions
via
our
back
objects
tool
bindings,
because
that's
what
it
can
actually
inspect,
and
so
that
works
fine,
if
the
only
authorizer
you're
using
is
the
are
back
riser.
But
if
you're
using
something
like
uke
there,
there
are
multiple
authorizers
in
place.
You've
got
to
the
cluster
api,
defined
authorization
rules
and
I
am
defined
authorization
rules.
Those
don't
play
nicely
together.
I
mean
it
fails.
It
fails
safe.
C
You
get
you
get
forbidden
rather
than
and
saying
well,
I,
don't
know
what
to
do.
I've
got
multiple
authorizers,
so
I
guess
I'll.
Just
let
you
go
ahead,
but
it
caused
those
problems
in
like
bootstrap.
In
cases
where
you
are
actually
a
super
user
and
I
am,
and
you
could
do
anything
to
any
API
you
want,
but
our
last
is
saying:
I
don't
know,
I,
don't
give
these
permissions
about
so
I'm
going
to
say
no
and
so
what
we
are
wanting
to
do
to
find
a
specific
authorization
check.
C
So
we
already
did
this
for
binding,
creating
rule
bindings
when
you
create
a
rule
binding.
If
you
already
have
all
the
Commission's
and
the
role
of
your
binding,
then
it's
allowed
or
if
the
authorizer
explicitly
authorizes
the
bind
or
then
it's
allowed,
so
that
gives
qke
or
an
extra
authorizes
or
a
way
to
give
a
thumbs
up
to
letting
someone
perform
a
role
binding,
and
so
this
is
wanting
to
do
something
similar
for
defining
roles,
and
so
the
approach
is
basically
the
same
question.
C
D
C
D
C
You
can
bring
in
far
back
permissions.
You
don't
currently
have
and
you
can
grant
them,
then
that
can
I
I,
don't
really
expect
I.
Don't
really
expect
this
be
used
for
much
other
than
what
we're
seeing
here,
where
you
are
a
super
user
in
some
other
system
and
you're
just
trying
to
define
your
are
back
roles.
That's
really
all
you're
trying
to
do,
and
it's
silly
that
you
as
a
super
user
cannot
do
that.
C
So
yeah,
that's
the
issue,
I!
Guess!
If
you,
if
anyone
has
great
ideas
right
now,
I'd
love
to
hear
them.
If
people
have
strong
feelings
against
the
current
state
or
they
have
other
suggestions
and
want
to
comment
out-of-band
in
the
poll,
that's
fine
as
well
I,
don't
know!
If
the
day
was
there
anything
else.
You
understood
yeah.
D
C
That
is,
if
you're
a
super
user,
you
have
the
escalate
verb
and
if
you
don't,
then
you
should
be
slightly
scared
to
grant
this.
Like
you
shouldn't.
This
should
be
the
kind
of
thing
that
would
give
you
pause.
Yeah,
I,
don't
know,
I,
don't
know
that
escalate
is
exactly
the
right
word,
but
the
fact
that
it's
a
little
scary,
I'm,
actually,
okay
with.
E
There
a
reason
that
you
have
like
up:
if
you
can
update
roles
or
delete
roles,
you
could
possibly
like
create
a
new
role,
but
it
has
the
same
name
as
one
where
an
existing
role
binding
exists,
which
would
you
know,
give
you
access,
but
it
seems
pretty
safe
too.
If
you
could
only
create
new
roles,
I.
C
Don't
think
we
want
to
draw
a
line
between
create
and
update,
especially
with
like
the
declarative,
big
stuff
coming
in
where
people
generally
use
apply
and
so
I
think
we
would
this
sort
of
secondary
check
the
that
is
checking
you
have.
Are
you
allowed
to
put
the
particular
permissions
into
this
role?
I,
don't
think
we
wanted
to
finish
being
creative.
D
E
A
C
C
D
C
C
D
A
C
C
A
So
I
have
a
more
generic
question
then,
which
is
special
permission.
C
Don't
did
so
I
view
discovery
documents
as
useful
for
the
person
making
the
API
request.
So,
if
I'm,
making
an
API
request,
I
know
that
this
resource
supports
create
an
elite
and
whatever
else
these
permission
checks,
don't
really
affect
me.
Making
the
API
request.
They
effects
the
person
who
is
building
policy
so
I,
don't
know
that
it's
super
important
for
it
to
show
up
in
discovery,
I,
don't
but
I,
don't
think
any
client
would
be
able
to
do
anything
automatically
in
response
to
it,
showing
up
in
discovery.
A
C
I
think
one
of
the
characteristics
of
the
authorization
interface
we
have
is
that
you
can
ask
it
arbitrary
questions
right
and
so
we've
got
a
couple.
You
know
use
bind
and
whatever
we
end
up
with
here,
we
have
a
few
known
examples
where
we're
using
it
for
specific
queries,
but
you
can
actually
use
it.
Generically
and
people
do
I.
Think
you're
gonna
have
a
hard
time
sort
of
gathering
a
definitive
list
of
all
possible
uses
of
it.
C
A
Sounds
good:
let's
move
on
to
the
next
topic,
which
is
something
I
threw
on
here.
I
was
recently
kind
of
going
through
all
of
our
add-on
base
images
and
noticed
that
a
lot
of
our
images
that
are
based
off
of
Alpine
do
so
basically
just
to
install
the
CA
certificates
package.
My
first
thought
was
well.
Maybe
we
should
have
some
sort
of
kubernetes
base
image
that
just
includes
CA
certificates,
but
then
I
was
thinking
that
actually
I
think
building
CA
certificates
into
container
images
is
a
bit
of
an
anti-pattern.
A
One
kind
of
simple
approach
is
to
just
dump
them
into
you
config
maps
and
mount
those
into
into
the
containers
at
the
right
path.
That
does
mean,
since
we
don't
currently
have
any
cross
namespace
config
map
references.
You
in
the
current
state
you
would
need
to
create
those
certificates
in
every
namespace.
H
Is
there
really
any
difference
between
this
and
that
cluster
managed
config
map
injected
into
containers?
I
mean
I,
it
is
a
specific
case,
but
I
think
I
go
once
a
day
and
someone
brings
up
man
I
wish
I
could
have
this
config
method,
two
namespaces.
Is
it
just
a
small
step
from
CA
to
generic
config
map
across
namespaces.
A
H
Effectively,
that's
what
this
is
I
mean
they
give
your
cluster
admin.
You
could
probably
make
this
distinction,
so
there's
kind
of
that
weird
spot.
When
we
jump
out
of
the
move
space,
we
start
getting
into
the
difference
between
cluster
admin
and
someone
who
wants
to
do
this
across
multiple
names:
the
cluster
admin.
That's
also
another
wrinkle
like
in
that.
If
we
did
like
cluster
pod
preset
or
something
like
that
or
anything
that's
injecting,
if
it's
only
the
cluster
admin
that
could
do
it
or
someone
who's
effectively
equivalent
to
cluster
admin,
it
does
limit
its
use.
H
It
was
proposed,
but
it
was
clustered
pod.
Presets
got
really
close
to
that
or
like
that.
Let's
kick
it
out
a
tree
because
we're
doing
that
and
it's
kind
of
languished
a
little
bit.
It's
not
hard
to
do.
This
has
come
up
someone
else.
There's
there
were
two
other
clusters.
Scoped
policy
objects
that
someone
proposed
recently
that
were
basically
just
small
variants
on
the
on
the
namespace
scoped
one
where
it
was
again.
I
H
Would
make
so
the
other,
the
other
one?
That's
very
common,
and
that's
why
cluster
pod
preset
comes
up
is
proxy
environment
variables
is
probably
the
number
one
thing
that
I
think
I
get
one
email
a
day
about
someone
wanting
to
do
environment
variables
across
the
whole
cluster
because
of
proxy
or
proxy
is
the
most
common
one.
A
H
I
mean
you
can
maybe
make
the
argument.
Config
maps
are
in
the
scope
of
kubernetes,
and
so
whether
your
namespace
scoped
or
not,
there
are
clusters
that
are
applications
that
there
are
namespaces
that
are
applications
I,
think
it's
a
valid
point
to
to
do
that.
It's
certainly
something
that
we
might.
That
would
be
best
as
an
extension
alongside
something
like
pod,
presets,
potentially
the
config.
H
And
maybe
maybe
this
is
like
a
good
opportunity
to
pull
together
the
use
cases
around
pod
preset
and
give
them
a
little
bit
more
kick
and
say
you
know,
being
able
to
mount
a
dynamic
volume.
I
don't
even
know
is
cluster
is
a
what's
the
extension
mechanism
for
storage.
Si
si
si
si
even
beta
yet
I'm,
always
confused.
J
Just
something
unrelated
so
much
related
generally,
you
can
use
Dockers
from
directive
to
basically
bill
from
Alpine,
get
the
certificates
and
then
do
scratch
start
from
scratch
and
get
the
certificates
into
the
earth
image.
Since
that
original
problem
could
be
solved
just
by
orchestrating
the
image
build.
H
Symbiotic
there's
a
symbiotic
relationship
between
apps
that
take
advantage
of
the
platform
that
are
reactive
to
config
maps.
Reacted
to
secrets
platform
enables
tools
that
make
those
to
react.
Stateful
sets
in
services
and
endpoints.
We
do
kind
of
lack
we're
kind
of
just
we're
just
getting
to
the
point
where
we're
starting
to
use
config,
Maps
and
secrets
in
components
and
make
that
easy
and
cross
cross
namespace
config
maps
can
be
managed
at
a
higher
level
but
they're
annoying.
H
H
I
Taking
this
to
an
extreme
I
think
what
we
have
is
some
some
files
on
disks
that
we
want
to
manage
separately
from
the
container
image
with
the
container
images
packages.
So
would
you
consider
potentially
a
similar
mechanism
for
updating
Lipsy,
for
example,
it
might
be
useful
to
have
a
single
Lipsy
across
a
cluster
and
update
that,
independently
of
its
container
images,
can
we
extend
as
a
mechanism
to
handle
updates
of
common
shared
libraries.
I
mean.
H
The
docker
image
volume
container
image
volume
proposal
had
that
use
case
called
out
at
the
time
it
was
more
limitations
in
docker
dams
did
a
prototype
with
a
flex
volume
that
was
just
you
know.
Bare-Bones
stupid
I,
do
kind
of
think
that
there
is
an
analogy
there
of.
If
we
have
an
API
mechanism
that
establishes
a
channel
from
a
centrally
managed
thing
to
the
to
the
nodes,
we
should
be
consistent
about
it,
whether
it's
config
map
secrets
or
volumes
that
are
doing
that
sort
of
synchronization.
H
Really
is
a
shame
because,
like
it
would
be,
if
CSI
was
a
little
bit
lower
bar,
it
would
be
trivial
to
create
a
CSI
plugin
that
implemented
any
number
of
these
things
with
a
CRD
like
it
doesn't
even
have
to
be
cluster
config
Maps.
It
could
just
be
a
CRD
that
either
an
admin
sets
or
you
set
like
I-
think
we're
really
a
me.
It's
still
too
hard
to
build
these
things
and
just
show
them
working
with
the
infrastructure
that
we
have.
E
H
You
know
Heroku
attack,
style
uploads,
where
you
have
an
image
that
has
your
source
code
and
an
image
that
has
your
runtime
and
nothing
about
images
says
they
have
to
have
two
lips:
leave
them
or
no
chance,
runtime,
etc.
Then
that
issue
a
I
feel
like
everybody
kind
of
wants
something
like
it,
but
nobody
needs
it
enough
that
it
has
ever
reached
escape
velocity,
given
the
amount
of
changes
to
the
cubelet
to
make
it
happen,
so
it
commits
kind
of
languages.
H
And
there's
not
a
ton
of
difference
between
like
putting
a
G
Lib
C
inside
an
image
and
using
an
image
volume
from
putting
a
CA
bundle
and
a
bunch
of
static
config
in
an
image
and
delivering
it.
The
same
way
and
doing
you
know
encryption
of
that
image
or
something
so
that
it's
a
payload
that
gets
delivered
from
a
surplice
bundle
is
just
a
tar
file
of
nodejs
scripts,
for
instance,.
K
Even
though
this
they
were
like
belly
security
savvy,
they
didn't
realize
they
had
a
back
still
on
in
this
cluster.
I
wanted
to
kind
of
like
raise
this
as
a
sort
of
discussion
topic
in
the
doc.
You
can
see
yeast
wheeze
kind
of
talked
about
the
security
profile,
work
and
I.
Think
that
helps
do
it.
Do
we
think
that
is
enough,
like
should
that
be?
C
C
Things
that
are
intended
to
interact
with
kubernetes
components
that
we
can
reason
about.
You
know
we
say
we
can
have
cubelets
up
to
two
versions
other
than
a
few
guys
over
you
know,
and
so,
if,
if
three
versions
after
we've
dropped,
some
function
from
the
cube
like
I,
think
we
can
do
something
to
automatically
remove
that
permission
there.
Tightening
that
tighten
that
up.
C
However,
if
it's
a
role
or
something
that
is
being
used
like
as
a
general
purpose
thing
or
even
in
the
case
where,
like
the
are
back
rolls
or
for
nodes,
we
don't
know
that
everybody
is
using
the
node
authorizer.
So
that's
why
we
continue
carrying
that
that
role,
I,
don't
think
we
can
automatically
tighten
that
I
do
think
we
should
have
tooling
or
detection
that
you
are
in
a
looser
than
default
state.
E
K
C
G
C
I
Think
we're
gonna
have
to
find
a
separate
solution
for
a
component
configuration
and
our
back
policy
configuration
I
think
we
can
probably
make
improvements
to
acute
control,
reconcile
fairly
easily
potentially
add
diff
support
and
be
able
to
target
the
bootstrap
policies
for
a
specific
release
branch.
Maybe
those
seem
like
low-hanging
fruit,
improving
component
config
introspection
will
allow
better,
will
allow
development
of
more
accurate
and
easier
to
use
benchmarking
and
security.
Benchmarking
tools,
so
I
can.
C
Point
something
at
my
cluster
and
get
like
a
scorecard.
Like
the
the
as
I
said,
the
scorecard
thing
certain
looks
at
your
server
I
mean.
Obviously
it
can
do
that
just
by
talking
to
the
endpoints,
but
something
at
that
level
of
difficulty.
For
you
just
say,
here's
my
star.
That
appears
my
config
tell
me
what
I'm
doing
wrong
and
make
make
me
work
to
get
a
green,
a
plus
check,
like
whatever
yeah
yeah.
B
L
But
yeah
yeah,
the
current
CRS
defines
the
like
the
the
rules
ready
to
the
command
line
flex
and
file
permissions
and
according
to
the
spec,
is
currently
supposed
to
come
native
version.
1.6,
1.7,
1.8
and
I
think
it's
time
to
evolve
that
because
a
new
version
comes
out
and
bunch
of
the
Koala
and
Flags
changed
so
yeah.
K
I
think
it's
a
little
chicken
and
the
egg
they're
like
if
we
had
a
good
way
to
measure
it
and
evaluate
clusters
against
it.
Everyone
would
be
wanting
those
things
updated
as
quickly
as
possible,
and
you
know
fresh
versions
but
like
while
there
isn't
like
a
great
way
to
evaluate
then
yeah,
it's
it's
kind
of
less
useful.
You
have
to
do
a
lot
of
manual
work.
B
M
B
So
I
was
having
similar
conversation
with
some
of
that
hefty
Authenticator
maintainer
z--,
it
doesn't
seem
like
there
are
a
lot
of
issues
so
far
by
people
who
have
been
using
this
plug-in
interface
and
been
writing
code
against
it.
So
that
gives
me
a
bit
of
confidence
around
this
graduating
to
beta.
B
We
I
had
some
initial
concerns
around,
maybe
the
way
that
the
inputs
get
passed
in,
and
also
just
general
windows
support,
because
I'm
not
entirely
familiar
with
what
that
development
environment
looks
like
overall,
if
I
think
that
the
biggest
sort
of
way
that
we
could
score
it
as
if
plug-in
containers
who
are
writing
against
these
interface
can
drop
into
that
issue,
and
just
say
we
are
working
with
this.
We've
seen
no
issues,
we
don't
have
any
feature
requests
or
changes.
B
B
B
A
B
H
I'll
keep
this
short.
It's
come
up
a
couple
times:
people
who
have
post
Secrets
for
the
cluster
and
as
we
move
to
more
dynamic,
config
and
bootstrapped
clusters,
it's
getting
more
annoying
for
people
to
manage
credentials
on
different
container
runtimes
like
container
D
or
docker
or
cryo,
or
any
of
the
seventeen
others
that
exist
out.
There.
I
wanted
to
float
the
idea
with
this
zig
and
with
sig
note
about
adding
a
credential
provider,
and
this
is
really
similar
to
the
secret
one
in
some
respects.
H
I
just
wanted
to
keep
it
separate
least
for
now,
which
is
there's
a
specific
use
case
for
the
credential
provider.
When
infrastructure,
which
is
you
want
secrets
that
the
cluster
can't
see
to
allow
you
to
pull
images
or
you
want
to
distribute
across
your
nodes,
the
infrastructure
images
on
the
node
David
sets
that
are
shared
or
part
of
a
standard
infrastructure.
H
We
have
credential
providers
for
the
cloud,
but
we
don't
have
a
credential
provider
for
kubernetes
itself,
and
so
I
had
just
been
talking
with
about
a
couple
of
people
about.
Would
a
credential
provider
for
the
cubelet
that
fetch
secrets
from
the
cluster
for
the
purposes
of
image,
pool
secrets,
adding
a
global
image
pool
secret
David
had
a
couple
of
comments
like
you
probably
wouldn't
want
just
one
or
you
could
conceivably
have
different
ones.
The
case
that
I'm
thinking
of
is
very
much
like
one
per
cluster.