►
From YouTube: Intro: Auth SIG - Mo Khan, Red Hat & Mike Danese, Google
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: Auth SIG - Mo Khan, Red Hat & Mike Danese, Google
We will present a high level overview of the SIG with an emphasis on recent accomplishments. Furthermore we will discuss immediate goals for the next few releases to help prospective individuals understand where they can get involved. This structure of presentation is similar to what we did in KubeCon NA 2018 - we received generally positive feedback from the community members.
https://sched.co/MPh3
A
A
So
there's
a
lot
of
people
sort
of
involved
in
this
tim
is
not.
Here
is
the
last
remaining
chair.
If
you
guys
hang
out
on
the
curry
night
slack
channel,
you
will
be
very
familiar
with
some
of
the
stuff
project.
Approvers
Jordan
is
probably
the
most
commonly
seen
individual
and
all
of
the
create
a
slack
channels,
but
Clayton
David.
Both
a
lot
of
other
individuals,
are
very
deeply
involved.
We
do
have
a
lot
of
sub
projects
that
have
a
very
distinguished
set
of
individuals
that
sort
of
carry
on
with
them.
A
So
nothing
is
ever
complete
with
our
without
our
favorite
xkcd
slide,
but
as
autumn
flies,
it
is
slightly
ambiguous.
We
do
cover
both
authentication
and
authorization,
but
there's
a
larger
set
of
domains
within
the
kubernetes
ecosystem
that
we
cover
auditing
falls
under
that
category,
as
well
as
security
policies
such
as
PSPs,
but
what
I
think
sometimes
people
miss
from
this
is
some
of
the
largest
sub
projects,
such
as,
like
encryption
at
rest,
still
fall
under
US
as
well
as
certificates
or
the
CSR
API
note
isolation,
there's
a
sub-project
on
multi-tenancy.
B
B
B
A
A
B
B
A
You
guys
are
familiar
with
which
service
accounts
so
traditionally
they've
been
backed
by
secrets
inside
of
xcd,
but
Mike,
and
a
lot
of
others
have
done
an
enormous
amount
of
effort
towards
more
ephemeral
tokens.
So
the
token
request,
API,
as
well
as
the
token
projection
volumes,
are
the
push
towards
a
a
it's,
both
a
pod
identity
that
can
be
observed
outside
of
the
cluster.
But
in
generally,
there's
a
better
security
practice
to
have
short-lived
ephemeral
tokens
not
stored
in
your
main
data
store
to
be
stolen,
but.
B
C
B
B
However,
due
to
really
old
permissions
and
a
lot
of
legacy
constraints,
nodes
have
been
able
to
delete
themselves,
don't
eat
their
node
object,
which
leaders,
labels
and
tanks
and
recreate
them
recreated
so
I
think
starting
and
110.
We
started
to
phase
out
some
of
this,
or
so
first
we
had
to
make
no
code
paths
in
the
cubelet
delete
the
node
object,
and
then
we
have
to
wait
two
releases
and
we
had
to
remove
this
permission
behind
the
flag,
and
now
we
are
trying
to
figure
out
how
to
constrain
Tencent
labels.
B
A
I
mean
if
we
want
to
add
to
that
like
say
if
you,
if
you,
if
you
configure
your
cluster
today,
to
use
like
the
node
authorizer,
the
node
restriction
plug-in
you
strip
any,
are
back
based
access
from
the
nodes.
You
get
a
pretty
sound
level
of
security.
You
can
make
great
like
if
your
cubelets
can
kind
of
do
anything
at
cuba.
A
So
some
some
of
the
things
that
we
are
trying
to
push
forward,
so
you
can
configure
other
policies
directly
like
a
file
based
approach
on
masters.
Today,
dynamic
audit
effectively
brings
that
up
into
a
rest
style
api
like
a
kubernetes
style
yeah.
What
what
that
gives?
You
is
the
ability
to
say:
okay,
I
have
a
running
cluster.
Something
is
wrong.
I
happen
to
know
within
some
sub
path
that
you
know
these
reese's.
Our
resources
are
involved,
I
want
to
see
what's
going
on
there
right
and
it
just
so
happens
in
distributed
systems.
A
Restarting
your
process
is
a
great
way
to
cause
things
to
work
again.
I
just
happens
to
be
the
domain
that
we're
in
so
having
the
ability
to
tell
the
cube
API
server,
hey
I,
need
you
to
start
logging
this
stuff,
but
don't
like
reboot
yourself
is
extremely
important,
so
we're
working
towards
that
there's
performance
considerations
as
well
as
just
like
higher
level
policy
considerations,
we're
still
looking
through,
not
necessarily
all
of
it
is
required
for
beta
or
GA.
B
D
A
A
B
C
B
There
are
a
lot
of
things
like
the
Calico
node
agent
or
the
no
problem
detector,
which
are
essentially
no
scoped
system
Damons,
and
they
do
need
some
access
to
write
to
the
contenders.
Api,
for
example,
calico
might
need
to
write
to
pod
statuses
for
pods
running
on
the
node,
or
the
no
problem
detector
right
might
need
to
write
to
no
status.
B
So
this
is
actually
a
solved
problem
for
node
identities,
so
the
node
authorizer
and
no
restriction
mission
controller
will
actually
be
constrained
at
cubelet
so
that
it
can
only
write
to
pods
or
pods
or
Peavey's
or
service
accounts
that
are
reachable
in
the
in
the
object
raft
in
the
object
graph.
However,
we
don't
have
a
solution
that
is
general-purpose
that
could
be
extended
to
two
calico
so
that
it
had
the
same
node
scope.
B
We
think
this
is
important,
but
it
actually
that
to
be
a
kind
of
a
hard
problem
to
solve.
Generally
we're
still
brainstorming.
The
camp
that
was
proposed
had
had
some.
There
wasn't
general
consensus,
so
it
was
good.
It
was
going
to
be
a
great
idea,
so
right
now
I
think
we're
recommending
that
where
it
makes
sense
run
those
components
that
adds
I'm
using
the
couplet
I
did
movie
and
then
we're
gonna
try
to
figure
out
a
better.
A
On
to
the
bound
service
account,
so
this
is
sort
of
the
extension
of
the
token
request.
Api
right,
so
you
can
mount
an
ephemeral
service
count
token
into
a
volume
and
the
cubelet
will
keep
rewriting
and
re-refer
etching
that
token
on
disk
for
you.
So
we
know
we
want
to
eventually
move
basically
everything
to
this
approach,
but,
as
you
can
imagine,
that
will
break
a
lot
of
apps
to
just
read
the
token
once
on
startup
and
then
read
it
again.
A
So
we
do
have
a
backwards
compatibility
issue
with
this,
but
our
own
core
components,
ideally
the
cube
controller
manager
or
any
any
piece
of
in
fraternities,
aware,
doesn't
have
that
same
restriction.
So
we've
started
sort
of
so
the
controllers
that
run
on
the
control
plane,
they
all
are
backed
by
service
account
tokens
and
traditionally,
if,
for
example,
you
deleted
those
secrets
that
were
backing
those
service
account
so
again,
so
those
controllers
would
just
stop.
Working
I've
actually
used
this
as
a
feature
before
to
turn
off
controller.
A
So
it's
not
exactly
the
way
to
do
it,
but
the
idea
would
be,
though,
that
these
controllers
have
an
enormous
level
of
access
on
your
control
points.
If
you
look
at
the
cluster
world
aggregation
controller,
it's
just
full
route
all
the
time
it
always
will
be
full
route,
and
it
is
it
is
concerning
when
there
is
a
secret
living
inside
of
that
CD,
that,
if
you
gain
access
to,
you
will
be
routed
on
the
cluster
till
the
end
of
time
by
the
way
we
implemented.
A
This
was
effectively
we
check
to
see
if
your
cluster
is
running
with
the
token
request
API
in
abled.
If
so,
we
will
actually
then
provision
those
controllers
with
the
ephemeral
tokens.
The
future
looking
bid
on
this
is
the
we
would
want.
The
service
account
token
controller,
just
stop
minting
tokens
for
those
service
accounts
altogether
and
instead
those
tokens
those
service
accounts
would
be
purely
ephemeral.
All
of
the
time.
B
We
updated
the
client
libraries
back
to
112
to
do
the
reloading,
there's
a
couple
other
things
that
are
not
gonna
work
with
these
new
tokens.
Specifically,
they
don't
support
this.
The
downward
api
reference
in
environment
variables,
so
the
old
secret
volume
you
could
put
that
secret
into
an
environment
variable
and
the
reason
that
we
stopped
supporting.
That
is
because
it
would
get
logged
in
very
unfortunate
places,
and
we.
C
B
B
A
So
we
have
been
using
sort
of
the
extra
time
on
ours
at
the
end
of
our
Sigma
dings,
to
give
priority
to
various
things
and
just
try
to
make
sure
that
things
that
are
new
and
open
like
get
a
response,
as
well
as
there's
a
lot
of
things
that
are
very
nice
to
have,
but
we
know
that
we
don't
have
cycles
to
get
to
them.
So
you
know
maybe
put
those
in
our
backlog,
whereas
other
things
we're
like
well,
we
really
should
do
this.
It's
sort
of
a
critical
bit
of
security
infrastructure.
A
Certainly,
at
any
level,
if
an
individual
wanted
to
get
involved,
we
would
not.
We
would
not
stop
you
in
any
way.
Like
I
was
the
one
who
had
made
the
like
issue
for
like
hey.
We
should
make
the
controller
manager
use
token
request,
but
I
never
got
to
it,
but
a
contributor
did
and
Mike
and
Jordan
review
this
stuff
and
it
got
merged,
so
it
took
a
while,
but
I
was
happy.
I
had
expected
to
do
it
myself,
but
I
didn't
get
to
it.
So
worked.
B
A
So
here's
all
the
places
you
can
find
us.
Certainly
the
bi-weekly
meetings
of
the
highest
bandwidth,
don't
be
shy.
We
don't
mind
if
you
put
something
in
our
agenda,
we're
very
appreciative.
Yeah
I
know
that
I
I'm
always
kind
of
sad.
If
there's
nothing
on
the
agenda,
all
right
meeting,
canceled,
there's
nobody
here.
A
D
B
A
A
Quick
little
blurb,
so
mike
has
a
talk
later
today
on
some
cool
stuff.
With
the
token
request,
API
honesty,
oh,
you
should
totally
check
it
out.
Matt
and
I
tomorrow
have
the
deep
dive
on
cigars,
where
it's
a
very
sort
of
code.
Heavy
talk,
we're
gonna
be
going
through
how
like
the
odd
step,
sort
of
works
if
you're,
if
you're
interested
in
becoming
a
contributor
to
that
area
of
the
code,
certainly
I'm
hoping
it's
helpful
and
with
that
the
floor
is
yours
guys,
yes,.
D
I'm
very
interested
in
the
bouncer
Versailles
tokens
future
because
we
are
migrating
a
lot
of
workloads
now
to
to
kubernetes
and
in
the
first
case
we
most
of
the
time
we
piggyback
on
the
identity
of
the
service
account
and
that's
why
I'm
interested
in
how
to
turn
it
on
when
it's
like
I
understand
it's
very
like
for
better
quality
right
now
in
snow,
like
maybe
fully
integrated.
But
what's
the
idea?
What's
the
plan
to
move
forward
as.
B
The
actual
volume
and
the
API
will
be
available.
If
you
don't
turn
off,
beta
features,
features
will
be
on
by
default.
There
is
a
separate
feature
which
replaces
the
core
the
volume
that
we
put
in
every
pod,
which
is
currently
alpha
this
that's
one
of
us,
got
to
turn
on
I.
Think
the
name
of
the
feature.
It
is
bound
service,
account
token,
and
then
you
would.
You
would
set
that
as
a
feature
flag
on
the
API
server
and
that
would
that
would
make
the
service
mission
controller,
use
the
new
style
service
volumes
like.
B
B
C
B
D
D
So
I
can
use
it
on
managed
kubernetes
for
a
public
cloud
provider,
well
notes
like
13
or
14,
like
the
low-level
more
or
less
do-it-yourself
thing,
and
for
the
film
key
for
like
the
full
solution
that
is
still
a
couple
of
months
before
I.
Take
like
one
or
twelve
is
now
13
his
recent
Google
or
AWS.
Then
it
will
be,
like
probably
a
few
months,
still
away.
Yeah.
B
B
A
A
related
piece
of
that
is
there's
a
cap
out
for
like
being
able
to
consume
like
the
public
key
of
like,
what's
being
active,
used
to
sign
the
service
account
tokens
which
is
useful
for
some
form
of
you
know
like
external
stores,
right
like
if
you
have
some
external
system
that
wants
to
consume
a
service
account.
So
if
and
it
needs
to
be
able
to
like
be
like,
where
did
like
what
do
I
checked?