►
From YouTube: Kubernetes SIG Auth 20180919
Description
Kubernetes Auth Special-Interest-Group (SIG) Meeting 20180919
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
B
I
just
wanted
to
put
out
a
general
reminder
to
everyone
that
this
is
our
shortest
release:
segment
of
the
year
so
plan
on
having
less
time
to
develop,
features
that
you
want
to
get
in
113
and
if
you
are
working
on
the
design
for
a
new
feature.
The
designs
should
really
be
should
really
be
in
the
review
stage.
A
A
All
right,
the
next
item
that
I
wanted
to
discuss,
I'm,
not
sure
if
anybody
was
interested
in
this,
it
is
potentially
extending
image
pull
credentials
to
supports
a
flow
based
on
the
service
account
tokens.
So
now
that
we
have
service
account
to
Kim's,
they
can
be
more
tightly.
Scoped
to
usage,
I
think
there's
a
reasonable
argument
to
be
made
that
we.
A
Can
start
using
them
as
a
replacement
for
image,
pool
secrets
and
environments
that
I
can't
support?
That
is
such
a
token
flow.
I
think
just
Clayton
had
mentioned
this
a
while
ago.
In
a
maybe
a
container
I
didn't
need
working
group.
The
idea
is,
if
you're
unfamiliar
the
image
pool
secrets
right
now,
how
they
work
is.
A
A
A
So
the
proposal
in
this
issue
that
I'll
drop
into
a
cap
or
something
is
that,
instead
of
using
an
image
pool
secret,
we
use
a
service
account
token
or
with
potential
exchange,
with
a
a
token
exchange,
with
an
with
an
OAuth
server
so
and
then
use
the
either
the
service
account
token
or
the
OAuth
token,
to
authenticate
to
the
docker
registry.
Instead
of
the
image
pool
secret,
and
this
solves
a
couple
of
problems,
people
don't
have
to
maintain
secrets
for
for
their
that
have
credentials
to
their
docker
registry
and
that
makes
rotation
easier.
A
A
C
A
D
C
Not
a
straight
password,
it
doesn't
have
to
be
a
pepper
to
give
me
a
token,
that's
associated
with
Yuriko,
but
you
log
in
and
retrieve
mm-hmm.
But
but
my
my
concern
is
that,
like
I,
don't
know
how
that
would
map
to
I,
don't
know
how
to
get
there
from
I.
Don't
know
how
to
get
from
there
to
service
counters
right.
C
A
C
Totally
gets
a
security
problem.
I
agree
that
secrets
have
to
be
rotated,
maybe
there's
a
way
to
create.
Now.
You
know
not
always
and
provide
more
pressure
to
do
that
right,
like
when
they
populate
a
secret
or
a
token
that
is
known
to
be.
It
is
known
that
where
it
will
know
where
it
is
known
that
it
will
become
stale
that
you
somehow
set
up
some
sort
of
that
we
report
on
the
age
of
that
secret
as
an
error
level
thing
like
whether
that's
a
matrix
level
thing.
D
A
E
So
I'm
trying
to
reason
about
how
this
would
work
in
similar
to
like
what
open
shipped
us
today,
because
it's
been
a
long
time
since
I
looked
this
in
the
in
of
the
ship.
But
if
I
recall
correctly,
we
like
basically
do
what,
like
the
Kuebler
does
with
image
stickers.
We
just
do
a
token
review
and
then
SAR
our
way
to
victory
I'm,
trying
to
figure
out
how
this
would
fit
in
and
I'm,
not
exactly
sure
we're
like
where
the
OAuth
flow
comes
in.
So.
A
A
E
So
if
I
understand
it
correctly,
if
you
were
someone
who
was
kubernetes
aware-
and
you
were
building
a
registry-
certainly
today,
you
could
use
token
review,
subject
access
review
and
everything
to
be
very
carefully
built
audit
and
support
rotation
and
so
forth
for
tokens.
If
you
are
not
that
person,
but
you
are
a
normal
registry
that
supports
oh
I,
DC
and
perhaps
some
forms
of
claims
support
within
those
tokens
because
kubernetes
service
account
tokens
are
kind
of
close
enough
to
that.
A
From
registries
that
understand,
kubernetes
tokens
to
registries
that
understand
to
bear
tokens
I,
so
it's
it's
a
it's
a
larger
set
of
registries,
I
think
it's
almost
all
registries.
At
that
point,
it
will
require
somebody
right
code
to
implement
the
exchange,
how
they,
how
they
would
like
to
implement
it,
but
it
does
close
that
gap.
That's
the
idea,
I
think
that,
for
something
like
hosted,
their
self
hosted
registries
like
what
open
ship
does
I,
don't
believe
that
it
took
an
exchange,
provides
value.
C
I'll
say
that
in
the
field
working
with
customers
trying
to
resolve
issues
around
image
poll
secrets,
frequently,
we
are
in
a
state
where,
like
we
have
to
figure
out
how
to
create
that
our
config
file,
so
that
locally,
so
that
we
can
determine
like
whether
just
straight-up
Gawker
can
pull
an
image.
And
then
once
we
have
that
all
figured
out.
We
then
put
that
up
as
a
as
I
see
creating
associated
with
the
circle
account,
so
that
so
that
we
know
how
to
do
that
so
like
whenever
semantic.
C
A
But
the
the
token
returned
from
a
I
know:
I
took
an
exchange.
Endpoint
could
be
you
know,
peak
access
token
as
well.
It
doesn't
necessarily
have
to
be
an
I
yeah
I'd
like
a
EC
ID
token,
that
is
int
respectable
and
it
could
just
be
Hubb
style,
api
key
or
not,
no
auth,
token
or
I.
Guess
no,
no,
no
I
thirteen!
It
has
to
be
a
bare
token,
but
it
could
be
where
I
took
in
where
the
resource
owner
is
the
Authenticator
and
authorizer
for
the
specific
resource
space.
E
D
E
A
Yes,
so
maybe
so,
if
this
a
token
with
an
audience
of
the
registry
is
allowed,
is,
is
intended
to
use
as
credentials
to
authorize
an
image
pool,
pull
the
subject
of
the
token
the
authorized
principal
might
be
authorized
to
pull
some
images
but
not
authorized
to
pull
other
images,
so
you
make
an
authorization
decision
based
on
the
subject.
I,
you
decide
you,
you
bind
the
token
to
the
usage
as
an
image,
both
credential
using
the
audience.
Okay,.
A
A
F
B
F
B
B
We
ultimately
decided
that
koruna.
Ds
is
just
such
a
big
project
with
so
many
different,
like
valid
configuration
setups
that
it
was
going
to
be
really
difficult
to
do
that
and
so
kind
of
where
we
landed
was
just
trying
to
enumerate
pieces
that
we
considered
in
scope
and
then
explicitly
list
things
that
we
consider
out
of
scope
for
the
program
as
well
and
there's
certainly
a
lot.
That's
missing
from
this
document
and
there's
a
lot
of
gray
area
between
What's
in
scope
and
out
of
scope.
B
That's
not
covered,
and
the
hope
is
that,
as
we
as
we
start
receiving
reports
and
as
folks
start
to
kind
of
like
look
at
look
at
bugs
and
kind
of
see
how
it
fits
into
this
document.
That
we
can
kind
of
grow
the
document
and
and
sort
of
narrow
it
to
cover
those
specific
use
cases.
So
definitely
viewing
this
as
kind
of
like
a
living
document
and
expecting
just
sort
of
crowdsource
a
lot
of
the
detail
on
the
scope.
F
F
The
stupid
lease
container
escalations
and
escapes
to
the
host,
which
are
not
specific,
to
kubernetes
same
thing,
with
some
expert
legislations.
Any
attacks
from
the
host
site
that
the
containers
are
running
on
or
relying
on
deprecated
components
and
vulnerabilities
in
a
specific
setup
or
vulnerabilities
and
components
of
communities
depend
on
such
as
a
to
you.
G
G
F
A
B
One
other
thing
to
mention
on
that:
we
are
in
the
process
of
working
on
laying
out
a
bit
more
about
the
governance
of
the
product
security
team
and
possibly
opening
up
some
new
roles
within
that
team
that
are
more
handling
more
of
the
kind
of
public
security
issues
in
the
bug.
Bounty
would
definitely
fall
under
that
area
as
well.
So,
if
you're
interested
in
getting
involved
with
that
more
stay
tuned.