►
From YouTube: Kubernetes SIG Auth 20181017
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20181017
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
Sure,
as
we
talked
about
last
time,
I'm
gonna,
step
down
from
stegall's,
chair
and
I
nominated
know
who
was
willing
to
do
cherry
things
and
feedback
on
that
was
good,
so
that
merged
yesterday
I
think
as
I
opened
up
the
kind
of
follow-up
thread
about
finishing
up
the
sub-project
PR,
that's
still
in
progress,
so
hopefully
we
can
get
that
worked
through
and
get
our
actual
projects
and
work
items
and
things
enumerated.
But
for
now
Moe
can
help
with
organization
and
uploading
videos
and
running
meetings
and
stuff.
So
congratulations,
yeah.
A
A
Your
mic
is
a
little
broken,
I
think
or
not
worth
I'm
like
you're.
C
B
A
B
There
is
work
in
progress
right
now,
around
topology
updates
for
things
like
CSI
drivers
that
want
to
start
having
drivers,
add
topology
labels
to
nodes
which
can
be
okay,
but
we
want
to
make
sure
that
if
that's
done,
it's
done
intentionally
instead
of
kind
of
accidentally
introducing
self
labeling
updates
and
then
a
release
later,
realizing
that
this
is
not
backwards,
compatible
behavior
that
we
have
to
like
honor
and
not
ever
break.
So
this,
the
PR
linked.
B
Keeps
nodes
from
updating
or
adding
labels
outside
the
standard
default
set,
so
today
they
don't
do
that.
The
only
labels
they
update
are
the
operating
system.
Architecture
zone
region
was
less
set
up
like
six
or
seven
labels
that
they
modify,
and
so
we
want
to
keep
them
to
that
set
until
we
figure
out
how
to
allow
additional
ones
in
a
controlled
way.
B
So
this
is
this
is
a
trying
to
try
and
put
a
stake
in
the
ground
and
saying
here's
where
we're
at:
let's
not
go
further,
without
considering
how
we're
gonna
authorize
this.
So
that's
what
this
PR
is.
The
community
911
issue
my
cup
and
a
while
ago
is
still
trying
to
explore
what
possible
methods
we
would
use
for
describing
this
set
of
labels
with
the
Senate
level.
Prefixes
is
fine
for
giblets
to
modify
that
we're
trying
to
sync
up
with
Sigma
and
six
storage
on
what
their
intended
use
cases
are.
A
A
A
A
Unfortunately,
considering
that's
not
the
way
the
labels
are
today,
I
think
that
might
be
problematic.
Well,
there
are
no
CSI
added
labels.
There
are
no
society
labels.
My
understanding
was
that
they
had
already
picked
the
label
scheme
in
that
they
had
deployed
it.
Is
that
not
the
case?
That
is
my
understanding,
but.
B
B
B
B
A
B
Well,
that's
true:
once
we
no
longer
let
them
delete
themselves.
Yeah.
A
B
Okay,
where
do
we
want
to
coordinate
communication
discussion
around
the
the
config
stuff?
Do
we
want
to
do
it
still
around
911
or
do
we
want
to
have
a
meeting?
They
seem
I
mean
I,
know
time
for
113
is
short.
It
seems
like
we
should
probably
get
storage
and
node
and
off
folks
who
are
interested
like
together
to
talk
through
this
and.
A
A
A
A
Plumb
server
context
down
to
authenticators
and
to
expand
the
return
value
to
support,
returns,
returned
information
outside
of
the
authentication
and
user
the
user
info.
So
we
want
to
plumb
context
to
things
that
I
think
are
valuable,
that
we
get
by
a
plumbing
context.
Is
we
at
propagation
of
of
cancellation
to
the
web
hook
Authenticator
and
the
IDC
Authenticator,
which
both
do
and
do
Network
calls
so
and
the
the
big
one
is?
We
can
plumb
through
an
audience
which
is
the
expected
audience
of
the
authentication
call.
A
So
this
is
will
be
useful
for
supporting
a
token
review
for
I
took
in
review
for
audiences
that
are
not
the
API
server
so
right
now
we
in
the
audience
aware
authenticators.
We
assume
that
the
audience
is
the
API
server
audience
and
in
token
unaware,
authenticators.
We
just
authenticate
anything
in
our
audience.
So
this
is
problematic.
A
We
want
to
move
to
a
place
where
token
aware
authenticators
only
authenticate
tokens
that
when
the
audience
is
the
API
server
and
that
token
aware
audiences
have
enough
information
to
authenticate
tokens
for
multiple
audiences,
such
as
a
vault
audience.
If
the
authentication
happened
through
a
token
or
via
flow
from
vault
yeah,
so
I
am
breaking
up
a
really
big
PAPR
that
slipped
in
111
and
then
I.
That
I
didn't
make
much
progress
on
in
112,
and
this
is
a
piece
of
it.
It's
a
pretty
big
change
because
it
changes
a
large
depended
on
interface.
A
Essentially,
this
is
a
minor
improvement
right
now,
if
you
send
a
bunch
of
authentication
requests
to
the
API
server
and
you
control,
C
or
whatever.
If
you
are
using
the
web
hook,
Authenticator
those
those
back-end
rpcs
will
not
be
cancelled
because
we
don't
probably
get
cancellation.
So,
ideally,
we
would
cancel
the
back
in
our
PCs
and
propagate
that
cancellation
beyond
passed
the
web
hook
in
that
circumstance,
but
it's
a
minor
improvement
compared
to
probably
probably
getting
audience,
expect
audience
to
the
authenticators
yep.
Okay,
thanks.
B
C
C
A
B
B
C
C
B
A
Yeah
we've
also
in
in
internally
in
our
current
internal
authentication
system,
we're
walking
back
a
bunch
of
attributes
that
we
exposed
initially
in
in
the
in
this
in
a
similar
proto,
hey,
ended
up
causing
a
bunch
of
issues
because
we
had
a
bunch
of
clients
of
authentication
of
the
authentication
system
depending
on
internal
features.
Opening
these
things
up,
implementing
ad
hoc
I
think
is
a
shin
systems,
an
ad
hoc
logging
systems
based
on
them.
A
We,
it
made
it
difficult
for
us
to
to
eventually
that
that
craft
built
up-
and
it
made
it
difficult
for
us
to
make
broad
changes
to
authorization
just
because
you
would
have
to
go
fix
every
single
client
I'm,
not
sure.
If
that's
something
we
want
to
consider
here,
we
should
probably
consider
it.
It
might
not
mean
that
might
not
have
the
same
issues
in
communities,
but
yeah
I
would
tend
to
recommend
caution
when
adding
to
the
extra
info.
A
A
This
paves
the
way
for
us
to
sub
in
a
config
map
projection.
Once
we
have
the
config
map
controller
emerged,
which
somebody
is
working
on
right
now
and
once
we
have
the
token
request
project
our
token,
what
does
it
sort
of
count
Chuck
in
projection
in
beta
for
two
or
three
releases
or,
however
long
we
wait?
We
can
just
sub
in
a
service
count
took
in
projection
and
we
will
no
longer
have
use
for
the
secrets.
A
E
A
Can't
possibly
this
is
this
I,
don't
think
we
can
make
decisions
based
off
of
the
project
it
like
we
can't
say.
Well,
we
have
these
compatibility
guarantees,
but
somebody
is
doing
something
where
they
were
running
one,
not
a
cluster
notes
against
1.15
API
servers
that
that
is
not
a
good
reason
to
not
advance
the
health
of
the
general
project.
I
agree.
E
So
I
wasn't
arguing
against
making
this
the
default
and
pushing
on
this
and
I'm
not
arguing
for
making
gke
try
any
of
these
decisions.
I
was
just
saying:
anecdotally.
Gk,
you've
seen
some
stuff
like
this
wondering
it
exists
elsewhere,
and
should
we
provide
some
flexibility
if
possible
right?
So
maybe.
B
We
have
similar
there's
a
similar
thing,
came
up
with
Damon
set
scheduling
where
basically
a
113
113
master.
Very
sorry,
a
113
scheduler
will
try
to
schedule
datasets
using
API
field
that
only
111
cubelets
know
about,
and
so
it's
like.
What's
the
release
note
for
that
look
like
does
it
look
like
only
111
cubelets
will
work
with
113
API
servers,
because
we
support
two
versions
and
we
really
meant
it.
A
guy
I
mean
it.
It's
kind
of
reminding
people
that
this
is
the
supported
window.
A
B
B
E
B
Most
of
the
questions
I
had
around
the
change
were
around
like
the
performance
and
feature
capabilities,
so
just
double.
Checking
with
storage.
Six
towards
that
protected
volumes
do
all
the
same
things
we
currently
get
from
secrets
like
live
updating
values
and
how
they
deal
with
read-only
values,
and
things
like
that.
I
think
all
of
those
are
fine,
but
they.
A
C
A
B
A
B
You
pick
a
fixed
name,
then
that
name
is
an
API
yeah.
If
we
don't
intend
for
it
to
be
an
API,
then
we
should
not
in
it
yet
right.
No
permanent
Reverend
am
name.
If
you
have
a
random
name,
no
one
can
depend
on
it.
So
that's
why
we
have
the
freedom
to
stop
injecting
this
randomly
named
secret
volume
today,
because
people
we
know
people
aren't
depending
on
it,
because
it's
different
in
everyone,
we
know.
No
one
has
manifests
that,
like
have
volume
mounts
that
reference,
this
volume
that
we
currently
inject
so.
A
A
To
disable
auto
mounting
I,
don't
know
how
that's
gonna
happen.
I
don't
really
want
to
have
the
conversation
about
it
now,
because
I
think
it's
gonna
be
a
huge
conversation,
but
the
case
where
we
do
turn
off
auto
mounting
people
can
use
the
static
name
to
inject
the
access
token
into
positive
they
care
about,
without
with
while
also
having
portability
so
right.
Now.
You
can't
actually
do
that
portably,
because
that
name
is
generated.
A
B
F
Yeah,
no
and
I
had
a
long
conversation
yesterday
about
like
this
whole
topic,
and
we
were
talking
more
about
the
the
API
of
the
secrets
and
tokens
we
create
less
than
the
amount,
but
I
really
do
prefer
to
very
intentional.
We
should
intentionally
walk
into
creating
new
api's
like
our
three
inside
pod
api's
that
are
implicit.
Our
service
links
the
token
the
contents
of
the
secret
dirt
and
and
I
keep
forgetting
what
it
is
we
have
to
in
implicit,
accidental
ones,
and
both
of
them
were
like.
Oh
wow.
F
B
F
So
the
question
one
of
the
things
mo
and
I
discussed
your
stay
with
touches
on
the
API,
is
like
the
fact
that
we
generate
a
token
even
with
a
random
name.
That's
accessible
by
a
service
account
as
the
first
link
right
get
the
services
get
the
token
for
the
service
account.
We
have
that
behavior
and
extended
tests.
We
have
these
various
people
out
there
who've
done
things
like
King
up
this
great
that
they
should
use
for
a
service
account.
F
A
F
F
We
don't
cover
it
as
part
of
conformance
today,
but
conformance
doesn't
cover
a
lot
of
things
that
would
break
people
if
they
changed,
and
so
I
think
this
is
just
a
really
like.
This
is
a
discussion
that
I
don't
wanna,
take
the
cig
art
until
we
kind
of
think
what
we
reasonably
Bill's.
The
answer
we're
gonna
make
the
world
a
better
place,
but
you're
gonna
break
some
people
on
the
way.
A
We
would
never
take
CA
data
out
of
the
secrets.
I
expect
that
we
would
stop
reading
the
secrets
as
they
exist
today,
all
at
once.
I
am
not
sure
how
that
migration
looks
right
now.
I
think
it's
important
to
think
about,
however,
that
I
agree
that
it
might
require
an
API
version
bunk
if
that's
kind
of
what
you're
saying.
F
F
There's
nothing
like
would
we
changed
how
like
replication
in
controllers
like
label
selectors
on
services,
like
services
still
had
the
old
label?
Selector
format
right,
you
can't
do
match
expressions
or
match
expressions,
but
replica
sets
can
use
that
and
deployments
can't
and
but
we
didn't
fix
services.
So
it's
another
like
we
went
to
this
whole
big
discussion
about.
Should
we
break
people,
we
decided
not
to
break
people.
Is
this
different
or
the
same,
but.
A
F
A
user
of
the
clock,
what
an
administrator
of
the
cluster
make
that
distinction,
yeah
I
agree
like
I
I,
agree
with
what
we're
trying
to
do
we're
trying
to
make
all
this
better
because
it
was
implicit
thing
we
just
have
never
done,
we
haven't.
We
don't
have
a
good
rule
dumb.
How
do
we
build
those
rules?
How
do
we
build
like
the
criteria
that
we
use
to
make
this
decision
and
make
sure
that
people
aren't
broken,
that
we've
justified
it.
B
And
and
doing
it
over
a
long
enough
period
of
time
communicated
well
enough,
probably
with
when,
when
we
have
the
ability
to
turn
off
the
auto
created
secrets
like
having
the
ability
to
turn
that
off,
probably
before
we
do
it
by
default,
saying
this
is
the
thing
we'd
like
to
do?
If
you
want
to
run
this
way
to
turn
this
on
or
when
you,
when
you
opt
into
doing
token
generation,
you've
opted
into
this
I'm,
not
sure
how
we
would
how
we
would
do
it,
but
then
giving
people
a
way
to
say
it
does.
F
Like
so
there's
a
couple
examples
and
like
open,
shifts,
open
chef,
there's
a
helper
CLI
command-
that's
like
hey
I,
want
to
get
a
token
for
the
service
account,
because
it's
the
thing
that,
like
99%
of
people,
do
we
never
put
that
with
it.
I
never
got
proposed
as
a
cube
thing,
but
the
heuristic
it
did
was
get
it's
the
same
thing
that
extended
test
do
get
the
first
service
account
secret
token
off
of
the
service
account
and
that
I
know
a
lot
of
people
use
in
automation.
F
That
is
not
impossible
to
go
recreate
in
a
number
different
ways,
and
so
I'm,
just
like
God
would
be
there's
a
bunch
of
people
out.
There
have
done
that
in
subtle
ways.
Unfortunately,
it'll
fail
pretty
fast
for
them.
Eventually,
when
we
switch,
is
there
an
analogy
here
to
both
our
back
and
pod
security
policy,
which
is
turning
our
back
on
broke?
It's
funny
how
all
this
comes
out
of
cig
off
I
feel
like
we're.
F
F
Deployment
operators
took
that
on
themselves
to
break
their
customers
because
the
trade-off
was
they're,
so
cube
made
the
distinction
that
we've
offered
this,
but
it
is
not
a
default.
You
must
opt
into
it
and
then
same
people
opt
into
it
because,
of
course,
security
is
worth
a
little
bit
of
pain
that
the
rationale
I
mean.
There's
a
reason.
F
B
The
security
thing
like
we,
we
would
like
to
see
that
happen,
but
I
can
I
could
see
letting
people
opt
into
it.
I
think
the
hard
the
hard
call
is
going
to
be
for
like
people
who
set
up
clusters
on
other
people's
behalf
so
which
should
cube
Adam.
Do
you
know
what
should
cops
in
open
just
she's
like?
Should
they
turn
this
on
they're?
Not
the
ones
who
are
gonna
be
impacted
by
it
necessarily
do.
F
We
should
we
write
up
like
the
distinction
that
we're
trying
to
draw
here
between
an
implicit,
explicit
and
behavioral
API,
which
is
like
hey
our
learnings.
Are
we
have
these
explicit
api's
that
we're
not
breaking?
We
are
implicitly
breaking
this
in
there's
behavioral
break
and
here's.
Why
we're
choosing
that
to
make
this
better
in
the
future,
for
other
people
to
reason
through
yeah.
B
I
mean
the
different
Cajun
policy
talks
about
like
behavior,
changing
behavior,
invisible
ways
and
kind
of
the
timeframe.
It
doesn't
say
you
can't
do
it.
It
just
says:
here's
here's
the
time
bringing
up
like
you
have
to
communicate
it
and
announce
it
and
like
get
people
a
heads
up
and
say,
if
you're
doing
X,
you
must
start
doing
Y
by
this
date,
I
mean
that
if
we
want
to
start
like
once,
we
have
the
sort
of
the
new
way
available
for
people
to
switch
to.
B
We
can
tell
people
like
if
people
are
using
kind
of
following
these
implicit
links
today
to
obtain
credentials
to
use
like
first
in
CI
system
or
something
they
should
really
be
explicitly.
Creating
a
secret
and
saying
I
want
I
want
to
credential.
Please
fill
this
and
then
obtain
it.
That
way
like
we
could
start
telling
people
to
do
that
now.
B
I,
don't
know,
I,
think
the
big.
The
big
thing
is
communication
and
doing
it
over
a
long
enough
time
period
that
there's
time
for
people
to
hear
the
communication
to
react
to
it
and
kind
of
understand
the
impact
on
them
and
make
changes
before
we
pull
the
rug
out
from
under
them.
I
don't
want
to
do
that.
I'd.
A
Also
like
to
understand
the
difference
between
an
implicit
API
and
an
implementation
detail.
If
we're
gonna
go
through
the
that
process
up
until
last
week,
you
can
send
ssh
authentication
essage
to
live
ssh
server
and
you
would
be
authenticated.
Is
that
NAB
hi
yep
contrived
example?
I,
don't
know
if
you
guys
saw
the
CV
I,
but
yeah
I
think
there's
a
there
are
fuzzy
lines
that
I
don't
understand
and
right
now,
there's
opinions
about
them
and
I.
F
Have
a
feeling
this
is
a
great
example
of
us
clarifying
what
we
consider
an
API
and
getting
the
language
around
it
tightened
up,
so
that
we
have
air
cover,
but
also
demonstrating
how
we
communicate
to
users,
because
this
is
like,
like
I,
think,
along
with,
like
turning
on
pod
security
policy
by
default
or
something
or
operators.
Turning
on
this
would
be
probably
one
of
the
bigger
implicit
behavior
changes
that
done
our
back
then
PSP
than
this
I
agree.
A
E
A
The
the
delegation
is,
this
actual
persisted
object
are
the
in
the
in
the
case
of
the
explicit
Authority
delegation
and
say
objects
stored
in
at
CD
that
has
a
set
of
permissions
with
an
end
user
principle,
maybe
not
the
end
user
principle.
Maybe
the
terminal
principle,
the
creator
of
the
initial
delegation
and
the
delegates
and
the
delegates
can
use
some
set
of
permissions
associated
with
delegation.
The
idea
is
you
have
this
terminal
principle:
it
creates
us
it.
A
It
extracts
a
set
of
permissions
from
its
overall
authority,
enhance
that
some
permissions
off
to
a
friend
to
take
actions
on
on
their
behalf.
So
in
the
case
of
an
end-user
creating
of
replica
set,
they
would
give
the
replica
set
permission
to
create
pods,
which
they
have,
and
the
replica
set
could
go
off
and
create
pods
that
those
permissions
can
be
attenuated
by
a
namespace.
A
So
we
are,
we
are
restricting
authority
of
individual
sink
loops
and
isolating
individual
sink
loops
and
I.
Think
a
really
good
situation
to
be
would
be.
You
cannot
a
replica.
A
replication
controller
process
cannot
create
namespaces.
We're
replica
sets
are
not
don't
exist.
We
can
have
a
helm
deployment
that
is
shared
across
the
cluster
and
if
you
are
not
using
that
helm
deployment,
you
are
your
namespace
is
not
manageable
by
helm.
A
Moving
from
this
model,
where
we
have
this,
these
controllers,
with
unilateral
permission
to
with
basically
route
in
cluster,
to
very
scoped
a
special
purpose,
purpose
permissions
I,
think
that
protects
us
against
both
bugs
and
controllers,
where
they
can
can
be
tricked
into
misusing
their
unilateral
authority
and
also
the
problems
with.
If
the
helm
deployment
is
some
somehow
you
are
able
to
exfiltrate
credentials.
You
limit
the
scope
of
what
of
what
that
help
controller
can
do
so.
A
These
Authority
delegations
are
have
that
end-user
principle
delegates
and
that
authority
delegation,
a
checker
or
an
authorizer
of
that
uses,
is
authorizing.
An
authority
delegation
would
check
the
permissions
are
granted
by
the
authority
delegation
check
that
the
authenticated
user
is
allowed
to
use
the
authority
delegation
in
the
list
of
Delegates,
and
that
is
would
be
the
selected
Authority
for
the
specific
action
taken
by
the
controller,
and
you
can
there's
a
process
for
creating
multiple
delegations
from
a
single
delegation.
E
E
A
So
I
think
there's
a
couple
ways
to
handle
these
scenarios.
I
would
like
to
garbage
collect
unused,
Authority
delegations.
So
suppose
you
have
an
a
delegation
that
hasn't
been
used
in
two
weeks
or
a
month.
We
should
delete
it
or
expire.
It
I
think
the
act
of
using
it
is
is
enough
to
say
that
we
should
keep
this
alive.
I
want
to
avoid
situations
where
you
have
a
team
member
who
creates
a
replica
set
that
team
member
is
deauthorized
and
the
replica
set
is
becomes
unmanaged
or
unmanageable
by
the
replica
set
controller.
A
However,
I
would
like
the
audit
to
audit
log
to
express
information
of
the
of
the
authority,
of
which
the
replica
said
is,
is
being
managed,
so
I
would
expect
that
in
the
audit
log
you
would
see
well,
this
user
has.
This
administrator
has
left
the
team,
but
we
have
traces
of
actions
being
taken
on
their
behalf
still.
A
Similarly,
if
you
do
a
list
of
the
authority
delegations
which
are
persisted
objects,
you
can
see
which
traces
of
their
which
authority
delegations
exist
that
lead
back
to
them.
So
authority
delegation
is
a
permission
check
at
a
point
in
time
that
grants
a
set
of
permissions
to
a
new
principal
they
are
revocable
and
that
you
can
just
keep
controlled,
delete.
A
The
authority
delegation,
if
you
so
choose,
and
they
will
hopefully
expire
and
will
be
garbage
collected
I
think
potentially
deleting
a
replica
set,
is
a
good,
would
be
a
good
time
to
delete
Authority
delegated
on
the
creation,
roughly
said,
which
is
not
explored
in
the
kept
yet.
But
I
can
certainly
add
that.
E
In
my
namespace,
you
lose
the
other
pieces
which
are
slightly
more
protection
against
confused
deputy,
where,
like
even
in
that,
you,
you
could
just
accidentally
go
to
a
different
namespace.
That
is
also
using
it
and
do
the
wrong
thing,
whereas
it's
slightly
harder
to
do
that,
if
you
also
have
to
carry
along
the
right
authority
selector-
and
you
also
don't
get
the
nice
auditing
thing
so
I
think
there
are,
there-
are
benefits
to
exploring
this
I
was
wondering
if
it.
If
there
are
any
explicit
authorization
guarantees
that
we
get
out
of
it,
though,
what.
A
Aren't
the
two
statements
that
you
had:
we
have
we
have
provenance
of
authority
in
audit
and
we
have
the
guarantee
that
actions
taken
on
behalf
of
a
terminal
user
terminal
principal
are
must
be
explicitly
in
the
context
of
actuation
of
their
desired,
what
they
desired.
I
you
you
covered
both
of
those
I
think
those
are
both
explicit
improvements
over
just
creating
namespace
troll
bindings
for
the
revenue
side,
control,
yeah.
E
For
sure
I
think
they're
definitely
explicit
improvements.
The
auditing
one
is
nice,
I
think
it
it's
a
little
bit
separate
from
authorization,
and
then
there
are
fewer
confused
deputy
bugs
is
an
authorization
benefit
you
you
can't
say
there
is
no
possible
confuse
deputy.
You
just
have
to
say
the
confuse
deputy
has
to
do
slightly
more
bad
things.
I
I
think
it.