►
From YouTube: Kubernetes SIG Auth 20170111
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20170111
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,
this
is
big.
On
4
january
11th
we
have
a
relatively
late
agenda,
we're
going
to
be
talking
about
our
back
in
one
beta,
1
and
rollout
that
we
are
currently
performing
for
various
country
to
convert
things
just
we're
using
our
lacking
forces
much
so
we
have
as
a
goal
for
one
second
to
get
our
back
to
the
one
day.
One
biggest
requirement
we
had
for
doing
that
was
to
enforce
role.
A
We
are
on
that
road,
so
there's
now
a
pull
open
to
actually
create
the
beam
1
beta,
1
version
of
the
api.
There
are
a
few
noteworthy
changes
in
that
whole,
the
biggest
one
is
the
attributes
or
scription
feel
it's
up
on
a
policy
rule.
It
is
something
that
we
regretted
doing
it
open
chefs.
We
poured
it
over
to
our
back,
but
never
actually
found
a
use
for
so
we
are
removing
that
dead,
feel
or
cross
out
and
then
otherwise.
We
are
just
copying.
A
A
So
the
poll
looks
like
a
reference
there.
If
someone
wants
to
make
comments
in
it,
it's
almost
merged.
Today
we
have
to
do
a
few
decays
with
one
thing.
Hopefully,
3
j
phone
isn't
too
upset
at
the
way
that
went
last
night,
we'll
give
it
another
try
and
we'll
be
looking
to
do
that
sometime
in
the
next
week.
A
Alright,
so
in
terms
of
the
rollout
at
the
very
beginning
of
this
year,
January
or
I
think
forth
right
around
there,
we
actually
started
enforcing
our
back
inside
of
niihka.
There
is
no
more
a
back
off
that
idea
being
used
during
those,
and
this
ensures
that
we
have
working
Hewlett
role,
working
controller,
both
working
proxy
loads,
that
the
stock
rolls
are
actually
being
exercised
and
that
no
one
can
actually
merge
their
controller
or
Hewlett's
or
property
changes
and
get
through
in
the
ETS
without
having
the
role.
This
was
a
big
boom
for
them.
A
It
has
gone
remarkably
smoothly,
they're
thin
I
think
maybe
for
fix.
Ups
already
the
people
have
noted,
but
if
you're
watching
take
off-
and
you
see
it
mentioned-
and
you
seen
concerns
about
a
403
from
a
controller,
we
need
to
try
to
make
sure
we
guide
people
to
the
appropriate
spot.
I
sent
out
community
dev
that
provided
links
for
where
you
need
to
change
the
code
for
controllers
and
for
for
cubelet
and
where
questions
should
go.
A
B
B
B
The
second
set
of
permissions
are
things
that
particular
deployments
use
so
in
a
particular
ete
test.
For
example,
it
might
expect
a
service
account
in
the
namespace
foo
to
have
admin
permissions,
and
so
we
don't
want
to
grant
a
service
account
named
foo
or
a
service
account
and
a
namespace
new
permissions
in
every
deployment.
In
a
case
like
that,
the
particular
e
to
e
test
needs
to
set
up
permissions
as
part
of
its
as
part
of
setting
up
the
environment
for
its
test.
B
That
can
either
be
done
in
the
test
itself,
or
it
can
be
documented
that,
if
you're
using
an
external
authorizer
in
order
to
run
this
and
then
test
here's
the
permissions
that
need
to
be
in
place,
that
was
largely
just
assumed.
It
was
assumed
that
all
service
accounts
were
route
on
the
cluster
and
so,
as
David
said,
going
ahead
and
enforcing
and
actually
enumerated,
the
permissions
that
we
need
in
ete
was
a
big,
a
big
jump
forward.
B
So
that's,
basically,
the
two
categories
were
kind
of
putting
issues
into.
Is
this
a
global
thing
that
all
deployments
should
have,
then
it
should
go
in
bootstrap
roles
and
role
bindings?
Is
it
a
particular
issue
with
a
particular
script
like
one
of
the
GCE
bring
up
scripts
or
cops,
bringing
something
up,
then
we
need
to
grant
permission
to
a
particular
user
in
that
script,
and
so
that's
how
we're
categorizing
things
and
what
we're
what
we're
trying
to
do.
B
So
that's
that's
the
bring
up
stuff.
The
the
second
question
is
what
to
do
with
upgrades.
So,
if
you're,
upgrading
a
cluster
using
your
own
deployment
methodology-
or
you
are
just
upgrading
the
binary
and
running
it,
invoking
it
the
same
way,
a
back
is
still
present
and
still
works
the
same
way
it
did.
So
if
you
have
a
policy
that
you're
happy
with
you
know,
the
one
six
will
work
identically
with
that
policy.
B
But
if
you
are
wanting
to
use
one
of
the
GCE
or
gke
scripts
that
was
switched
to
our
back,
we
need
to
think
through
how
do
we?
How
do
we
upgrade
a
cluster
that
was
brought
up
with
the
same
corresponding
script
in
1-5,
and
so
I
linked
I'll
copy?
I
link
actually
one
of
those
issues
just
talking
about
what
to
do
with
upgrades.
B
My
preference
would
be
to
optionally
include
the
legacy
policy.
I,
don't
really
want
to
duplicate,
but
the
legacy
policy
in
our
back,
because
the
legacy
policy
was
not
a
good
policy,
it
made
service,
accounts,
cluster
admin
and
so
I
think
if
you
are
upgrading
from
an
old
cluster
and
you
want
to
keep
a
a
nun
enforcing
policy
in
place
that
should
be
possible,
but
that
shouldn't
be
the
default
and
I
don't
really
want
to
propagate
that
loose
of
a
policy
into
our
back.
C
B
C
B
The
cube
user
that
people
have
already
been
using
as
their
bootstrap
user
will
be
in
the
super
users
group
so
that,
if
you,
if
you
use
those
bring
up
scripts
and
then
started
running,
cube,
control
commands
as
well
continue
to
work
as
they
did
before
the
right
now.
Those
scripts
are
loading
policies
for
e
to
e
and
I
think
we
probably
want
to
make
the
e
to
e
runs.
B
To
generate
a
new
one
for
you,
but
if
you
have
a
working
cluster,
you
should
be
able
to
say
and
load
the
old
policy
file
that
I
had
from
my
older
cluster.
We
need
to
think
through
how
to
do
that
if
we
want
to
detect
if
the
file
exists,
I,
don't
know
how
much,
how
many
of
these
things
are
being
run
by
other
tools
or,
if
they're
being
run
by
users
directly.
So
we
just
need
to
figure
out
how
to
do
that.
So.
C
B
I
would
expect
that
to
either
be
something
that
you
start
up
your
cluster
and
then
create
granted
permission
that
gives
everyone
access,
so
you
can
use
a
queue,
control,
create
cluster
roll
binding
and
grant
us
our
admin
to
all
your
service
accounts.
You
could
do
that
if
you
want,
you
could
script
that
if
you
want
I,
don't
think
that
should
be
the
default
anymore.
I,
don't.
C
Think
so,
either
and
I
think
we
need
to
actively
push
people
away
from
that
I
just
figured.
It
might
be
easier
to
have
some
get
out
of
jail
flag
that
basically
did
exactly
what
one-five
does
it
will
if
you're,
creating
a
new
cluster
it'll
write
that
a
back
file
and
it'll
turn
on
the
a
back
authorizer
along
with
the
are
back
authorizer,
and
you
can
what
you
need
with
that?
Well,.
B
C
B
D
Yeah
we
find
that
hey
back
in
our
back,
don't
play
particularly
well
together
in
terms
of
like
practically
having
that
it's
like
a
back
is
really
good
for
the
bootstrapping
initially,
but
in
reality,
it's
way
easier
to
just
use
our
back
all
the
way
through,
because
you
get
weird
scenarios
like
you
get
limitations
around
the
like.
You
get
privilege
escalation.
You
can
look
at
the
privileged
escalation
checks
pretty
quickly
because,
like
the
authorizers
don't
play
well
together,
Oh
actually.
B
I
should
mention
that
you
know
anyone
who
has
been
using
our
back
if
you
use
multiple
authorizers
together.
This
is
what
Eric
was
talking
about
when
you
try
to
grant
a
role
in
our
back,
it
makes
sure
that
you
already
have
all
the
permissions
granted
in
our
back
so
that
you
can't
escalate
yourself
or
someone
else's
permissions
via
sort
of
circular
grants
like
I'll,
grant
you
a
role
that
gives
you
power
than
you
grant
the
role
back
to
me.
B
That
kind
of
thing
a
poll
just
went
in
that
allows
alternately
gating
that,
on
a
particular
permission
and
any
authorizer
can
give
you
that
permission.
So
this
this
will,
let
you
strap
with
a
back
or
a
webhook,
authorizer
or
something
else,
and
then
that
can
vouch
for
you
that
you
have
permission
to
bind
a
particular
role
so
that
just
went
in
and
I'll
link
in
the
pull
notes
on
the
side.
That's
not
related
to
the
roll
out.
C
B
A
D
E
B
E
And
I
think
users
are
open
to
guidance
here
right
like
they
don't
want
to
have
to
go,
read
50
different,
Docs
or
lots
of
stuff
to
figure
out
how
to
configure
it
securely.
If
we
have
like
the
security
best
practices
guide
of
here's
like
how
you
should
use
our
back
to
part
from
this
based
on
the
transistors
or
knowledge,
because
we
know
what
you're
doing.
C
E
B
Able
are
back
and
if
we
detect
there's
a
legacy,
a
back
policy
also
include
that
and
log
hey.
We
included
a
back
because
you
have
it
in
place.
Here's
how
here's
a
reference
to
how
you
migrate
off
of
it
I
think
a
lot
more
people
would
not
really
care.
It's.
D
Our
internal
experience,
though,
turning
on
our
back
for
a
lot
of
the
core
or
less
clusters,
is
that
so
many
people
developers
are
used
to
clusters
that
developing
against
clusters
that
don't
have
authorization
that
it
basically
like,
and
it
breaks
everything
I
over
to
me
to
get
people
with.
Like
you
know,
smart
people
who
work
with
kubernetes
every
day
coming
up
to
me
and
saying
like
hey
everything
is
broken,
what
the
hell
and
it
it
seems
like
from
a
documentation
standpoint
or
like
even
a
learning
standpoint.
D
If
it's
like
suddenly
pretty
much
every
job
that
uses
you
know
every
thing
that
could
possibly
deploy
the
deploy
that
uses
the
kubernetes
api
like
an
ingress
controller
or
something
like
that
suddenly
becomes
a
surface
area
for
somebody
being
confused
and
being
frustrated
with
the
new
technologies.
So
it
I,
don't
know
exactly
what
best
way
of
combating
that
is.
But
it's
just
like
I
think
the
major
complaint
that
I
see
is
that
just
not
enough
people
who
know
how
to
use
our
back
or
understand
what
the
general
way
to
use
it
is
for
the
patterns.
D
So
they
become
frustrated
too,
very,
very
quickly.
With
it
so
so
you're
saying
a
users
guide
to
it
is
useful,
but
a
developer's
guide
is
also
useful
willing
to
be.
We
have
a.
We
have
a
guide
and
I
think
that
it's
useful
but
I
think
just
the
fact
that
it's
not
very
like
like
we
in
this
one
cig,
no
understand
these
concepts
very
well,
but
I.
Think
outside
externally.
Not
many
people
are
playing
around
with
authentic,
really
customized
authentication
or
authorization
practices.
D
E
E
Know
right
I
mean,
like
I,
think
they
for
a
use
case
if
I
want
to
hack
a
Raspberry
Pi
together
using
mini
cube
as
quick
as
possible.
That's
a
reasonable
use
case
and
I,
don't
think
using
admin.
Token
is
necessarily
all
as
bad
in
that
case,
because
your
goals
are
really
constrained
and
there's
no
plans
to
ever
productionize
right.
D
Yeah
I,
unfortunately,
I
don't
have
great
answers
in
terms
of
this,
but
I
think
it's
I
think
it's
reasonable
to
need
to
I
mean.
Maybe
it
is,
you
know
reviewing
our
documentation
to
try
to
make
it
better.
Maybe
it
has
to
be
writing
more
blog
posts
on
a
given
Nettie's
blog
for
introducing
this
feature
to
more
people.
What's
our
education
plan
right,
yeah
I
think
that's
the
better
way
of
putting
it.
B
B
Somebody
writes
a
component,
and
that
is
intended
to
be
broadly
consumable.
You
know
in
any
kubernetes
deployment
and
doesn't
consider
the
permissions
API
permission
to
require
I.
It's
it's
unfortunate
that
we
made
it
this
far
without
people
having
to
consider
that
and
so
I
just
kind
of
framing
this
as
a
good
thing
like
this,
isn't
something
that
was
working
before
and
is
now
not
working.
B
This
is
something
that
maybe
worked
before,
but
you
never
knew
it
depended
on
what
cluster
your
apples
deployed
to
and
so
just
kind
of
framing
this,
as
this
is
the
other
half
of
API
usage,
like
figuring
out
the
API,
is
you
want
to
use
and
then
making
sure
that
you're
running
as
someone
authorized
to
use
this?
It's.
E
This
is
important
point
is
when
you,
when
you
explain,
what's
going
on
to
users
the?
Why
we're
making
the
changes
as
important
as
to
how,
in
the
what
and
to
the
extent
that
if
we
have
like
a
security
roadmap
plan
of
like
where
we're
driving
things
and
why
that
justifies
what
we're
doing.
We
could
potentially
refer
people
to
that
and
that
might
also
serve
some
of
the
proactive
education
of
like
hey.
Community
security
isn't
really
there
and
we
need
it
to
be,
and
we're
going
to
do
that
in
2017
and
here's
what's
coming
and
why.
D
E
D
Be
I
mean,
are
we
I
know
that
as
part
of
release
doesn't
even
have
blog
post
think
about
describing
particular
features
may
be?
Do
we
can
commit
put
on
those?
At
the
very
least
you
know,
here's
the
are
back
thing
that
we
had
just
enabled
in
here
is
sort
of
how
to
use
it
and
here's
how
to
get
started
and
here's.
Why
we're
doing
I.
A
B
Could
even
see
an
option
to
say
run
and
securely,
but
I
would
not
want
any
of
our
e
two
E's
or
CI
machines
to
run
that
way.
For
someone
who
needs
a
cluster
to
behave
the
same
way
it
did
in
1:5
and
with
big
nasty
warnings
around
the
run
and
secure
option,
hey
I,
don't
think
I
would
want
them
to
handcraft
that
it
should
just
be
a
I'm
running
insecure,
like
1:5
and
I.
Don't
care.
C
B
B
B
E
E
So
from
gke
standpoint,
we
need
to
be
backwards
compatible
with
all
of
the
other
clusters
that
are
already
out
there.
We
can't
inflict
this
without
notice
on
users.
Like
sorry
all
of
your
stuff
breaks,
the
roam,
I
care
about
having
a
backwards
compact
and
happy
to
put
in
whatever
we
need
to
do
to
make
that
happen.
I.
A
B
B
But
this
person
was
using
one
five
and
they
were
happy
and
they
want
to
use
one
six
and
they
are
sad
and
either
either
setting
up
the
policies
that
they
would
need
and
telling
them
go
load
them
this
way,
and
this
will
get
you
one.
Five
behavior
and
here's
the
trade-offs
or
I
think
that's.
That
would
be
the
minimum,
but
yeah
I.
D
Think
also
practically
how
a
lot
of
people
will
deploy
urbanized
Buster's
from
what
we've
seen
is
that
they
use
tools
like
cops
or
whatever
else
right.
We
have
like
a
million
internally
and
I.
Think
that
are
the
general
feedback
for
me
going
to
like
one
of
our
deployment
methods
has
been
well
our
backs
and
our
backs
and
alpha.
D
Therefore,
we
don't
want
to
endorse
it
for
every
Korea
s
cluster
that
we
spin
up
I,
think
that
will
get
a
lot
of
good
feedback
if
we
sort
of,
as
we
push
deployment
methods
to
start
using
our
back
on
because
like
whether
or
not
they
server
has
it
on
by
default.
I
think
the
real
test
is
do
does
cops,
does
Kubat
mend
whatever
those
many
to
use
it
right?
These
type
of
things
would
be
I
think
that
those
type
of
things
will
be
a
good
test
of
how
does
it?
D
E
B
I
mean
to
be
clear,
a
BAC
is
the
API
version
is
beta
also
so
yes,
the
goal
is
beta
for
1/6
API
was,
and
correctness
was
its
it's
in
a
good
place.
I
think
the
remaining
issues
that
we
wanted
to
look
at
work,
performance
and
documentation
and
tooling
around
it,
and
some
of
the
like
upgrade
scenarios
like
your
upgrade
and
some
new
roles
exist.
How
do
those
roles
get
added
in
upgrade
and
a
component?
It
requires
some
additional
permissions.
How
does
the
role
for
that
component
get
updated?
E
A
Think
you
can
definitely
be
made
to
work
there
our
help
and
be
able
to
find
roles.
We
have
dot
started.
What
roles
exist
out
of
a
box,
the
reconciliation
on
startup,
to
be
sure
that
the
controllers
and
cubelets
and
all
those
are
kind
of
off,
is
a
solved
problem
and
OpenShift.
We
can
bring
that
same
style,
solution
up
and
ready
so
that
your
cluster
will
automatically
add
the
system
pieces
that
we
need
system.