►
From YouTube: Kubernetes SIG Auth 20170405
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20170405
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
So
I
wanted
to
highlight
a
few
pull
requests
and
issues
that
are
tagged
with
our
sig
I've
been
trying
to
be
sure
to
add
that
tag.
So
if
you're
watching
issues
or
pull
requests
and
filter
it
to
sig
off,
that
should
give
a
pretty
good
picture
of
what's
going
on,
at
least
in
the
main
repo,
and
if
you
see
issues
or
PRS
that
don't
have
that
tag
added
or
mention
the
sig
off
team
and
will
get
that
added.
A
A
Let
users
discover
what
storage
glasses
they
can
request
in
their
persistent
volume
claims,
and
so
there
are
other
class
type
of
resources
that
I
think
will
be
similar
and
so
we're
wanting
to
come
up
with
a
role
that
will
give
read
access
to
those
things
and
we're
having
trouble
coming
up
with
a
good
name
for
that
role.
So
if
you
have
ideas
or
you
want
to
look
at
the
pull
request
and
add
suggestions,
maybe
someone
will
call
but
I
mean.
A
I
think
one
of
the
tricky
things
about
house
security
policy
is
going
to
be
figuring
out
how
to
structure
like
all
the
little
options
that
might
make
sense
for
some
volumes
right
now.
This
one
is
adding
it
sort
of
peer
to
the
allowed
volume
list
or
about
a
lot
of
volume,
type
field
and
I.
Think
it's
going
to
be
tricky
to
structure
that
in
a
way,
that's
not,
but
maybe
ugly,
is
okay.
A
Anyway,
the
the
other
pot
security
policy
item
in
one
six,
you
can
authorize
use
of
POD
security
policies
cluster
wide
and
has
to
be
close
to
wide.
So
if
you
have
a
policy
that
lets
users
create
privileged
pods,
you
can
either
let
them
do
that
anywhere
in
the
cluster
or
nowhere
in
the
cluster,
and
so
this
this
poll
went
in.
That
would
let
you
give
users
that
permission
just
within
a
specific
name
space
now
for
those
playing
along
at
home.
A
You
would
have
to
pair
that
with
something
that
would
limit
which
nodes
you
could
target
in
that
namespace
right
otherwise
didn't
create
privileged
pods
within
a
particular
namespace.
But
if
you
can
target
them
out
to
any
node,
then
that
really
hasn't
gotten
you
a
lot.
But
when
you
combine
it
with
some
of
the
admission
plugins
that
lets
you
force
pods
in
a
namespace
to
only
go
onto
nodes
with
specific
selectors,
then
that
becomes
really
powerful.
You
can.
A
You
can
limit
a
namespace
to
a
set
of
nodes
and
then,
like
users,
create
privilege
pods
on
those
nodes
and
once
we
subdivide
nodes
access
back
to
the
API
that
can
start
to
get
you
into
like
a
tenant
model.
Where
you
say
you
have
these
namespaces
which
go
to
these
nodes
and
you
can
do
whatever
you
want
on
these
nodes.
C
Is
there
anything?
Is
there
anything
blocking
that
PR?
Because
last
time
I
checked,
it
was
looks
good
to
me,
and
this
actually
is.
Basically,
this
is
a
requirement,
at
least
for
us,
to
use
the
pod
security
policies
so
which
one
the
the
namespace
one,
the
namespace
one
yeah
it
merged
Oh
perfect!
That's
my
business.
B
A
Like
this
is
a
building
block,
we
have
like
three
dimensions
and
building
blocks.
You
have
controlling
what
kind
of
pods
you
can
have
in
the
namespace
controlling
what
nodes
and
names
can
target
and
then
controlling
what
that
node
can
do
back
to
the
API
and
all
three
of
those
pieces
have
to
be.
There.
I
feel.
A
There's
an
old
issue
about
enabling
service
account
token
lookup
in
replication.
By
default,
so
service
account,
tokens
are
signed,
gwt's
and
those
signatures
get
verified
by
the
api
server,
but
by
default
they
don't
expire
and
by
default
the
server
the
API
server
doesn't
look
up.
Whether
they've
been
revoked.
Dbt
revocation
is
like
a
black
hole
that
I
don't
want
to
get
into,
but
the
simple
way
to
check
that
is
to
see
if
the
secret,
where
they
were
stored,
still
exists
and
there's
an
option
to
check
that
and
some
deployments
use
it
some
of
the
formants.
A
Don't
it
was
off
by
default
in
the
initial
implementation
and
I've
been
wanting
to
turn
it
on
for
several
releases
now
I
think
the
downsides
would
eat,
but
the
performance
impact
which
I'm
not
that
concerned
about,
because
we've
been
running
it
at
scale
in
lots
of
deployments
and
the
sort
of
distributed
Federation
aspects
where
I
want
to
use.
My
service
account
tokens
against
another
cluster
based
solely
on
the
signatures
and
where
they
don't
share
an
SCV,
and
they
can't
do
this
lookup.
A
A
A
C
Do
we,
how
do
we
prevent
this?
These
type
of
changes,
its
default
Flags
from
creeping
us
upon
us
once
when
a
second
gets
released,
and
you
know
other
things
come
in
and
say:
hey
you've
changed
default
behavior.
If
they're
like
a
better
way,
we
could
communicate
that
upfront.
So
we
could
have
that
discussion
now,
rather
than
right
at
1-7.
C
C
A
C
A
It's
good
question
so
yeah.
So
probably
those
three
concerns:
I,
guess,
performance,
sort
of
a
federated
signature
only
use
case,
and
then
just
people
expecting
it
to
work
the
way
it
works
today.
Although
honestly
I
think
people
would
be
surprised
if
you
told
them
that
you
can
delete
a
service
account
and
all
sorts
we're
going
to
keep
using
them.
Yeah.
A
All
right,
yeah,
well
we'll
we'll
continue
the
discussion
and
in
that
poll
I
did
tag
in
SIG's
scalability.
We
do
have
keep
mark
running
against
sort
of
a
fully
secured
stack
now.
So
that's
that's
good.
So
if
there
are
issues
with
this,
it
should
show
up
there.
A
A
The
next
one
is
actually
a
response
for
those
who
saw
the
pod
security
policy
CBE
announcement
a
couple
weeks
ago,
we're
going
through
the
retrospective
on
that
now.
I'll
probably
send
that
out
to
the
list
in
the
next
day
or
so,
and
one
of
the
root
causes,
for
that
was
a
special
case,
handling
of
requests
that
came
to
the
unsecured
port.
So
currently,
if
you
make
a
request
to
the
unsecured
port,
the
localhost:8080
fort,
there's,
no
authentication
authorization
on
that
port
and
what
that
means
is
for
the
rest
of
the
stack.
A
The
user
info
is
no
and
so
places
where
we
check
things
against
user
info,
had
the
special
case
like
the
nil
use
case,
and
that
made
for
turkey
logic
in
a
couple
places
and
incorrect
logic
in
one
place
that
called
that
cause.
That's
V
E,
and
so
this
PR
is
removing
the
special
case
handling
and
if
you
make
a
request
to
the
unsecured
port
you
get
a
super
user
assigned,
and
so
everything
else
that
deals
with
users
can
actually
run
authorization
checks
and
that
user
will
pass
all
those
checks.
A
There
are
a
couple:
work-in-progress
design
pulls
open.
The
threat
model
stuff
is
something
we've
been
wanting
to
talk
through
for
a
while,
so
Clayton
started
that
it's
early
stages.
So
definitely
take
a
look
at
that
comment.
If
there
are
things
that
you're
expecting
to
see
that
aren't
there
mention
them,
we
want
to
make
sure
we
are
comprehensive,
but
also
understandable.
A
So
we
want
to
cover
all
the
bases
and
then,
if
we
want
to
drill
deeper
and
some
of
those,
we
can
maybe
break
those
out
to
different
sections
or
different
box,
but
we
want
kind
of
one
place
where
people
can
look
and
see.
No.
Here's,
my
Network
threats,
here's
my
authenticated
user
threats,
here's
threats
from
a
node,
your
stuff,
some
containers
and
just
sort
of
hit,
although
hit
all
the
bases
and
list
threats.
A
A
E
Sure
yeah
so
I'll
give
you
guys
my
quick
back
story
on
the
pleasure
Roth
plugin
I
was
looking
at
doing
this,
certainly
in
March,
and
we
found
some
problems
with
the
way
that
Active
Directory
issues,
ID
tokens,
apparently
there's
there's
two
versions
of
a
the
adv
one
does
not
sign
the
ID
tokens
when
they're,
refreshed
and
aad
v2
has
no
device
flow
logins.
So
there's
there's
no
good
way
for
us
to
have
users
get
us
a
token,
especially
in
cases
where
the
browser
and
cue
TTL
are
not
on
the
same
actual
machine.
D
E
That
it
looks
like
it
looks
like
there's
two
implementations
one
is:
it
will
try
to
look
into
the
azure
CLI
directory
and
see
if
there's
already
an
access,
token
store
there,
and
if
not,
it
will
actually
go
ahead
and
initiate
the
device
off
flow
whereby
it
will
retrieve
a
token,
after
propping
the
user,
to
take
some
action.
Nice.
A
E
E
E
C
D
C
D
How
the
g-cloud
one
works?
Okay,
actually,
essentially
does
oh
as
a
oh
s,
exec
to
a
like
give
me
an
up-to-date
access
token,
based
on
the
cache
refresh
token,
that
g-cloud
manages
okay,
but
that's
an
entirely
non
interactive
and
not
interactive.
So
if
you
do
revoke
that
refresh
token,
you're
gonna
need
a
user
interactive
flow
through
g-cloud
in
order
to
get
a
new
refresh
token.
Okay,.
E
Off
login
sure
sure
yeah
so
I
think
I.
Think
then
the
the
thing
for
us
to
do
is
I,
don't
think
we
have
like
we're.
Not
we're
not
issuing
it
like.
If
you
look
at
his
code
today,
he's
not
issuing
command
to
get
the
access.
Token
he's
just
reaching
directly
into
the
cache
and
so
I
think
we
would
first
need
to
go
ahead
and
add.
Cli
support
to,
like
you
know,
create
the
equivalent
of
your
car
fake
helper.
That
dumps
out
that
information
or
slash
does
the
refresh
the
dumps
about
that
information,
but
I
I'm.
E
It
seems
totally
reasonable
to
me
to
push
back
on
removing
the
interactive
flow
from
from
the
plug-in
unless
it's
implemented
now.
I
understand
that
concern.
It
makes
sense
to
me
so
I
think
I
will
I
will
give
that
feedback
to
Kozma
and
I'll
probably
go
file
a
bug
on
on
the
azure
CLI
right
now
to
see,
if
they're
willing
to
implement
that,
and
then
we
need
to
to
sort
through
whether
or
not
this
implementation
is
sound.
C
C
E
I'm,
a
little
confused
myself,
I
think
I
think
there's
potential
that
this
two
things
there
one
is.
You
can
use
URLs
as
client,
IDs
and
adjourn
so
it's
possible,
but
that
is
just
the
registered
client
ID
for
the
address
Eli.
The
other
possibility
is,
is
that
I
know
at
various
points
inside
this
client
ID
has
had
special
permissions
that
other
clients
don't
have,
and
so
there
may
be
some
magic
going
on
there.
That
I,
don't
even
quite
fully
know
about
so
yeah.
C
A
That'd
be
great
sure,
appreciate
it.
There
was
one
other
client
off
plug
in.
It
has
actually
been
open
for
a
little
while,
which
is
an
openstack
one,
and
this
is
this-
was
kind
of
along
the
lines
of
what
I
was
expecting
the
adjure
one
to
be
as
well,
which
is
like
taking
making
use
of
known
environment
variables
or
files
that
are
present
in
an
environment
that
is
authenticated
to
this
provider.
A
When
you
are
a
sonic,
you've
authenticated
to
OpenStack
these
environment
variables
are
part
of
like
the
standard,
shell
environment,
and
so
this
is
taking
advantage
of
those
to
obtain
a
token
for
queue
control
to
use.
This
is
dependent
on
an
openstack
token
Authenticator,
which
is
another
poll,
that's
been
open
for
a
while
and
I.
Think
I
would
actually
like
to
see
moved
out
to
a
webhook
implementation,
rather
than
adding
natively,
at
least
to
begin
with.
C
Yeah
I
had
some
I
had
some
concerns
with
the
way
that
it
does
the
transport
stuff.
Actually
so
it
like
yeah.
So
the
current
weight
of
the
client
off
plugins
work
is
that
they
sort
of
rapid
transport
down
lower,
which
means
that,
like
a
go,
HTTP
transport
and
the
way
that
this
does
it
is
it
is,
it
interprets
it
sends
the
request
off
and
then,
if
it
gets
a
forbidden
error,
then
it
goes
and
tries
to
refresh
the
token
and
then
resends
the
request,
which
seems
like
a
very
weird
abuse
of
that
particular
go
interface.
C
It's
like
specifically
denied
by
it
specifically
the
in
the
documentation
that
something
says,
do
not
do
this
so
there's
a
degree
of
like
because
I
don't
know
it
like
does
we
need
to
think
about
how
we're
doing
the
client
off
stuff
for
poor
plugins?
That
don't
have
a
native
way
of
saying
and
looking
at
cooking
and
saying?
Is
this
a
valid
token.
A
A
A
C
C
So
C
is
Korea's
benchmark.
Stuff
is
basically
the
Center
for
Internet
Security
set
these
benchmarks,
they've
done
one
for
docker
and
various
other
things.
The
there's
been
a
lot
of
activity
in
that
particular
in
the
benchmark.
So
I
can
maybe
just
share
my
screen.
Even
yeah
can
I
look
at
my
allowed
to
take
over
for
me,
okay,
yeah.
A
C
So
yeah
the
there's
been
a
ton
of
work
done.
This
website,
maybe
doesn't
have
the
best
you
boy,
okay,
I
mean
just
at
the
bottom
left.
There's
been
a
ton
of
work
done
in
terms
of
like
I'm,
addressing
specific
flags
that
you
need
to
set
on
the
API
server
on
the
scheduler,
on
the
controller
manager,
etc,
etc.
I
don't
necessarily
want
to
go
into
any
of
these
individual
ones.
But
just
as
a
quick
note,
the
timeline
for
this
is
about
six
to
eight
weeks.
C
I
personally
have
not
been
spending
quite
as
much
time
as
I
should
on
this,
but
it
seems
to
align
and
very
closely
with
some
of
the
work
that
sig
off
is
doing
around
talking
about
attack
vectors,
more
holistic
views
of
what
the
general
overall
security
looks
like
for
a
kubernetes
cluster.
There
are
an
insane
amount
of
tickets
from
what
I
can
see
so
because
this
is
going
to
be,
you
know,
sent
out
by
the
Senate
for
Internet
security.
C
I,
think
it'd
be
very
good
if
some
people
from
sing-off
could
come
in
and
who
are
opinionated
about
this
stuff.
Just
to
ensure
that
you
know
the
that
this
recommendation
is
going
to
be
hitting
all
the
faces
so
and
I
don't
have
any
specific
ones
that
I
want
to
talk
about
in
this
meeting,
but
just
a
heads
up
that
the
timeline
is
about
six
to
eight
weeks.
For
this
to
be
about
complete
are.
B
A
B
A
If
you're
interested
I
think
the
instructions
to
to
join
to
get
access
are
in
that
that
forum,
post
and
yeah
definitely
take
a
look,
and
if
you
see
something
that
you
disagree
with
speak
up
and
I
think
the
process
is
intended
to
be
like
consensus
driven.
So
people
who
know
the
area
give
their
opinions
and
like
most
things,
there
are
trade
offs
right
like
if
you
want
this
feature,
you
need
this
setting,
and
this
has
implications
whether
it's
on
or
off
and
and
so
the
more
information
we
can
provide.
A
The
better
informed
people
can
be
when
they're
trying
to
apply
these.
You
can
say
if
I
want
to
be
super.
Secure,
I'm,
gonna,
disable
everything,
but
if
I
want
this
feature,
I
can
enable
Otis,
and
these
are
the
implications
like
we
just
want
to
make
that
clear.
For
people
thanks,
Eric
Eric,
you're
up.
B
Hey
this
is
a
business
item.
Currently
there
are
four
sig
leads
and
I'm
listed
as
one
of
them.
However,
I
spend
almost
all
my
time
on
apps
and
things
other
than
off,
so
in
spirit
of
good
community
membership
and
having
these
reflect.
What
they're
actually
doing
I'm
gonna
announce
that
I'll
step
down
as
a
cig
lead,
so
that
the
list
of
leads
will
reflect.
Actually,
who
actually
does
work?
B
A
A
All
right
and
just
to
follow
up
on
that
I
think
Eric
and
David
and
I
will
talk
it
over
if
people
think
that
we
could
use
more
leads.
That
feedback
would
be
helpful
if
people
are
happy
with
how
things
are
going
and
just
want
to
get
stuff
done.
That's
helpful
to
know
as
well.
We
really
want
to
have
have
enough
people
to
share
the
load
and
not
so
many
that
it
becomes
crazy.
So
so
yeah
we'll
talk
it
over.
If
you
have
thoughts,
feel
free
to
shoot
them
out
the
list,
then
we
appreciate
it.