►
From YouTube: Kubernetes SIG Auth 20170920
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20170920
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
According
all
right,
this
is
sig
off
for
September,
20th,
2017
I
think
we
have
everyone
that
I
know
of
who
was
supposed
to
be
here.
So
we
will
go
ahead
and
get
started
Eric.
You
are
still
there
right,
yeah,
all
right.
So
first
pulls
of
note.
There
is
one
about
trying
to
turn
on
a
PSP
configuration
for
GCE
as
I
recall,
Tim,
st.
Clair,
er,
Tim,
L
clarity
here,
yeah,
okay,
so
as
I
remember
this
one
there
were,
there
was
at
least
one
subtle
problem
ordering
there
was
no
PSP
order.
B
The
so
all
of
the
pod
security
policies
that
are
introduced
in
that
config,
except
for
one,
avoid
this
by
simply
not
setting
any
defaults
and
if
you're
not
setting
defaults,
then
the
ordering
doesn't
matter
the
only
one
that
does
set
defaults.
Is
there
as
sort
of
a
documentation,
or
example,
policy
that
users
might
make
use
of
or.
B
A
The
problem
we
have
experienced
this
downstream
in
OpenShift
and
the
experiences
around
ordering
it
was
a
very
lesson
learned.
You
know
for
a
while
they
have
a
strict
ordering
and
it
caused
some
problems
for
us.
I
think
we
should
really
try
to
wait
here,
because
the
behavior
does
get
to
be
predictable
and
so
things
that
you
create
end
up
creating
differently.
A
B
A
A
A
So
with
the
defaulting,
yeah
I
think
it's
a
clear
this.
Just
this
just
has
to
wait.
Without
the
default
thing
we
could
I
guess
try
to
be
relitigated
but
the
whole
the
whole
API
ends
up
unreliable
that
as
a
whole
right,
not
not
the
specific
example
that
you
may
have,
but
when
someone
starts
trying
to
use
it,
which
comes
more
naturally,
if
these
things
already
exist
and
they're
getting
messages
about
them,
they
might
say:
hey
I
need
one
and
look
it.
A
D
A
A
A
Eric
is
having
a
separate
conversation
on
the
chat
I,
which
I
now
have
open.
Looking
at
a
whole,
we
need
a
holistic
view
of
what
folk
initializers
admission,
control,
inane
ordering
I,
agree
and
I
agree
that
it
would
take
too
long
for
why
but
I
looking
at
this
as
an
opener
for
1/9
I
think
that
Jordan
even
linked
and
I
linked
to
his
poll
or
somebody
else's
pull
that
attempted
to
actually
set
up
the
order
Inc
so
yeah.
A
B
A
E
It
depends
on
the
fix,
so
I
think
one
of
the
problems
with
waiting
here
is
that
essentially
we
we
don't
have
this
good.
We
don't
have
a
way,
then,
to
you
know,
do
the
really
basic
you
know:
block
a
block,
a
root
container
blocka,
a
host
network
post
puff
containers
like
those
really
basic
security
controls
that
kind
of
like
without
those
kind
of
the
other.
E
Some
of
the
other
security
controls
are
working
on
basically
defeated
and
so
without
being
able
to
say
at
a
cluster
level,
we
can
at
least
do
like
those
basic
bits,
then
kind
of
other
security
controls.
We
have
done
don't
work
so
kind
of
like
regardless
of
the
default
issue.
It
sort
of
feels
like
there's
just
a
basic
capability
that
we
need
now
well
so.
A
That
basic
capability
hasn't
hasn't
been
present
in
any
state
different
than
it
is
today
since,
since
we
first
even
introduced,
PSPs
back
was
a
three
three
two
three
or
one
three
one.
Four
so
I
don't
see
that
as
a
change
from
the
state
of
affairs
from
the
seven
I
agree
that
I
want
to
get
better
and
that
we
have
known
issues
and
starts
on
fixes
for
making
those
known
issues
better.
I
think.
C
It
was
more
of
a
bandwidth
issue
in
the
past.
We
didn't
have
bandwidth
to
figure
out
how
to
deploy
this
without
breaking
GCE,
and
we
did
the
work
this
quarter
I'd
like
to
ask
if
this
makes
the
user
more
secure.
I
think
beta
is
known
to
have
some
rough
edges,
but
will
enabling
this
allow
users
to
run
a
more
secure
cluster
because
of.
E
Do
you
think,
there's
no
safe
way
to
use
that,
though,
like
if
I,
basically
just
want
to
have
a
very
simple
policy
like
one
policy
at
the
top
level,
that's
just
no
root
containers,
no
host,
both
no
host
network,
like
that's,
that's
the
basic
control,
y1
or
enforce.
Can
we
do
you
think
we
can
not
do
that
with
with
the
feature
as
it
is
I
think.
A
We
should
do
something
like
turn
on
GCE
until
we've
actually
fixed
known
problems
with
the
API
right
I
mean
like
it.
It's
a
no
problem.
If
you
want
to
turn
it
on
your
deployment,
that's
that's
fine
right.
Wherever
you're
setting
this
up
for
your
GC,
you
turn
it
on,
but
doing
it
across
the
whole,
where
everyone
doesn't
know
to.
B
C
A
A
All
right,
the
the
other
one
that
I
see
linked
here
is
adding
permissions
for
pod
disruption.
Budgets.
A
A
A
The
proposal
looked
pretty
good
to
me
when
I
read
through
it,
we
had
worked
through
the
plugin
registry
for
the
existent
one
that
we
have
now
or
gke.
One
of
the
cloud
providers
now
has
to
see.
Gce
has
one.
This
is
looking
to
use
the
same
mechanism
and
prove
the
interfaces
out
with
the
second
implementation.
A
E
Yeah
so
I
mean
I,
think
the
the
Volk
kms
provider
is
is
pretty
reasonable.
I
think.
The
actual
kind
of
sticking
point
here
is
the
the
plugin
mechanism,
so
I
filed
a
a
bug
that
I
was
I
was
hoping
to
get
the
Google
API
team
to
help
us
out
with
developing
the
mechanism.
If
you
look
at
the
review
for
the
for
the
GCE
one,
it
was
quite
a
lot
of
discussion
there
about.
E
Is
this
the
right
way
to
plug
it
in
and
so
at
the
moment
we've
got
a
plug-in
mechanism
for
cloud
providers,
but
volt
is
not
a
cloud
provider.
So
that
means
that's
not
really
going
to
work
for
this
vault
implementation,
so
there
needs
the
recommendation
was
from
API.
Machinery
was
to
have
a
kind
of
out
of
process
plugin
mechanism,
but
that
doesn't
currently
exist
so.
E
So
I
filed
a
bug
for
that
and
I
talked
to
David
Smith
on
our
team.
It
looks
like
they're,
probably
not
gonna,
have
been
wait
to
work
on
that
I'm
I,
don't
think
we're.
Probably
gonna
have
been
with
to
work
on
it
in
q4,
but
it
would
be
great
if
there
is
possibly
community
desire
to
create
this
plugin
mechanism.
A
I'm,
trying
to
remember
I
thought
that
the
way
we
had
done
was
we
set
it
up
like
the
admission
plugin
registry,
where
you
can
choose
load
particular
packages
and
install
them
as
providers
as
kms
providers,
so
that
you
could
choose
a
particular
call
or
could
choose
to
compile
in
the
plugin
if
they
wanted
to
use
it
same
way
that
we
do
the
admission
plug-ins
today,
where
there's
a
separate
plugins
folder.
That
has
an
order
to
use.
A
You
have
to
import
the
plugins
folder
and
call
a
register
method,
and
once
you
registered
it,
you
you
have
the
import
tree
and
you
start
using
it.
We
use
that
mechanism
to
be
able
to
figure
out
what
it
is
we
needed
to
do
things
in
admission
and
if
you
look
at
some
of
our
other
remote
web
hooks
things
like
authentication
and
authorization,
we
learned
a
lot
by
doing
the
second
implementation.
A
So
if
a
similar
structure
is
possible
with
vault
I
think
that's
something
worth
pursuing
because
as
a
for
instance,
the
the
token
review
endpoint
that
we
use
for
for
delegated
authentication
or
the
subject
access
review
that
we
use
for
delegated
authorization.
Those
calls
would
look
very
different
if
we
hadn't
had
a
second
example
of
the
original
in
process
interface.
G
E
A
A
E
A
C
Yeah
I
just
wanted
to
reenact
the
stock
ument
I,
don't
know
if
anybody
everybody
had
a
chance
to
read
it.
I
think
Eric
looked
at
it,
but
neither
David
nor
Jordan
have
looked
at
it.
Yet
I
wanted
to
get
it
back
on
people's
radar
after
a
feature
freeze
because
I
know,
I
sent
it
out
at
a
busy
time
and
I
was
planning
on
depending
on
how
familiar
people
are
with
it.
I
can
go
through
what
is
proposed
or
we
can
defer
to
another
meeting.
I
was
also
planning
on
renouncing
it
in
the
next
pot
identity.
A
C
Or
it
can
at
least
be
developed
orthogonal
II
in
the
design
that
depends
on
pot
identity.
Of
course,
it
is
blocked
by
the
creation
of
a
positive
energy
system,
but
there's
a
design
where
we
have
a
centralized
server
that
is
similar
to
subject
access,
review
or
token
access
review,
API
that
builds
shots
that
are
time,
bounded
and
scope
bounded
with
audiences.
In
that
version
of
this,
it
is
actually
not
blocked
by
pod
identity
and
it's
kind
of
a
extension
of
what
the
system
we
already
have.
C
C
C
That's
the
goal
nuts
pod,
the
service
count
from
yeah.
So
that's
the
goal
right
now.
The
jots
are
painful,
with
integrations
with
systems
that
you
trust
less
than
the
kubernetes
master,
because
by
sending
it
shot
you
by
sending
that
just
as
they
exist
now
you
give
the
ability
to
for
the
receiver
the
audence
of
that
shot
to
act
as
you
against
the
kubernetes
api
and
anywhere
else
that
that
shot
is
accepted.
A
That
will
help
people
know
whether
they're
interested
in
in
reading
and
reviewing
the
vehicles
I
mean
just
cuz.
It's
a
little
vague
if
you
haven't
tried
doing
it
before
right
right.
What
you're
saying
is
that
right
now,
if
you
give
your
jbt
token
out
for
your
service,
account
to
something
else
to
use
it
you
that
other
thing
now
has
a
long-lived
token.
That
is
valid
against
your
API
server
correct
and
you
can't
eat
without
revoking
the
entire
token.
You
have
no
way
to
take
it
back.
Correct.
C
C
C
A
A
D
H
Well,
lots
of
users
have
start
to
using
these
things,
but
yeah
we're
kind
of
looking
at
what
we
can
do
next
with
all
of
this,
so
I'll
skip
about
a
few
things.
Yeah
starts
out,
we've
got
inverses.
We
want
to
be
able
to
turn
on
TLS,
so
we
had
an
annotation,
that's
a
wedding
good,
but
yeah.
So
how
does
it
do
that?
H
So
volt
is
how
you
want
to
target
just
as
well
just
as
a
sample.
Some
kind
of
a
separate
signing
key
pair
just
stored
in
a
secret
somewhere,
potentially
well
yeah
a
number
of
different
things.
So
on
top
of
that,
I
opened
a
proposal
recently,
which,
hopefully
you
can
still
see
it
I've
had
a
few
quite
a
few
good
comments
on
there
and
just
really
started
to
stretch
my
thinking
on
where
this
can
be
placed,
which
is
good
and
I'm
kind
of
trying
to
work
out
how
this
interacts
with
the
existing
humility
certificates
API.
H
If
there's
anything
that
can
be
done
there,
especially
in
the
bootstrap
process.
For
clusters,
I
think
Mike
Denis
pronounced.
That
right
has
rightly
suggested
that
you
know
we
need
to.
If
we
are
going
to
go
down
that
route,
we
need
to
make
sure
that
we're
not
just
constraining
ourselves
to
what
cube
logo
could
do,
which
is
it
gives
you
a
private
key,
but
actually
more
generalizing,
this
similar
to
the
certificates
API
and
accepting
just
a
plain
certificate,
signing
request
and
signing
that.
H
So
there's
a
number
of
different
things
to
consider
now,
I
think
just
getting
some
feedback
from
people
on
where
we
are
at
the
moment
and
how
will
that
mind
play
would
be
good
yeah
just
to
cover
where
we
are
at
the
moment
we
define
we've
got
bacne
supported
with
DNS
and
HTTP
challenges,
as
well
as
a
simple
signing
key
pair
implementation,
just
to
make
sure
that
we
can
invent
more
than
one
issuer.
So
you
define
your
SEO
specification.
H
There's
quite
a
lot
of
comments
in
here,
and
this
is
not
at
all
final
spent
I
think
it
might
be
changed
in
the
intro
spec
slightly,
but
yeah.
We
define
an
issuer
that
is
able
to
actually
and
out
certificates,
and
then
users
create
certificate
resources
which
are
more
akin
to
difficut
signing
requests.
At
the
moment,
we've
provided
with
kind
of
layering
thin
app
structure
on
top
of
CSR's
with
the
domains
field.
H
The
sort
of
thing
I
think
is
gonna
change
and
develop
into
more
common
names,
old
names
and
then
kind
of
expand
beyond
that
key
usages
and
so
on.
I
think
this
kind
of
goes
back.
The
discussion
point
on,
should
we
just
accept
CSRs,
like
base64-encoded
and
at
least
some
level
in
our
API,
or
can
we
just
piggyback
on
the
existing
certificates
API
for
it
yeah,
so
other
things
that
we
are
not
there
as
well?
H
It's
kind
of
daunting
at
least
some
kind
of
a
similar
mechanism
to
the
certificates
API
with
an
audit
trail,
so
I
really
like
what
is
there
at
the
moment
where
we
can
see
who
created
the
request
and
when
it
was
last
changed
and
so
on?
It's
that
sort
of
thing,
yeah
and
eventually
I
think
proposing
that
we
move
into
cube
Nettie's
incubator.
If
we
can
kind
of
find
a
common
position
for
this,
that
all
of
these
different
projects
that
corrupt
solve
the
problem
and
tried
to
address
yeah
I
think
some
guys
with
giant
swarm
attack.
H
H
This
could
kind
of
fall
into
place
there,
so
yeah
we're
kind
of
looking
for
incubators
on
them.
Now
sorry
I
see
on
the
now-closed
incubator
them
stuff.
So
hopefully,
when
that
opens
up
again,
we
can
reconsider
potentially
moving
into
there.
I
know
if
there's
any
questions
from
people
on
the
whole
project
or
thoughts.
Thank
you.
A
C
I
have
I
think
they
target
different
use
cases.
The
our
certificates,
API
I,
think,
is
not
ever
not
conceivably
going
to
issue
publicly
trusted
certificates
in
the
near
term.
I
see
a
lot
of
value
and
stuff
like
cube
Lego
and
your
certificates
manager
being
able
to
provision
less
encrypt
certs
for
ingress
and
other
publicly
facing
services.
C
I
see
I
have
some
secured
I,
don't
know
if
these
projects
target
or
plan
to
target
workload,
identity
or
container
identity
and
I'd
like
to
note
that
the
development
on
the
CSR
API
SAR
is
kind
of
up
in
the
air,
depending
on
where
we
decide
to
go
with
pot
identity.
If
we
decide
to
make
that
x.509
pact,
for
instance,
that
could
that
could
inform
the
future
direction
of
the
CSR
api's.
C
So
as
far
as
public
serving
certificates,
I
think
that's
very
useful.
The
secrets
mechanism
is
a
distribution
through
secrets
mechanism
is
a
little
worrisome
and
painful
I.
Also
don't
like
how
these
public,
if
we
are
using
the
ingress
controller
and
how
it
is
deployed
today,
these
publicly
trusted
certificates
and
private
keys
are
available
on
the
file
system
of
every
single
node.
That's
that's.
C
A
little
bothersome
I
would
like
potentially
to
move
to
deployments
where,
if
we
were
using
something
like
this,
we
would
we
would
isolate
ingress
to
dedicated
machines
and
only
allow
secrets
to
be
pulled
from
those
dedicated
machines.
The
other
thing
is
then
I
think
is
a
question
for
the
bootstrap
committee
that
has
come
up
recently
and
it's
one
of
the
reasons
why
we've
halted
incubation
is
I,
don't
know
if
it's
very
clearly
defined
where
the
kubernetes
ecosystem
begins
and
the
Corrine
ADIZ
project
ends.
C
H
Ingress
control
was
mounting
it
in
kind
of
how
these
are
used,
isn't
so
much
seven
at
the
moment,
as
Mike
said,
and
we
target
since
secret
resources.
I
think
the
delivery
mechanism
is
definitely
something
to
be
considered.
It's
not
something
we
want
to
get
particularly
involved
it.
It's
open
to
looking
alternative
secrets
right
now
seem
to
make
sense
and
be
sending
secret
and
the
advancements
going
on
there
yeah.
Absolutely
all.
A
Right
so
moving
on
just
to
the
very
last
thing:
I,
don't
think.
I'm
gonna
bother
switching
the
projection
back
on
support,
unequivocal
Bolton
I
in
a
union
authorizer.
This
is
basically
a
way
to
a
similar,
Halle,
Union
authenticators,
it's
a
way
to
Union
and
authorize,
or
so
that
the
authorizer
can
say
no
not
this
and
can
deny
the
request
without
passing
it
through
to
the
rest
of
the
chain.
I,
don't
remember
who
opened
this,
but
it
seems
like
a
pretty
reasonable
thing
to
do
to
me.
C
These
are
things
that
we
want
to
prevent
the
user
from
doing,
and
we
think
that
it's
reasonable
to
assume
that
the
user
did
not
mean
to
do
these
things
with
the
current
model
of
authorizers.
This
doesn't
fit
since
it
is
an
or
relationship
between
the
authorization.
Decisions
between
different
authorizers
and
alternative
to
this
would
be
to
use
an
admission
controller,
but
it
feels
heavy
weight.
C
C
A
Mean
not
getting
into
the
weather
I,
how
I
feel
about
particular
usages
of
it
I
think
it's
a
reasonable
thing
to
do.
I.
The
only
thing
I
would
worry
about
is
trying
to
build.
Some
sort
of
sane
can
figure
out
that.
So,
whenever
you
open
the
poll
that
goes
to
to
implement
something
like
this
I
think
I'd
want
to
see
how
you
would
wire
that
up
with
flags.
A
G
Not
a
suggestion
on
the
thread
which
was
set
aside,
how
we
do
the
compatibility,
but
like
going
forward,
do
anding
instead
of
Oren.
How
that
would
address
all
the
needs
and
it
would
remove,
would
not
have
ordering
as
an
issue,
and
it
would
make
it
so
that
it's
consistent
with
how
we
do
admission
control
I,
don't.
G
A
G
I,
just
think
that,
if
think
so,
that
I
think
I'm
glad
we
agree,
we
needed
to
be
able
to
say
definitely
did
I.
Think.
The
question
is
whether
or
not
to
go
with
a
tri-state
model
or
which
that
opens
up
a
lot
of
other
questions
or
go
with
and
only
model
which
doesn't
allow
us
to
go
to
those
other
questions.
Yeah.
C
I
mean
that
the
Antoni
model
doesn't
make
sense
to
me
off
the
bat,
so
imagine,
I
am
and
our
back
integrating
and
I
have
some
I
am
roles
that
match
and
allow
specific
actions
on
a
cluster.
But
then
there's
a
subset
of
there's
a
bunch
of
roles
that
are
there's
no
interactions.
I
could
take
against
I.
Am
that
don't
match
any
rules?
How
would
I
am
be
able
to
not
return?
True,
all
the
time
on
a
lab,
a
system.