►
From YouTube: Kubernetes SIG Auth 20190306
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20190306
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
All
right,
so
this
is
the
cig
off
meeting
for
March
6
29
seems
like
it's
been
a
very
very
long
time.
We've
had
one
we
got
I
seem
like
a
pretty
reasonable
agenda
in
Jordan
handsome
desire
for
making
our
meetings
a
little
more
structured,
but
we
can
start
with
announcements
for
the
during.
Did
you
want
to
talk
about
the
extension
Bader
rule
sure
this.
B
B
A
B
We
will
probably
at
the
same
time
we
announce
duplication
in
114,
announced
also
deprecation
of
the
old
policy
check,
so
that
would
give
at
least
who
really
says
possibly
before
I
need
to
look
at
where
it
would
fall
on
the
policy.
But
yeah
eventually
will
collapse
just
on
to
checking
permissions
in
the
policy.
Api
group.
A
C
That
was
me:
I
moved
this
from
discussion
to
announcements.
Unfortunately,
yes,
we
couldn't
make
it
today,
but
he
sent
out
an
email
to
the
Salaf
mailing
list
about
adding
a
sub
project
or
a
repository
for
the
working
group
multi-tenancy,
which
I
believe
is
a
sub
working
group
of
sagat's.
So
essentially
he's
asking
for
some
sagat's
sign-off
I'm.
It
seems
reasonable
to
have
a
little
repo
to
start
to
prototype
some
of
their
work,
so
I'm
Pro
this
adopting
this
repo
or
sponsoring
this
repo.
C
A
D
Cool,
let
me
try,
can
you
see
this
cool
all
right,
so
I
just
want
to
take
a
few
minutes
and
demo
our
back
look
up
and
our
bank
manager.
There
are
a
couple
projects,
open-source
projects
we
were
working
on
at
reactive
odds
at
reactive
ups.
We
just
we
get
to
work
with
a
lot
of
different
organizations
and
see
how
they're,
using
our
back
and
authorization
and
kubernetes,
and
we
saw
a
lot
of
really
consistent
challenges
with
it.
So
we
came
up
with
our
back
looked
up
and
our
bank
manager
as
tools
to
try
and
help.
D
I
don't
know
if
they
do
but
Ted.
That's
that's.
Why
I'm
here
trying
to
get
some
feedback
so,
first
off
our
back
look
up
and
the
idea
behind
this
is
just
a
really
simple
CLI
that
I
think
of
as
a
reverse
lookup
for
our
back.
So
let
the
reverse
phone
book
phone
number
lookup
way
back
in
the
day.
That's
my
idea
here
and
to
have
great
off.
You
need
to
actually
understand
it
and
be
able
to
see.
D
What's
going
on
and
the
idea
with
our
back
lookup
is
you
just
enter
a
name
and
it
shows
you
any
kind
of
subjects.
Any
are
back
subjects
that
have
access
have
any
kind
of
roll,
binding
or
cluster
roll
binding
in
your
cluster.
And
of
course,
if
you
do
a
broader
query,
like
example,
you're
going
to
get
any
subject
that
matches
that
in
this
case,
they're
all
emails,
so
anything
matching
that
email
is
going
to
come
back
with
a
result.
D
Here
you
see
what
what
role
they
have
and
what
namespace
or
if
it's
cluster,
wide
that
level
of
access
and
then
finally,
like
any
good,
kubernetes
CLI,
you
can
get
wide
output,
so
you
can
see
exactly
the
cluster
roll
binding
of
role
binding.
This
off
is
being
granted
by
and
then
on
the
far
left.
The
other
addition
is
that
you
can
see
the
type
of
subject,
whether
it's
your
user
service,
account
or
group,
and
that
was
great
for
a
dot
one
release.
D
But
at
some
point
somebody
filed
an
issue
that,
like
they
were
clearing
all
the
stuff
and
gke,
they
still
had
access
in
gke,
because
I
am
matters
there
too.
So
now
there's
this
gke
flag.
That
shows
you
related.
I
am
to
that
user,
so
you
can
see
Joe
at
example.com.
Has
this
I
am
role
for
it
and
similarly
bitly
you
can
get
wide
output,
so
I
am
role
container
viewer
specific
to
that
I
am
access.
So
that's
like
the
very
very
brief
intro
to
our
back
lookup.
It's
a
really
simple
tool.
D
D
F
D
A
D
D
Alright
I'll
keep
on
moving
our
back
managers
a
bit
more
involved
here,
because
it's
an
operator,
it
simplifies
our
back
management
and
I.
Think
the
parallel
use
case
that
we
were
thinking
of
when
we're
developing.
This
is
pods
and
deployments.
So
as
a
really
simple
example,
here,
pods
can
be
deployed
on
their
own,
but
they're
a
bit
of
a
pain
to
work
with
at
any
kind
of
scale.
D
D
It's
a
list
of
our
back
bindings
and
each
our
back
binding
can
have
a
list
of
subjects.
Cluster
roll
bindings
and
roll
bindings
and
those
roll
bindings
have
a
namespace
and
cluster
role
or
role,
and
the
cluster
roll
bindings
just
have
a
cluster
role.
So
in
this
a
simple
example,
we
have
Jane
who
has
cluster
admin,
access
and
Joe,
who
has
edit
access
and
web
and
view
access
an
API.
So
very,
very
simple
example.
D
But
if
we
go
ahead
and
apply,
this
auerbach
manager
is
going
to
create
everything
for
us,
which
is
not
that
exciting,
because
we
can
do
that
already
with
roll
bindings
and
everything
just
works.
This
is
a
bit
more
concise,
but
that's
about
all
we've
gotten
so
far.
The
real
reason
that
starts
to
become
helpful
is
if
you're,
trying
to
automate
this
with
something
like
CI.
If
you're
trying
to
build
this
into
a
CI
pipeline,
that's
really
difficult
without
some
kind
of
parent
resource
like
this.
D
So
in
this
case,
let's
say
that
Jo
now
wants
edit
access
instead
of
view
access
and
the
API
namespace.
We
just
make
that
single
change
and
we
apply
it
and
our
back
manager
goes
ahead
and
makes
the
change
for
us
by
deleting
and
creating
a
new
role
binding
and
then
finally,
simple
deletions,
if
you
just
want
to
remove
that
access
entirely.
Remember
that
an
our
back
definition
effectively
owns
role
bindings,
so
it
knows
what
it
should
have
and
then
anytime
an
are
back
definition.
D
Update
comes
through
that
compares
the
current
state
with
the
desired
state
and
makes
B
changes.
So
we
remove
that
role
binding
and
just
apply.
The
are
back
definition
and
our
back
manager
goes
ahead
and
deletes
that
extra
role
binding
that's
no
longer
desired,
and
then
the
last
feature
that
I
want
to
cover
here
is
label
selectors.
This
is
kind
of
a
new
thing
that
we
added
pretty
recently
and
that's
something
that
that
came
out
of
the
desire
for
ephemeral
namespaces.
D
We
have
a
lot
of
customers,
a
lot
of
organizations
that
were
working
with
that
want
to
just
spin
up
an
ephemeral
namespace
and
give
a
group
a
team
access
to
it.
So
any
any
feature:
branch
as
an
example
has
an
ephemeral,
namespace
associated
with
it.
With
label
selectors,
you
can
just
say
any
namespace
matching.
This
selector
gets
this
level
of
access,
while
these
users
get
access
to
it.
So
in
this
case
we've
got
a
namespace
selector
for
a
specific
label
team
equals
web.
We
create
a
demo
namespace,
we
label
it.
D
With
that,
you
can
see
the
role
bindings
created.
We
changed
that
label.
You
can
see
the
role
bindings
deleted,
really
really
simple
functionality,
but
it
has
been
helpful
for
that
kind
of
ephemeral,
use
case
and
probably
others
that
I'm
not
quite
aware
of
yet.
So
that's
all
there
is
with
our
BAC
manager
any
questions,
any
feedback.
B
That
looks
really
cool
I
things
like
this
are
exactly
the
type
of
thing
that
I
like
to
see
getting
built
using
the
are
back
stuff
as
primitives.
So
that's
very
cool
I'm
curious
how
how
you
go
about
coexisting
with
liking,
other
things
using
the
same
primitives
just
under
the
covers.
Does
it?
How
does
our
bike
manager
know
which
things
it
owns?
Oh.
C
D
D
C
D
D
One
of
the
things
I
would
say
was
just
the
the
frustration
around
everything
else
in
kubernetes
is
really
easy
to
automate
as
an
example,
everything
is
really
easy
to
just
plug
into
a
CI
pipeline
and
just
let
go
and
our
back
just
doesn't
fit
those
models
because
you
just
can't
apply
an
update,
a
roll
binding
as
an
example
or
especially
for
revocation.
If
you
want
to
revoke
access,
you
can't
just
remove
a
file
from
a
really
simple
CI
pipeline.
Just
see
it
go
away
like
there's.
D
That
was
one
of
the
things
that
I
found
confusing
and
the
other
thing
that
and-
and
that's
not
really
a
specific
to
our
back.
That's
just
some
challenges.
If
you're
trying
to
automate
that
and
then
the
other
thing
that
I
think
is
relevant
here
was
just
the.
What
we've
seen
over
and
over
again
is
how
do
I
have
like
what
access
do
I
have
in
this
cluster
or
what
access
does
X
user
have
in
this
cluster?
So
we
tried
to
solve
those
but
I
would
say
impartial
solutions
that
could
use
improvement,
so
yeah.
A
D
F
I
think
on
original
label
selector
on
namespace
concept,
I
know:
we've
had
issues
thinking
through
the
echo
model
around
using
labels
inside
of
our
back.
The
only
using
about
namespaces
makes
it
a
little
nicer
because
you
assume
the
namespace
administrative
control
could
get
you
access
to
its
name
space
anyway.
I
think
the
one
things
still
open
is,
if
you're,
if
you're
able
to
modify
one
of
these
auerbach
definitions,
you
can
maybe
claim
a
label
on
a
namespace
that,
maybe
you
didn't
want
again.
D
That
this
model
does
not
scale
with
like
letting
people
grant
access
at
a
namespace
level
that
don't
have
cluster
admin.
Our
back
that
our
back
manager
requires
cluster
admin.
Our
back
definitions
are
custom
resources
and
by
default
are
generally
granted
as
cluster
admin.
So
they
it
yet
it
doesn't
scale
really
well.
If
you're
yeah
I
mean,
if
you,
if
you
had,
if
you
have
an
access
to
modify
our
back
definitions,
you
might
as
well
have
cluster
admin.
That's
what
it
comes
down
to.
A
D
The
I
mean
it's
been
great
label,
selectors
are
the
newest
version
and
the
newest
iteration
and
those
are
definitely
a
concern
for
performance.
I
have
not
tested
on
what
I
would
call
massive
clusters,
so
I
can't
say
for
sure,
but
that
you
know
within
a
reasonable
scale.
They
they've
been
working.
Fine,
so
I
I
know
that's
not
a
complete
answer
there,
but
yeah.
F
B
Some
things
are
new
features,
it
didn't
exist
and
now
it
does
there
we
go
now.
I've
covered
all
possible
customer
sources,
weren't
providing
correct
metadata
because
they
were
getting
encoded
properly
for
in
Auto
buttons.
So
you
dependent
on
that,
you
might
have
noticed.
I
was
broken
a
controller
manager
using
rotatable
tokens
Mike.
You
want
to
talk
about
that.
One
yeah.
C
This
is
migrating
the
controller
manager
to
using
token
request
API,
instead
of
what
it
did
before,
which
is
to
create
a
service
account
per
control
loop,
essentially
and
pull
the
secret
out
that
it
generates
from
the
token
controller.
So
this
is
work
along
the
path
to
phase
and
token
request,
as
the
replacement
for
tokens
generated
in
service
counter
secrets.
C
This
will
be
enabled
as
currently
written
in
in
the
PR.
This
will
be
enabled
when
a
token
request,
api's
are
detected
to
be
enabled
on
the
API
server,
and
we
currently
have
those
API
is
enabled
on
the
generally
on
all
end-to-end
tests.
I
think
there
was
an
open
question
about
whether
and
to
end
tests
are
long
enough
to
to
exercise
the
refresh
code
paths
when
tokens
expire
right
now
the
expiration
is
or
the
TTL
of
these
tokens
are
an
hour
in
the
in
the
current
PR.
So
I,
it's
a
step
in
the
right
direction.
C
B
We,
if
we
can
exercise
the
rotation
path
well,
then
I
think
it's
fine
to
go
ahead
and
bring
in
in,
and
the
comment
about
making
a
robust
to
service
account
deletion.
If
you
look
at
the
existing
way,
we
build
clients
for
controllers,
they're,
actually
really
vulnerable
to
disruption,
if,
like
the
token
that
they
created
at
initialization
time,
gets
deleted
that
controller
just
spins
with
401
errors
until
you
shut
the
watchman's
down.
A
E
B
Yeah
I'm
gonna
be
my
next
next
question:
hey
I
think
this
is
an
incremental
step
in
the
right
direction.
It
makes
the
controller
manager
more
robust
than
it
was.
It
gives
us
a
way
to
tie
in
things
like
responding
to
revocations
more
quickly
in
the
future
yeah
I.
If
we
exercise
the
rotation
path
well,
then
I
think
it's
undo
to
get
in
so
I,
don't
know
if
that
means
shortening
it
from
an
hour
to
half
an
hour.
B
C
B
Right,
let's,
let's
think
of
this
thing
just
today,
and
we
can
figure
out
upsells
good.
C
E
C
E
I
just
wanted
to
close
to
to
see
if
there
was
some
way
to
close
this
out
one
way
or
another.
So
there
was
some
a
lot
of
discussion
on
this
proposal
as
to
basically
whether
it
would
be
better
to
provide
a
not
necessarily
valid
Oh
IDC
discovery
document
at
the
OEC
endpoint
I
had
suggested
an
alternative
which
was
to
have
a
similar
but
not
entirely
bad
thing
at
a
different
path,
and
it
seems
like
there's,
not
closure
on
this.
So
I
guess.
E
My
question
is
like
what
is
the
path
that
we
should
do
to
get
closure
on?
How
to
do
that?
I
I
have
a
private.
You
know
a
private
branch
at
the
moment
that
implements
one
of
these
and
I'm
happy
to
like
contribute
that
back
based
on
whatever
the
outcome
here
is,
but
I
kind
of
want.
You
know
the
proposal
to
be
solid
before
doing
that.
C
B
C
A
A
E
This,
at
the
same
time,
this
is
sort
of
like
I
feel
like
this
is
something
that's
missing
from
from
the
flow
right.
If
I
don't
want
to
publish
how
I
get
this
token
or
the
way
that
I
get
this,
this
token
isn't
isn't
this,
but
it's
otherwise
compatible
right,
there's
not
a
way
to
publish
just
develop
it.
B
B
Come
up
with
like
a
concrete
list
of
here's,
what
it
would
take
to
publish
something
that
wouldn't
cause
a
random
spec,
compliant
verifier
to
crash,
because
we
were
missing
a
field
that
you
know
field
was
null
when
it
should
be
not
null
figuring
out
how
weird
it
would
have
to
be
to
be
valid.
That
would
be
what
I
would
want
to
do.
First,
I,
don't
think
publishing
a
thing
at
a
different
URL
is
going
to
get
us
all
event.
What
we
wanted
from
this
that's.
C
This
has
been
tested
against
a
couple.
Oh
and
you
see
the
up,
validators
or
clients,
and
it
it
seems
to
work
fairly
well
against
the
ones
that
I
spot
checked.
I.
Think
if
we
have
the
authorization
endpoint
be
an
actual
URL
that,
like
returns,
403
or
404,
most
clients
are
never
gonna.
Actually
query
that
there's
not
a
good
reason
and
I
think
that
if
we
move
the
programmatic.
C
B
C
B
A
C
D
C
B
B
B
We
thought
it
would
be
good
to
take
a
step
back
and
if
you
look
at
some
things
that
haven't
been
as
structured
or
haven't
been
haven't
gotten
the
attention
they
need
over
the
past
few
months
or
a
few
releases,
and
so
two
pretty
good
examples
are
like
milestone,
planning
and
backlog
triage.
Whether
that's
issues
report
requests,
so
the
first
like
milestone,
planning,
is
kind
of
looking
ahead
and
saying
for
the
next
release
or
the
next
month
or
whatever
the
next
time
period
like
what?
What
are
our
priorities?
What
are
people
working
on?
B
B
So
there
was
a
link
to
the
way
cluster
lifecycle
has
been
doing
this
and
had
some
good
good
thoughts.
There
I
don't
know
if
people
had
a
chance
to
read
that,
but
we're
coming
up
on
the
end
of
114
click
freezes
tomorrow,
probably
a
week
of
people
putting
effort
into
stabilizing
stuff
and
flushing
stuff
out
and
then
we'll
be
thinking
about
plans
for
the
next
release.
And
so
I
think
it
would
make
sense
to
relate
about
our
next
meeting
to
115
planning
and.
B
Or
the
next
meeting
I
think
it
would
be
good
to
kind
of
go
through
all
the
sub
projects
that
we
have
and
say
what,
like
stack,
rank,
working
progress,
a
crank,
probably
word
use
and
say
like:
what's
top
priority
who's
working
on
it
and
how
much
are
they
working
on
it?
Are
we
trying
to
finish
something?
B
When
can
I
expect
these
things
to
make
progress
between
now
and
the
next
meeting,
I
yeah
I
think
it'd
be
good
to
list
out
our
some
projects
stack
rank
stuff
in
progress
and
what
it
is
plans
to
be
worked
on
in
115,
and
then
we
can
kind
of
take
a
look
at
the
big
picture
at
the
next
meeting
and
say:
does
this
seem
reasonable?
Are
these
things
competing
for
resources.
C
That's
both
like
feature
features
that
have
feature
Flags
api's
that
are
stuck
in
beta
having
an
idea
of
how
to
make
progress
on
those
and
figure
out
how
to
how
to
unblock
people
from
making
progress
like
through
being
a
paying
attention
to
reviews.
Making
making
sure
that
reviewers
and
approvers
are
accurate.
I
think
that
those
would
all
be
good
results
of
rethinking
of
this.
B
B
Would
be
helpful
just
in
general
like
because
a
lot
of
the
things
we
do
have
compatibility
implications,
and
so
it's
it's
not
just
a
matter
of
finding
the
time
to
do
the
work.
It's
a
matter
of
finding
the
time
to
do
the
work
and
then
wait
six
months
before
you
like
merge
the
pull
request,
and
so
knowing,
where
those
wait,
six
months,
chunks
fall
and
the
work
can
help
us
prioritize
things
like
oh
this
really
in
stab
in
a
114,
so
that
we
don't
block
ourselves
six
months
down
the
roads.
B
So
if
you
have
things
in
progress-
and
this
is
part
of
what
the
release
team
has
been
asking
us
to
do-
with
caps
to
get
like
road
maps
and
graduation
criteria
and
test
plans-
and
they
actually
be
more
disciplined
in
how
we
plan
out
work
for
a
feature
instead
of
just
and
it
works
well
enough,
it's
beta
I
can
use
it.
I'm
happy
I'm,
just
gonna,
let
it
sit
in
beta
forever.
B
The
other
thing
that
is
just
a
useful
thing
to
do
in
general
is
treat
housing
issues
and
pull
requests
that
come
in
and
so
github
makes
it
really
easy
to
look
for
things
labeled
with
sig
off
that
had
been
open
since
the
last
meeting,
and
so
a
useful
practice
I
think
could
be
to
pretty
quickly
sweep
through
things
that
got
opened
that
are
languishing.
We
have
sort
of
insane
numbers
of
feature
requests
issues
open
with
no
priority
assigned
some
of
them
very,
very
old,
so
I
put
a
few
example
queries
in
the
meeting
minutes.
B
The
first
couple
are,
the
types
of
things
I
think
would
be
useful
to
sweep
through
in
meetings
just
you're.
Here
the
issues
open
since
the
last
meeting
are
there
any
that
are
urgent
or
don't
have
owners
or
don't
have
priority,
and
so
it's
like
starting
to
get
a
handle
on
the
things
coming
in
would
be
a
good
first
step,
and
then
we
can
start
running
down
the
large
backlog
so.
B
B
C
B
B
Ideally,
this
triage
would
be
happening
throughout
the
week
I.
It
would
be
great
if
an
issue
didn't
sit
for
two
weeks
before
someone
looked
at
it,
I
think
our
meeting
here
it
is
probably
a
good
chance
to
make
sure
things
don't
escape
the
two-week
window
and
so
anything
that
hasn't
yet
been
triaged
or
assigned
or
at
assigned
priority
would
show
up
here
and
it's
like
a
forcing
function.
A
So
Jordan
or
Mike,
maybe
or
anyone
I'm
curious.
How
do
you
other
dreams
sort
of
track
this
kind
of
stuff
over
time
like
I,
could
see
like
a
Trello
board
or
something
with
like
swim
lanes
for
things
and
like
try
to
move
them
across
right
like
I?
Don't
I,
don't
see
how
like
a
Google,
Doc
being
like
a
good
like
visualize
it
for
what
folks
are
working
on
and
like
where
they
stand,
but
maybe
I'm
yeah.
B
B
I
get
hub
makes
it
pretty
low
and
they're
making
the
making
the
project
words
better.
So
you
can
really
easily
query
stuff
and
if
we've
learned
one
thing
in
this
project,
it's
that,
if
you
have
information
represented
in
two
places
at
least
one
of
those
places
will
be
out
of
date.
Possibly
both
of
those
places
will
be
out
of
date,
but
at
least
one
of
them
will
be,
and
so
whatever
we
can
do
to
avoid.
Denormalizing
issue
data
and
PR
data
and
stuff.
B
It's
like
Trello
that
autumn
on
sinks
issued
in
to
yours,
so
it
not
Auto
sinks,
but
storages
are
the
information,
so
you
can
filter
it.
The
same
way.
You've
built
their
issues
and
pairs.
You
can
query
things
and
drag
them
into
the
project
pretty
easily
yeah,
but
all
the
query
stuff
would
just
be
no
more
github
queries.
B
So
yeah
so
again,
this
is,
if
you
are
involved
in
the
sub
projects,
but
between
now
and
the
next
meeting
think
about
what
that
project
is,
is
doing
for
115
and
try
to
burn
through
feature
requests
and
for
bugs
there
aren't
really
that
many
bugs
there's
like
two
bugs
but
feature
requests
related
to
that
and
at
the
very
least,
assign
priority.
B
If
there
are
things
that
are
clearly
out
of
scope,
then
you
can
close
them
with
explanations,
but
but
yeah
that
would
be
really
helpful
for
getting
a
handle
on
115,
oh
and
what
Mike
said
about
like
mapping
out
things
that
are
blocking
things
that
are
in
progress
so
just
capture
current
state
help
us
understand
where
we're
at
with
things
that
are
in
progress.
B
My
node
label
example
I
have
a
pull
request
open
to
update
the
timeline
for
that
for
some
cleanup
things
that
we
found
that
had
pushed
out
some
of
the
stuff
one
at
least,
and
so
caps
are
a
good
place
to
kind
of
put
details
about
graduation
criteria
and
then,
as
you
get
further
into
implementation,
keep
that
updated,
like,
as
things
become
clearer
and
you
find
out
more
information
and
fold
that
back
into
the
document,
just
keep
it
updated.
So
there's
kind
of
one
place
people
can
look
to
see.
B
C
B
Ask
how
you
can
help
with
some
of
these
things,
even
just
identifying
the
issues
related
to
that
area
would
be
helpful,
like
that.
There's
a
lot
of
information
gathering
types
of
things
where
it's
like
sweep
these
80
things
and
put
a
list
of
the
things
related
to
this
area
here,
so
we
can
go
through
them.
C
C
A
All
right,
yes,
we
can
call
it
back
three
minutes.
We
did
thanks
everyone
for
attending
and
we
haven't
had
one
in
a
while
and
thanks
Jordan
for
sort
of
the
N
Mike
for
sort
of
getting
rid
trying
to
get
us
more
organization
in
the
future.
That
way,
we
can
kind
of
have
a
lot
of
value
from
these
meetings.