►
From YouTube: Kubernetes SIG Auth 20181018
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20181018
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
B
Today
we
have
a
a
few
positive
note,
some
design,
one
design
of
note
nothing
in
the
discussion
section.
So
maybe
it'll
be
a
short
one.
If
anybody
has
anything
they
want
to
drop
and
the
meeting
notes,
please
do
that.
First
up
we
have
a
Matt
Moyer
of
FDA.
Talking
about
the
AWS
I
am
a
web
cook.
Authenticator
Matt.
Do
you
want
to
show
your
screen
or
just
a
chat
about
I.
C
C
B
C
So
it's
sort
of
like
you,
you
run
the
daemon
set,
runs
on
each
master,
node
self
signs
a
CA
for
itself,
the
first
time
it
runs,
generates
the
webhook
coop
config,
splits
it
down
on
disk,
and
then
you
have
to
go
sort
of
update
your
api
server
with
that
webhook
flag,
which
actually,
I
think,
works
out
reasonably
well
in
terms
of
ease
of
use.
I'd
still
would
love
to
see,
there's
an
open
issue.
C
B
B
Looks
like
we
don't
have
any
demos
today.
So
the
next
item
is
the
pools
of
note.
First,
there
was
a
PR
for
allowing
authorizers
to
return
unequivocal
denies.
So
this
would
allow
the,
for
instance,
a
web
hook,
authorizer
to
say
I,
don't
care
what
our
back
says
or
any
other
author
either
in
the
system
says,
do
not
allow
this
action,
basically,
no
matter
what
I
saw
that
it
was
updated
recently,
I,
don't
know
if
there's
specific
outstanding
concerns
there
I
don't
know
if
I
think
that
was
Mike
Denis
you
had
that
open.
D
B
D
B
Okay,
next
item
is
that
there
was
a
PR
for
aggregated.
Our
back
rolls
that
was
put
up
by
David.
Eads
I
know
that
that
was
know
that
that
was
to
address
some
of
the
concerns
around
some
of
the
the
inability
to
add
additional
policies
or
permissions
to
the
existing
default
rules
looks
like
that.
That's
a
good
conversation
and
from
what
I
saw
I
looked
pretty
reasonable,
don't
know
if
anybody
else
had
additional
comments
on
that.
B
E
So
I
do
see
them
switching
I
actually
think
I
see
them
switching
in
1/9
I'm,
going
through
the
migration
impact
and
there's
both
at
the
dock
and
a
code
pool,
depending
on
how
you
like
to
review.
But
the
code
poll
shows
how
reconciliation
would
happen.
I
think
the
only
outstanding
question
about
migration
is.
E
If
someone
has
already
edited
these
roles,
are
we
going
to
create
a
synthetic
role
for
them
to
aggregate
it?
I
am
fine
with
doing
that.
It
would
just
be
one
more
bit
of
code
that
we
would
be
hanging
on
to.
It
was
I
think
the
only
comments
I've
seen
in
the
doc
have
been
largely
positive
and,
in
the
code
have
been
around
how
you
do
the
particulars
of
reconciliation.
F
F
E
F
Look
at
the
design
that
lays
out
pretty
clearly
how
how
nice
this
is
for
having
a
single
manifest
that
can
set
up
your
CR,
D
and
you're
contributing
roles
or
if
you're,
doing
aggregation,
API
server.
You
can
define
your
deployment
and
your
service
and
your
API
service
and
your
role
contributions,
and
it's
one
manifest
and
it's
pretty
awesome,
then
you
can
remove
all
of
those
things
and
they
all
just
go
away
and
get
ripped
out.
B
B
B
D
D
Maybe
just
if
you
get
some
really
quick,
essentially
it
gets
away
from
some
of
the
issues
with
the
centralized
model
brings.
It
brings
the
decentralized
model
closer
to
a
standard
validation
practice.
It
uses
a
proof
of
possession
proof
of
possession
tea
semantics
to
find
shots
usage
of
shots
to
key
pairs
so
that
the
workload
holds
and,
for
this
reason,
I
think
we
can
feel
more
comfortable
for
making
the
long
lived
the
jots
issued
by
the
central
authority
more
long-lived.
So
in
this
model
the
central
authority
would
build
a
jot
valid
for
48
hours.
D
D
Propagation
of
end
user
credentials
into
API
layers.
So
notably,
if
you
have
a
large
service
that
provides
that
you
provide
some
product
offering
to
many
tenants,
you
might
not
want
to
take
what
your
front
ends
like
your
nginx
is
say
for
granted.
So
if
you
terminate
TLS
at
the
edge
of
next
layer,
you're
not
going
to
be
able
to
propagate
an
end-user
credential
into
an
API
such
that
it
is
valid
a
table.
So
this
this
is
a
noted
advantage
of
the
jot
model
that
provides
very
similar
security,
semantics
to
TLS
and
also
the
semantics
Mike.
D
Client
TLS
works
really
well.
Mutual
TOS
works
very
well
just
for
service
to
service
communications.
It
does
not
work
well
when
you
want
an
end-user
credential
to
propagate
in
too
many
layers
of
an
API.
So
if
you
is,
if
you
have
the
user,
that
say
you
have,
you
are
AWS
and
you
have
or
Google
Cloud,
and
you
have
a
user
that
authentications
using
x.509
you
kind
of
delegate,
you
kind
of
trust,
implicitly
your
front-end,
which
are
which
are
exposed
to
the
world.
A
Ok,
so
let
me
put
this
in
critical
terms.
So,
like
I
login,
you
know
to
Gmail
Google
as
Joe
Beda,
gmail.com
right
and
maybe
there's
the
Google
front
end
and
then
that,
like
authenticates,
that
session
cookie
for
the
browser-
and
then
it
tells
say
maybe
the
Gmail
front-
end
hey.
This
is
Joe
betta
gmail.com
and
then
that
that
thing
then
goes
ahead
and
tells
the
the
backend
hey.
This
is
Joe
Beda
gmail.com
and
there's
no
sort
of
like
strong
assertion
from
the
guy
who
authenticated
it
all
the
way
down.
D
C
So
the
values
case
to
consider
that
like
mutual
TLS
does
not
survive
ingress
or
egress
in
most
environments,
like
the
ingress
case,
is
like
the
one
you're
talking
about
where
you
have
some
set
of
like
load,
balancing
tiers
that
terminate
TLS,
and
you
can't
can't
pass
a
valid
a
table
assertion
about
the
user
through
that
ingress
system,
and
then
you've
also
mentioned
in
the
past.
Like
egress
filtering,
is
also
a
thing
in
a
lot
of
environments
right,
you
can't
survive
egressing
your
network
without
breaking
TLS.
A
Who
is
this
I
mean
is:
is
this
another
layer
on
top
of
mutual
TLS?
For,
like
you,
have
mutual
TL
of
s
for
service
to
service?
But
then
you
know
combined
with.
That
is
a
job
that
actually
sort
of
says.
Well
now
I
have
a
live
end
user
and
this
thing
is
short-term
yeah.
Exactly
so,
I
mean
on
how
Google
does
some
of
the
stuff
internally,
it
may
have
changed
and
read.
There
are
of
different
ways
to
skin
the
cat
here
and
I:
don't
want
to
start
spewing
code
names
and
everybody
yeah.
D
D
Service
identity
doesn't
go
through
the
front
end
when
I'm
sorry,
service
identity
doesn't
generally
does
not
all
right.
Does
not
the
the
critical
path
does
not
involve
the
front
end
so
essentially
you'd
say
nginx.
You
terminate
TLS
you're
allowed
to
say
that
any
user
was
on
the
other
dialling
end
of
this
connection
and
I
must
trust
you.
F
One
question
I
would
have
is
when
the
audience
was
baked
into
the
jaw.
What
audio
and
you're
expecting
this
to
probably
gate
through
multiple
layers?
Who
would
be
audience
B?
Would
it
be
the
front
end
or
would
it
be
the
ultimate
back
end
destination
and
how
would
the
client
know
the
ultimate
back-end
destination
right.
G
D
F
D
A
Realm
in
my
mind,
that
seems
like
a
layered
thing
like,
because
you
have
service
to
service
authentication,
and
then
you
have.
How
do
you
now
propagate
end-user
affinity?
You
know
identity
across
this
stuff,
which
is
that
which
seems
like
a
it
seems
like
these
things
should
be
layered
on
top
of
each
other
and
that
that
wasn't
clear,
at
least
in
my
mind
from
the
from
the
way
this
was
set
up,
yeah.
D
I
think,
with
especially
integrations
with
large
companies
with
many
customers.
This
is
going
to
be
preferable
as
the
third-party
integration,
especially
as
since
we
can
make
these
shots
compliant
with
oh
I,
see
the
OID
C
select,
so
suppose.
A
large
provider
like
AWS
or
Google
supports
custom.
Oh
I,
DC
providers,
then
we
can
use
these
jots
to
authenticate
as
identities
in
those
systems
is.
D
D
Well,
there's
also
the
possibility
that
suppose
a
integrator
did
not
implement
this
standard.
Then
we
could
fall
back
to
the
central
authority
issuing
short-lived
shots,
so
that
was
the
model
one
in
the
first
doc.
I
think
that
is
valuable
in
the
theorem.
While
people
want
to
and
implement
this
standard,
but
it
does
have
availability
concerns
pointed
out.
So,
okay.
D
A
To
be
I'm
a
little
bit
confused
too,
because
the
objective
on
the
document
says
this
document
describes
how
to
extend
kubernetes
to
support
jots
testing
to
workload,
identity
that
are
variable
verifiable
by
third-party
integrators
discussion.
We
just
had
wasn't
about
workload.
Identity
is
about
end-user
identity.
That
is
actually
sort
of
transferable,
yes
workplace.
So.
A
A
But
from
users
of
kubernetes,
the
end-user
would
be
like.
Let's
say
that,
like
we
have
like
a
hosted
hefty
Oh
SAS
solution
and
we
have
people
log
in
and
maybe
we're
using
auth0
or
something
like
that.
That's
the
thing:
that's
actually
going
to
sort
of
identify,
end
users,
and
so
there's
this
question
of
like
okay.
If
we
have
a
chain
of
micro
services
and
we're
passing
around
some
sort
of
identity
token,
for
our
end
users,
that's
that's
a
different
thing
than
talking
to
Google
and
I.
A
Don't
want
Google
to
know
about
my
end,
users
right,
there's,
no
right,
yeah
and,
and
similarly
the
you
know,
there's
their
securing
the
individual
links
in
the
chain
of
a
big
call
stack
of
micro
services
and
then
also
having
the
sort
of
you
know
some
cryptographic
identity
of
the
end
user
being
passed
down
such
that.
You
know
that
those
seem
like
those
are
so
it
seems
like
we
have
three
different
scenarios
that
we
have.
You
know
how
do
we
actually
identify
through
proxies
to
something
like
Google?
A
D
Right
so
this
this
targets,
the
situation
where
we're
kubernetes
is
an
identity
provider
work,
individual
workloads,
individual
service
counts,
our
identities
provided
by
the
kubernetes
identity
provider
and
the
a
third-party
like
Google
cloud.
Google
cloud
platform
wants
to
authenticate
identities
by
from
the
kubernetes
identity
provider.
So
this
is
the
situation
where
the
end
users
are
kubernetes
workloads,
I'd,
I,
don't
want
to
speak
more
generally
than
that.
Okay,
okay,.
A
D
D
D
D
A
D
Into
that
so
AWS
offers
configuration
of
a
customer.
Id
see
providers.
So
you
say
this
are
icgc
provider
is
allowed
to
issue
identities
under
this
namespace
which
the
namespace
is
the
issuer
you
well
so
I
could
I
could
just
curl
the
GC
meditator
server
exchange
that
transparently
with
it'll
be
used
API.
So
if
I
have
that
configured,
my
age
abuse
project.
Okay-
and
this
is
all.
A
It's
no,
it's
not
a
jot.
It's
like
its
own
and
it's
it's
mostly
used
I,
think
to
to
verify
that
say:
you're
running
a
Red
Hat
image
when
you
go
and
ask
for
Red
Hat
support
or
when
you're
actually
going
through
and
talking
to
the
right.
So
it's
more
along
the
lines
of
being
able
to
identify.
You
know
whether
you're
paying
for
a
for
a
premium
image
I
believe,
but
it's
been
abused
for
other
things
like
as
a
attestation
for
things
like
fall.
D
A
D
C
D
So
the
central
issue
model
is
really
easy
to
implement,
so
I'll
discuss
the
distributed
model.
That
is
in
the
second
talk.
Essentially,
a
note
agent
would
using.
This
is
how
I
would
prototype
it.
A
note
agent,
using
the
cubelet
no
credentials,
would
request
on
behalf
of
a
workload
that
long-lived
shot
to
create
that
request.
It
would
have
to
generate
a
key
pair
and
it
would
hand
both
of
those
somehow
to
a
workload
or
it
would
keep
them
in
escrow
and
that
workload
could
request
short
short
lived
proof
of
possession
shots.
D
So
the
combination
of
this
long
live
shot
and
the
proof
of
possession
shot
or
the
long
live.
Dada
Central
signed
by
the
central
authority,
which
is
could
be
an
OID
C
provider
and
the
short-lived
odd
is
assigned
by
the
proof
of
possession
keys,
the
public,
key
of
which
is
claimed
inside
the
confirmation
field.
A
claim
of
the
central
authority
issued
John.
The
combination
of
those
presented
to
a
third
party
recipient
would
prove
that
the
central
authority
batches
for
the
workload
and
the
workload
possesses
a
key
that
the
central
authority
has
confirmed.
D
A
C
D
A
Of
using
x.509
certificate
signing
in
Chains
you're,
using
essentially
a
JA
to
sign
the
public,
you
know
you
have
the
second,
the
permanent
job
essentially
signs
the
public
key
and
then
to
verify
that
you
have
to
sort
of
call
back
to
the
to
some
sort
of
central
server
to
validate
that.
That's
that
long
live
job.
You.
A
A
F
C
F
C
F
D
F
D
Way
to
do
this,
so
there's
two
ways
that
you
can
divide
proof
of
possessions
into
two
ways:
you
can
sign
a
request
or
the
server
can
encrypt
a
response.
So
the
if
GCP
I
am,
was
returning
responses
using
I
encrypted
at
with
the
public
key
as
JW
ease.
Then
it
would
require
possession
of
the
private
key
to
decrypt
and
if
those
were
held
in
escrow,
then
turning
off
the
machine
or
turning
off
the
TPM
that
stored
those
keys
would
make
any
jots
that
had
been
previously
created,
useless.
A
A
A
You
have
more
flexible
down
scoping
available
to
you
because
we're
not
you
know
you
could
technically
do
this
stuff
with
x.509,
but
practically
it's
a
total
pain
in
the
butt
to
deal
with
asn.1
extensions
and
validation,
and
all
that
most
libraries
don't
support
that
right.
So
we
get
marked
much
more
flexible
down
scoping
and
then
there's
OID
C
compatibility
here
so
that
you
can
interrupt
for
essentially
presenting
these
things
as
proof
to
other
systems.
D
F
A
A
What
type
of
proof
you
want
for
which
audience
that's
something
that
is
very
much.
You
know
similar
to
the
to
the
spiffy
workload
API
or
at
least
the
stuff
that
we've
been
sketching
out
there
and
and
for
me
I
like
that,
a
heck
of
a
lot
better
than
just
laying
down
some
static
stuff
on
disk.
So
I
don't
think
this
is
necessarily
incompatible
with
with
at
least
the
way
that
folks
have
been
thinking
about
it.
But
I
I
know
that
that
hasn't
been
something
that
has
been
front
of
mine
for
folks
right
now.
D
C
A
We
do
have
the
problem
right
now
we're
with
kubernetes,
where
there
is
no
connection
between
the
service
that
you're
calling
and
the
service
account
that
the
pods
behind
that
service
might
have
access
to
right.
So
we
still
need
a
way
to
essentially
say
you
know:
hey
I'm,
a
pod
I
want
to
be
able
to
get
some
certificate
that
can
prove
that
I
should
be
listening
on
this
service
right.
We
don't.
We
don't
have
a
solution
there,
the
the
Google
solution
there
is,
this
thing
called:
what
is
it
like
trusted?
A
It's
essentially
sort
of
you
augment
the
service
discovery
with
the
sort
of
the
end
credentials
that
you'll
actually
be
talking
to
so
as
part
of
service
discovery.
You
get
back
from
that
sort
of
like
here's,
the
identities
of
the
things
that
you're
going
to
be
connecting
to
that
are
different
from
the
service
identity.
A
Early
on
when
we're
talking
50
in
that
model,
the
you
know
my
opinion
there
is.
That
is
that
that
breaks
this
facade,
that
that
the
this
service
should
prevent
a
unified
front
and
it
works
when
you
have
sort
of
semi
trust.
You
know
and
you're
not
worried
about
knowledge
leakage,
but
like
in
cases
where
you
are,
you
may
not
want
those
identities
that
are
implementing
this
thing
behind
the
scenes
to
actually
leak
out.
A
F
D
D
C
So
I
also
like
you're,
like
the
centralized
portion
of
this,
isn't
involved
in
rotation,
not
the
short-term
rotations
at
all.
So
it's
sort
of
only
involved
when
you
schedule
any
workload.
Any
workload
starts
on
on
the
node
right.
That's
why
you
still
have
a
decentralized
control
over
like
the
each
individual
node
can
only
possibly
issue
tokens
for
workloads
that
are
on
that
node.
D
F
C
A
A
D
Hey
its
and
I'm
looking
inwards
and
I,
there
are
certain
situations
where
we
do
use
network
as
an
identity,
but
it
it's
a
lot
easier
because
we
run
each
one
of
our
users
as
different
UNIX
user.
So
we
can
actually
inspect
sockets,
since
our
users
are
crazy
and
run
everything
is
route.
I
think
I
would
prefer
using
a
UNIX
domain
socket
and
exposing
a
G
RPC
interface
over
ETS
that
makes
sense
and
that
that
works.
A
D
D
A
C
D
A
So
what
I
would
do
is
I
would
I
would
have
an
annotation
or
some
value
on
a
pod
saying
give
me
a
forever
token
and
I
would
make
that
be
opt
in
and
then
I
would
actually
update
the
the
client
libraries
to
actually
do
it
so
over
time.
At
some
point,
people
with
new
client
libraries
won't
have
to
set
that
magic
thing.
I
mean
you
got
to
start
deprecating
it
somehow
I
mean
week.
A
C
G
A
D
A
A
I
asked
is
that
they
put
some
documentation
that
things
saying
that
this
thing
is
kind
of
very
early
quality.
There's
known
issues
with
it
and
like
don't
copy
this
pattern
elsewhere
right.
It's
like
some
caveats
there
around
like
look.
This
may
work
for
vault
is
we're
going
to
trust
ball
with
with
the
company
jewels,
but
you
know
don't
cop,
this
pattern
elsewhere,
because
I
think
a
lot
of
people
looking
involved
for
good
or
ill
as
a
as
a
reference
in
terms
of
how
you
actually
do
certain
types
of
cross
service,
authentication,.
D
B
Right
any
final
comments
on
my
niece's
proposal:
I'm.
D
A
A
A
D
A
D
A
D
A
A
C
I
agree:
I
would
also
like
to
see
something
like
this
eventually
be
in
kubernetes
core
as
the
default.
That's
always
if
you
serve
you're
writing
an
application
that
runs
on
kubernetes.
It
can
rely
on
this
mechanism
I.
Don't
think
that
necessarily
means
that
it
needs
to
be
named
with
kubernetes,
because
I
think
it's
also
something
that
could
be
available
on
other
systems,
not
kubernetes.