►
From YouTube: Kubernetes SIG Auth 20170322
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20170322
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
A
And
I
think
we
have
a
couple
of
topics
to
link
in
to
that
so
I'm,
adding
those
in
probably
right
after
this
meeting
there's
one
doc
PR
that
I
have
open
that
I
know
of
I
think
there
are
some
others
for
cube
atoms
that
are
related
to
our
back,
because
cube
atom
is
enabling
our
back
by
default
other
than
that
I.
Don't
know
of
in-flight
changes
or
release,
notes
or
Doc's
that
we're
waiting
on
does
anyone
else
have
things
they
want
to
link
in.
A
A
So
in
1/5
you
know
we
have
several
authorizers
that
are
available
and
each
deployment
gets
to
pick
which
one
they
want
to
enable
by
default
and/or,
which
ones
they
want
to
enable
by
default
and
if
a
particular
deployment
method
changes
its
defaults
then,
is
responsible
for
kind
of
preserving
existing
permissions
or
documenting
breaking
changes.
So,
for
example,
cube
up
changed
from
defaulting
a
back
to
defaulting
to
our
back,
but
when
upgrading
existing
clusters
it
includes
the
legacy,
a
back
policy
so
that,
if
you
upgrade
an
existing
cluster,
your
existing
cluster
keeps
working.
A
The
change
that
cube
up
needs
to
document
is
what
happens
when
you
bring
up
a
new
cluster
and
the
answer
is
service
accounts
outside
the
keeps
system.
Namespace
lose
permissions
by
default,
and
if
you
want
the
old
behavior
back,
there's
a
single
command,
you
can
run
to
get
the
old
behavior
back.
So
that's
an
example
of
what
we
want
to
make
sure
is
documented
a
right
now.
The
only
deployments
I
know
of
that
are
going
to
are
back
by
default,
are
Cuba
and
cube.
B
A
B
That
just
execute
a
benign
they
are
making
something
like
7
or
8
breaking
changes
as
far
as
I
know
so
I'm
working
with
him
to
make
sure
those
are
adequately
documented
and
yeah
was
alpha.
Cube
up
was
definitely
not
alpha.
I&Amp;I
status
is
kind
of
weird,
but
it's
not
entirely
clear
to
me
that
this
change
is
okay
for
cube
up
I
mean.
Is
it
all
clusters
in
keep
up
or
just
certain
providers
or
the
ones
that.
C
A
B
You
know,
as
soon
as
we
get
the
providers
stuff
able
to
run
out
of
tree,
we
actually
need
to
spend
some
effort
nuking
all
that
stuff
or
you
know
there
any
bits
that
need
to
be
saved
for
DK
or
anything
else
that
needs
to
be
moved
out
of
tree,
but
breaking
existing
scripts
and
things
and
votes
or
blogs
or
whatever
that
invokes
cuba
to
bring
up
a
cluster
is
really
not
okay
for
the
project
thing.
That's
super
duper
painful
to
go,
explain
that
everywhere.
If
we
can
make.
B
Instead,
you
know
for
someone
who's
setting
up
a
production
cluster
today.
Look
you
just
execute
this
one
command
or
add
this
one
thing
saying:
yes,
I
want
to
secure
production
cluster
that
enables
appropriate
author
whatever,
and
that
seems
like
not
a
huge
burden
on
setting
up
a
production
cluster,
since
it's
inherently
more
challenging
with
more
also
good
people
doing
it
even
but
for
all
the
kick
the
tires
kind
of
making
all
those
harder
is.
It
is
not
very
desirable.
I.
B
Mean
it
may
be
made
existing
clusters
works
in
a
backward
compatible
way,
but
you
know
a
lot
of
people
create
clusters
as
part
of
automation
or
I
think
as
part
of
scripts
or
just
like
copy
pasting
from
blogs
and
stuff.
Like
that,
last
time
you
changed
you
control,
run
and
a
non
backward
compatible
way.
It
caused
a
unique
and
little
pain.
Also
I'd
really.
C
D
E
B
E
D
Like
I
think
like
Brian,
the
position
you're
advocating
for
is
where
we
are
today
is
the
default
security
processor
and
the
all
new
security
postures
that
are
potentially
back-breaking
in
an
API
fashion
would
have
to
be
opted.
We
think
that
we
want
to
do
something
like
feature
by
feature
there
like
right
now,
it's
Arabic
next,
it's
pod
security
policy.
After
that,
it's
you
know
ability
to
create
namespaces
or
something
do
we
want
do.
D
We
think
we
would
probably
prefer
to
have
to
define
now
the
default
security
or
like
be
it
the
default
security
and
a
secure
profile,
or
would
we
do
it
few
attics
that
I
think
that
would
be
a
good
idea.
So
if
we
say
the
secure
profile
may
break
you,
because
we
introduced
more
security,
is
that
because
they're
opting
in
to
get
more
security
and
they
want
to
be
secure
that
it
that
makes
it
acceptable?
I.
B
A
B
Want
to
try
to
be
compatible
with
that
from
day
one
when
they
opt
into
the
profile
they
can
like.
We
can
say:
look
we're
going
to
take
away
all
kinds
of
hosts
access
from
pods
we're
going
to
cluster
admin
level,
definitions
from
non
cube
system.
Namespaces,
we're
gonna,
enforce
all
these
things.
We
don't
enforce
them
today,
but
our
intent
is
like
reasonable
security
practices.
You
know-
and
these
are
the
ones
we
can
think
of
right
now.
I
can
help
write.
D
B
D
A
I
guess
the
three
environments
that
I
see
like
the
kick
the
tires,
the
CI
environment
and
then
the
intentionally
hardened
hardened
environment,
and
what
we
want
to
make
sure
is
that
the
CI
stuff,
that's
running
a
to
ease,
is
actually
testing
things
in
the
secured
mode.
Like
that.
That's
lost
out
a
lot
of
cases
where
we
didn't
have
the
right
permissions
and.
E
D
I
think
the
argument
I
would
I've
heard
other
people
make
is
the
person
setting
this
up
is
usually
doing
this
into
some
context
where
they
probably
have
some
control.
So
if
you're
setting
up
on
GCE,
you
probably
have
default
firewall
rules
and
the
only
credentials
to
the
cluster
or
what
come
back
as
part
of
Cuba
and
so
you're
at
a
reasonable
level
of
security,
and
every
step
after
that,
where
you
allow
someone
else
to
access
it,
you're,
adding
extra
people
I
would.
B
A
A
B
D
D
D
The
we're
adding
effectively-
and
this
has
been
discussed
a
little
bit
in
the
conformance
stuff
like
we're
at
basically
adding
two
security
profiles
minimum
and
it
probably
makes
sense
that
we
will
have
to
go
pay
the
cost
to
separate
out
the
tests
and
like
an
open
shift.
We've
actually
hit
a
lot
of
that,
like
you
spent
most
of
the
time
saying
like
this
cube
test.
Does
it
run
because
it
assumes
that
it
can
schedule
to
all
notes.
Scheduling
to
all
modes
is
not
allowed
by
default,
or
you
know
whatever
the
specific.
B
B
Think
this
is
a
win
actually
as
well,
because
then
we
can
like
advertise
that
we
introduced
to
secure
profile
for
production
clusters.
You
want
to
run
secure
a
harden
profile
or
whatever,
and
then
then
it
you
can
advertise
it
as
a
you
know,
a
feature
instead
of
saying
look:
we're
making
it
harder
for
everybody
who
doesn't
care
about
this.
Oh
I.
E
B
Do
want
to
remove
Cuba,
but
you
know,
keep
up
is
gonna
need
some
kind
of
replacement
and
yeah
I.
Don't
know
how
much
you
want
to
have
a
talk
about
specific
thing,
but
the
concept
of
a
secure
profile
is
going
to
need
to
exist
in
the
conformance
testing.
It's
going
to
need
to
exist
in
a
little
bit.
Cuban
concludes
today's.
It's
good
I
need
to
persist
beyond
Cuba.
B
C
B
C
C
A
B
F
B
B
B
I'll
just
say:
I
appreciate
your
flexibility
and
I
know
this
was
discussed
in
various
threads.
All
the
way
back
in
January
and
maybe
earlier
I
saw
Tim
had
responded
to
the
thread
that
I
then
found
and
responded
to,
but
there
was
no
follow-up,
I
just
plead
with
people.
If
you
can
think
about
how
to
communicate
some
of
these
things
to
the
broader
community.
B
That
would
help
it's.
This
isn't
the
only
issue
to
just
come
up
today.
Just
to
let
you
know
it's
like
one
on
three
at
least
finding
about
these
things
on
the
day
we're
supposed
to
come
through,
Lisa's,
not
awesome.
So
if
you
can
just
help
brainstorm
ways
to
get
better
coverage
of
these,
like,
like
I,
said,
I
didn't
really
see
anything
clear
in
the
futures.
Repo
I
didn't
see
anything
clear
and
the
release
notes.
I,
didn't
see
anything
clear
in
the
one
documentation
PR
I
could
find
about
what
was
going
on.
A
B
A
A
Necessary
but
in
particular
deployments
switching
defaults,
authorizers,
and
so
the
disconnect
is
probably
like.
The
are
back
feature
itself
is
completely
compatible
with
1/5,
but
the
deployment
methods
changing
is
where,
like
it
affects
users,
and
so
it's
a
new
deployment.
You
know,
quote-unquote
new
deployment
is
like
you
Badham,
you
know
if
it's
enabling
our
back
and
everyone
is
using
a
new
cluster,
then
okay,
you
get
a
secured
cluster
of
the
cube
atom
cube
up.
People
like
you
said
I
already
have
scripts
and
examples
and
blogs
and
things.
B
A
We
probably
wanna
brainstorm
for
at
least
a
minute
about,
like
what
profiles
are
likely
to
do
clean.
You
said
you
were
going
to
write
that
up,
because
I
I
think
we'll
have
at
least
three
like
the
development
or
insecure
one:
a
secured
single
tenant
one
and
then
I
secured
multi
tenant,
one
eventually
and
so
think
about.
F
B
A
A
B
A
B
A
And
with
someone
from
I
guess
just
bidden
him
back
to
you,
madam
nearly
as
much,
but
the
idea
about
security
profiles
is
something
we
will
at
least
want
to
discuss
with
the
very
simpler
methods
like
I
think
that's
a
useful
constructs
to
have,
especially
when
you
start
having
like
three
four
or
five
different
ways
of
deploying
cube.
If
you
can
say
well,
I
want
this
profile
and
then
each
deployment
does
it
in
its
own
way
that
that
might
be
a
useful
way
to
kind
of
communicate.
What
type
of
cluster
are
you
setting
up
here?
C
Do
we
end
up
having
to
worry
about
like
this
is
what
it
was
in
one
six
and
I
want
the
secure
profile.
I
got
in
one
six
running
in
one
seven:
yeah
I
worry
about
the
creep
there
yep,
even
the
more
secure
one
that
you
could
get
in
one
seven,
no
I
don't
want
that.
I
want
the
way.
I
ran
it
in
one
six
yeah.
A
I
mean,
on
the
one
hand
you
have
like
all
the
underlying
options
and
all
the
setup
that
you
can
do
and
if
you
expose
all
of
that
to
the
user
they
can
fiddle
on
every
knob
and
say
well,
I
want
this,
and
that
and
this
and
that,
on
the
other
hand,
you
have
the
really
high
level
like
I,
want,
secure
or
not
secure
and
the
meaning
of
secure
changes
released
to
release.
As
you.
A
A
F
Not
landmine
here
like
if
we
let
people
be
insecure
by
default.
Essentially,
then
you
know
they
could
essentially
end
up
building
that
production
infrastructure.
You
know
in
that
in
that
mode
and
then
then
decide
ok,
now
I
want
it
to
be
secure
and
it's
gonna
be
so
incredibly
complex
to
move
it
like
once
it's
been
built
like
that
yep,
then,
if
you
want
to
try
and
flip
it
into
secure
mode,
it'll
be
basically
impossible
at
that
point,
and
so
they'll
just
give
up
that.
E
A
F
E
F
F
Yeah
so
I
think
if
we,
if
we
go
down
this
path
up
like
these
separate
profiles
that
will
inevitably
kind
of
braid
in
this
way,
we
then
maybe
there
needs
to
be
some
sort
of
stick
to
get.
People
like
I,
understand
the
kick
the
tires.
We
want
that
to
be
frictionless
and
as
easy
as
possible
that
you
know,
maybe
maybe
once
you
hit
some
sort
of
threshold
like
oh,
you
know,
you've
put
more
than
X
X
number
of
nodes
into
this
or
something
along
these
lines
that
you
start
getting
warnings
about
not.
F
A
To
run
in
secure
mode
right
and
anything
anything
that's
in
the
kubernetes
org
or
linked
to
by
us,
like
the
things
we
sort
of
adopt
and
recommend
like
we're,
not
going
to
recommend
something
that
requires
you
to
start
up
an
insecure
mode.
So
in
my
mind
that
would
be
a
division.
It's
still
not
terrific,
but.
C
So
how
do
we
for
lack
of
a
better
term?
Shame
the
deployment
things
that
don't
work
in
secure
mode,
because
that's
kind
of
what
we're
fighting
against
now
is
people
have
built
these
things
that
are
not
going
to
work
if
you
run
with
only
our
back
on,
because
they
didn't
include
a
our
back
role
binding
with
it.
Well.
A
Whoever's
deploying
it
can
always
give
the
same
permission,
out-of-band
right
it
doesn't.
It
doesn't
require
whoever
wrote
the
add-on
to
change
their
add-on
if
I
want
to
run
an
add-on
that
requires
permissions.
I
can
I,
can
grant
those
permissions
and
then
deploy
the
add-on
right
sure,
and
so
it
doesn't
have
to
be
on
them.
But
ideally
things
that
want
to
run
on
your
cluster
would
describe
the
permissions
they
needed.
F
Yeah
I
mean
for
kind
of
big
security
changes,
I've
rolled
out
on
the
pasta,
it's
sort
of
been
like.
You
know
you
introduce
it
as
an
optional
thing
and
then
you
know
you
set
a
timetable
and
you
try
and
start
communicating,
and
then
you,
like,
you,
know,
then
have
a
very,
very
lightweight
kind
of
exemption.
Like
oh
I
want
to
get
out.
You
know
this
disco
flipped
at
a
fault.
I
need
to
get
myself
out
of
this
situation
back
to
working,
and
then
you
gradually
beat
down
on
the
whitelist
thing.
A
I
mean
even
even
that
the
as
simple
as
which
profile
is
the
default
like
do
you
default
insecure?
That
seems
like
a
really
bad
default
and
I
know
I've,
seen
sort
of
servers
that
default
that
go
both
ways
where
you
have
to
opt
into
development,
though
so
I
think
vault.
You
have
to
start
up
and
specify
that
you
want
development
mode
and
it
opens
itself
up,
and
those
are
some
things
sed
I
think
is
the
other
way.
So
by
default
it
runs
not
with
TLS
enabled,
or
at
least
in
v2.