►
From YouTube: Intro: Auth SIG - Jordan Liggitt & Tim Allclair, 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 - Jordan Liggitt & Tim Allclair, Google
SIG Auth is responsible for the design, implementation, and maintenance of features in Kubernetes that control and protect access to the API and other core components. In this session, we'll give an overview of the work the SIG is doing, improvements and features added over the past year, and some of the plans for upcoming releases.
To Learn More: https://sched.co/Grd0
A
So,
looking
forward
to
the
next
year,
we
have
the
building
blocks
in
place,
for
these
improved
service
account
tokens
and
it
is
alpha
and
113.
So
if
you
want
to
go
start
using
bit,
you
can,
and
we
would
appreciate
it
if
you
would
and
give
us
feedback
we're
looking
for
ways
to
roll
that
out
and
have
it
enabled
by
default.
So
there
are
a
few
pieces
to
that.
A
One
is
kind
of
looking
at
how
clients,
across
the
ecosystem,
used
and
consumed
token
credentials
from
inside
pods
and
helping
them
start
to
be
capable
of
handling
rotated
credentials
so
that
they
don't
just
assume.
I
can
read
this
when
my
process
starts
up,
and
this
will
be
good
until
eternity
client
go
is
already
updated
to
do
this.
We're
gonna
be
working
with
a
lot
of
the
other
clients
as
well.
To
get
that
happening.
There's
an
opt-in
switch
currently
to
make
what
admission
injects
automatically
be
these
better
tokens.
A
A
Compatibility,
but
we
also
push
people
to
better
defaults
as
they
continue
along
with
their
configuration.
We
started
the
dynamic
audit
work
last
release,
and
that
was
alpha
and
so
we'll
be
progressing
that
right
now.
It's
all
dynamic
audit
webhooks
get
the
same
events,
and
so
we're
looking
for
ways
to
let
them
specify
particular
events.
They
would
like
to
see
and
then
also
working
through
some
of
the
ways
that
we
configure
API
servers
to
authenticate
to
the
web,
hooks
that
they
call
that
doesn't
just
apply
to
dynamic
audit.
A
C
C
C
So
if
you
for
your
organization,
for
instance,
want
to
enable
some
really
kind
of
very
specific
to
your
organization
policy
like
you
can
only
be
a
privileged
pod.
If
you're
using
this
image
between
the
hours
of
9:00
and
5:00,
then
you
might
not
necessarily
want
to
write
your
own
admission
webhook
to
implement
that
policy,
and
so
the
goal
of
these
policy
engines
is
to
be
able
to
express
that
in
a
sort
of
generic
way
through
something
like
OPA.
The
open
policy
agent
and
Rigo
is
the
language
that
they
use.
C
We're
also
talking
about
new
domain
specific
policies.
So
when
for
common
use
cases
you
might
not
want
to
have
to
deal
with
writing
detailed
configuration
through
rego
or
another
mechanism,
and
so
we're
talking
about
other
other
domain
specific
areas
such
as
scheduling,
which
has
been
in
review
for
a
long
time.
We
hope
to
kind
of
push
that,
through
in
2019,
we've
had
conversations
about
image
policies
so
restricting
kind
of
what
registries
or
what
repositories
and
and
what
images
you
can
use.
C
And
then
there's
a
lot
of
issues
with
pod
security
policy
and
I
get
a
lot
of
questions
about
when
it's
going
to
GA
I
I
I'm,
not
promising
that
pod
security
policy
will
go
to
GA.
But
this
isn't
important.
It's
an
important
area
and
so
we'll
be
thinking
about
kind
of
what
the
path
forward
for
that
is.
And
how
do
we
provide
a
solution
around
that
and
then
on?
C
We
kind
of
already
talked
about
the
node
authorisation
and
restriction
plugins,
but
so
far
that
effort
has
focused
on
the
cubelet
identity
and
the
node
identity
and
restricting
what
that
identity
is
capable
of,
but
there's
other
workloads
that
run
on
every
node
and
have
some
privileges
to
the
API
server
that
an
attacker
could.
Potentially
you
know
the
attacker
gets
access
to
every
credential
on
the
node
if
they've
compromised
the
node,
and
so
we
need
to
think
about
how
we
can
apply
similar
restrictions
to
those
workloads
as
well
Hey.
C
So
if
this
all
sounds
really
cool
to
you
and
you
want
to
get
involved
in
sig
off,
we
have
a
few
suggestions
up
here,
but
first
I
want
to
just
give
a
disclaimer,
which
is
the
projects
that
we
handle
in
sig.
I
have
some
really
complex
nuances,
because
we're
dealing
with
security
issues
that
have
potentially
very
serious
implications,
and
so,
if
you're,
working
on,
if
you're
working
on
a
say,
goth
project
expect
maybe
a
little
more
resistance
through
the
review
process.
C
A
C
C
C
Of
start
life
as
a
prototype
or
a
plugin
oftentimes,
it's
it's
enough
to
just
exist
as
a
plugin
and
and
we'll
see
more
and
more
projects
that
you
know
might
even
become
standard
standard
features
that
you
expect
on
every
kubernetes
cluster,
but
are
still
run
as
a
plugin,
dynamic
admission,
webhook,
an
authorization
or
a
authentication
web
hook
or
expect
ones.
Dynamic
audit
goes
to
GA
that
will
even
start
seeing
some
cool
things
like
audit
portals
and
whatnot,
and
lastly,
I
wanted
to
call
out
that
quality
is
a
top
priority
for
2019.
C
You
may
have
heard
this
in
other
sessions,
and
so
a
really
great
way
to
get
started.
Submitting
code
and
learning
more
about
current
parts
of
sig
off
is
to
work
on
expanding
our
test
coverage.
If
you,
if
there's
some
feature
that
you're,
you
want
to
learn
more
about,
go
and
look
at
the
end-to-end
test
and
see
examples
of
how
to
use
it.
If
you
find
that
there
isn't
an
end-to-end
test
or
there
isn't
an
example
of
what
you
want
to
see,
then
think
about
adding
that
and
then
similarly
with
documentation.
C
So
even
if
you're
not
an
actual,
if
you're,
not
an
official,
sig,
auth,
reviewer
or
approver,
you
can
still
take
a
first
pass
on
PRS
and
that's
actually
a
great
way
to
become
a
reviewer.
If
we
see
that
you're
doing
a
good
job
with
the
reviews
that
you've
done,
then
we
would
like
to
promote
you
and
then
also
I
mentioned
earlier,
that
we
want
to
do
a
better
job
of
triaging
issues
and
so
always
looking
for
help
there
as
well.
C
E
So
a
lot
of
the
cig
off
stuff
has
been
working
great
for
us
on
our
internal
cluster
and
we've
started
looking
at
some
of
them
managed
kubernetes
offerings
out
there
and
finding
that
they're
all
tightly
integrated
with
the
I
am
offering
of
the
cloud
provider.
So
one
thing
I'm
interested
in
knowing
is
this
something
sick
off
can
influence,
or
is
anybody
aware
of
this
direction
where
we
could
get
our
own
like
kind
of
bring
your
own
authentication
provider
to
a
managed
kubernetes
offering
in
the
cloud.
F
A
Authentication
is
one
of
those
areas
where
every
cluster
is
a
special
snowflake.
Every
everybody
has
their
authentication
solution.
If
you
are
running
on
premise,
you've
got
existing
systems.
You
need
to
tie
into
cloud
providers,
managed
providers
have
systems
that
they
are
going
to
hook
into
I
I
doubt
that
sig
auth
will
probably
push
very
hard
to
make
extensible
authentication,
like
part
of
conformance
like
a
requirement
for
a
conformant
cluster
I,
think
that
would
always
be
the
domain
of
the
person
running
the
cluster.
A
So
if
that
is
something
you
care
about,
I
would
probably
start
talking
to
the
providers
that
you
are
experiencing
that
with
and
asking
them
do
you
intend
to
allow
hooking
and
authentication
that
is.
That
is
my
view
of
the
landscape
and
my
expectation.
I,
don't
speak
for
providers
or
these
guys
necessarily,
but
I
am
skeptical.
That
providers
that
are
responsible
for
maintaining
SL
O's
on
clusters
are
going
to
want
to
sort
of
allow
identity,
something
as
fundamental
as
identity
to
be
interfered
with
or
like
changed
in
ways
that
are
unpredictable
to
them.
A
G
It
was
not
too
long
ago
we
had
someone
come
to
our
bi-weekly
meeting
and
I
think
they
had
a
similar
issue
and
they
basically
worked
around
it
by
having
a
authenticating
proxy
that
ran
as
cluster
admin
and
and
just
impersonated,
whatever
user
wanted
to
impersonate,
so
they
controlled
the
tokens
that
came
into
their
proxy
and
as
far
as
the
cluster
was
concerned,
that
user
was
that
user.
Obviously
auditing
tracks
it
as
the
authenticating
proxy
is
impersonating
this
user.
G
That
is
a
way
around
it,
because
you
can
build
any
identity
solution
at
that
point
because
you
have
controlled
the
proxy
in
a
slightly
different
vein,
like
even
with
OpenShift,
into
managed
instances
like
on
Azure,
the
only
configuration
for
the
IDP
is
the
OID
see
as
your
integration,
because
I
think
our
expectation
is
that's
what
you
want
I,
don't
think
you
want
to
have
like
random
other
configurations
on
them
as
your
instance,
if
you're
on
a
sure.
So
that's
kind
of
that.
H
H
Yes,
so
if
you
are
running
inside
a
cluster,
we
hope
that
there's
some
consistency
in
the
way
that
you
authenticate
to
the
kubernetes
control
plane
right
now.
There
is
some
conformance
testing
for
for
how
that
works.
Where
so
it
it
should
be
consistent
on
providers
that
say
that
they
are
running
kubernetes.
That's
one
area
where
we
do
have
a
little
bit
more
controlled.
I
So
I
had
a
couple
of
questions.
One
is
kind
of
related
to
just
what
he
just
said
regarding
conformance
like,
for
example,
if
I
want
to
verify
something
works
as
a
you
know,
as
a
privilege,
pod
and
I
I
want
components
to
work
in
both
ways
like
running
is
probably
like,
if
I'm
having
a
new
ad
and
running
a
new
ad
Mission
Control,
that
it
works
in
privilege,
mode
and
non
privilege
mode
and
I
find
that
the
compromises
is
kind
of
like
I'd.
Accept
that
non-privileged
more
some
set
of
tests
will
fail.
A
Yeah,
so
the
there's
actually
work
underway
more
as
part
of
SiC,
architectures
and
say
goth,
but
to
first
of
all
make
sure
all
the
things
that
we
are
actually
counting
on
are
covered
by
conformance
tests.
There
are
a
lot
of
there's
a
lot
of
functionality
that
has
tests,
but
is
not
yet
part
of
the
conformance
suite,
and
there
are
several
dimensions
to
conformance
you
mentioned
one
which
is
privileged
versus
unprivileged
or
less
privileged.
There
are
other
dimensions
like
what
operating
system
are
you
running
on
other
dimensions
like?
A
A
The
the
way
they've
been
designed,
the
the
token
is
valid
for
until
it
expires
or
the
pod,
it
is
bound
to
gets
deleted
at
a
percentage
of
that
time.
The
token
gets
rotated
and
a
new
one
gets
injected,
but
the
old
token
is
still
valid.
So
there's
an
overlap
of
I
think
it's
a
percentage
of
the
lifetime
where
the
old
token
is
still
valid,
but
the
new
token
is
available
for
the
process
to
pick
up.
Okay.
A
Doing
that
you
know
so,
the
the
token
rotation
doesn't
require
evicting
the
pod.
The
tokens
can
update
live
inside
a
running
pod.
So
if
the
process
is
capable
of
observing
that
change
and
picking
up
the
new
token,
then
it
doesn't
have
to
restart
it
can
keep
using
the
new
token
that
was
part
of
what
we
were
talking
about
with
updating
the
client
libraries
that
pick
up
in
cluster
config
to
do
to
handle
that
observation
and
rotation
for
you.
A
So
if
you're,
using
the
the
client
libraries
provided
by
the
kubernetes
project,
you'll
get
that
behavior
for
free,
if
you're
using
your
own,
then
you
need
to
observe
token
changes
and
that's
part
of
what
we're
working
through
how
to
do
that.
Compatibly!
Try
to
figure
out
if
we
need
people
to
opt
in
to
that
or
indicate
that
their
pod
is
capable
of
that
or
how
we're
going
to
roll
that
out.
H
If
you
want
to
force
a
rotation
which
we
won't
do
automatically
so
say,
you
have
tokens
that
are
valid
for
an
hour.
They
rotate
every
30
minutes
or
so,
if
you
want,
for
whatever
reason
that
hours
too
long
for
you,
you
can
go
ahead
and
do
a
rolling
update,
a
replica
set
and
that
will
invalidate
all
tokens
provision
to
old
pods
that
have
since
been
deleted.
A
So
there
there
are
two
two
ways
you
can
do:
federated
authentication.
You
can
put
an
authentication
proxy
which
terminates
authentication
and
then
just
conveys
information
to
the
backend
through
headers
with
mutual
TLS.
That's
one
way
the
other
way.
If
you
in
some
environments,
you
don't
have
the
ability
to
actually
get
em
TLS
credentials
to
be
an
authenticating
proxy,
so
the
impersonation
mechanism
works
as
well.
So
if
you
make
a
normal
API
call,
but
then
add
impersonation
headers,
the
first
step
is
the
API
server
will
will
do
is
once
it
figures
out.
B
A
A
good
question
just
general
security
knowledge,
I
guess
it
depends
on
what
area
you're
interested
in.
So,
if
you're,
looking
at
like
some
of
the
authentication
areas,
then
familiarity
with
whatever
that
is
whether
it's
you
know,
x.509
client
certificates
or
open
IT
connect
or
whatever
the
particular
area
is,
would
be
helpful
if
I
think
Tim's
suggestion
about
getting
familiar
with
the
code,
that's
there
and
either
helping
fix
it.
Where
it's
unclear
or
not
not
well
tested,
not
well
documented,
would
be.
H
A
C
Just
to
add
something
to
the
first
question
also
I
think
a
lot
of
security
having
some
security
knowledge
before
working
on,
say
goth
will
help
you
to
identify
kind
of
the
big
projects
and
areas
that
we
need
to
focus
on
and
sort
of
set
priorities
and
goals
and
whatnot.
But
you
don't
necessarily
need
to
do
that.
You
don't
need
to
do
that
to
get
started,
and
so
a
lot
of
that
work
has
already
been
done
by
people
who
are
experienced
in
the
project
and
so
I
think
there.
G
Well,
Tim
does
that
I
was
just
gonna
mention
that
so
I
probably
spent
a
year
before
I
became
particularly
useful
in
the
openshift,
which
is
you
know,
just
cube
with
more
stuff.
On
top,
so
don't
extend
if
it
takes
some
time,
like
I
spent,
probably
two
years
before,
that
working
in
IT
security,
and
it
still
just
it's
just
a
lot
of
code,
but
yes,
devons
talk
was
quite
excellent.
I
did
enjoy
that.
G
F
We're
using
webhook
for
validating
burrito
cans,
so
essentially,
we've
built
an
external
session
management
that
we
use
to
log
into
communities
we're
using
cash,
that's
built
into
web,
who
called
a
directive
to
look
for
performance,
but
we
would
like
to
log
out
from
our
destroyed
a
session
at
some
point
and
then
we
would
like
to
be
able
to
tell
curious
and
the
web
hook
about
it.
It's
decision
is
done,
like
click
clear,
the
cache.
H
So
probably
the
fastest
thing
for
you
to
do
if
you
need
this
feature,
is
to
implement
a
some
sort
of
local
web
hook.
Caching,
that
is
able
to
do
invalidation,
I
think
caching,
by
default
in
the
web
hook,
Authenticator
is
somewhere
around
10
seconds
or
something.
So
if
you
do
a
revocation
five
minutes.
H
A
In
general,
things
that
increase
the
API
surface
are
a
lot
slower
and
harder
to
to
get
in
for
good
reason.
Every
API
surface
we
support,
we
have
to
support
basically
forever,
and
so
something
that's
specific
I
would
I
would
be
surprised
if
an
API
for
token
cache
management.
It
happened
in
the
UVI
server
itself,
hi.
My.
D
Question
is
around
service
accounts.
We,
as
a
company,
are
trying
to
onboard
some
of
our
applications
on
to
Cuba
net
is
cluster
I
work
for
t-mobile
and
we've
been
working
on.
We
have
large
amount
of
clusters
on
the
Cloud,
Foundry
stack
and
Cuban.
It
is
is
something
that
we
just
started
off
and
we
are
trying
to
onboard
some
of
the
applications
on
that,
and
but
this
question
keeps
coming
from
the
security
folks.
What
do
you
do
with
the
service
accounts?
Like
you
know?
How
do
they
work
and
how
do
you
ensure
security?
H
H
Yeah,
it's
gonna
be
difficult
to
phase
in
because
there
are
some
incompatible
changes
such
as
more
lockdown
file,
permissions,
the
rotation,
so
that's
actually
incompatible
for
older
clients,
they're
no
longer
able
to
be
projected
into
environment
variables,
which
was
a
behavior
for
secrets
that
we,
we
are
just
continuing
so
there's
various
hiccups
that
prevent
us
from
doing
this
implemented
are
enabling
this
broadly
and
so
we're
working
through
those
kinks.
But
if
you
are
concerned
about
security,
I
highly
recommend
that
you
you
turn
those
on
as
soon
as
possible.
A
So
the
question
was:
how
does
an
external
workload
like
an
external
CI
system
or
something
consume
this
token?
The
the
tokens
have
the
ability
to
be
time,
limited
audience
limited
and
then
bound
to
specific
API
objects,
so
the
ones
that
are
mounted
into
pods
are
bound
to
that
pod.
You,
the
token
request.
Api,
has
the
ability
to
generate
these
bound
only
to
a
service
account,
so
you
can
still
generate
ones
for
use
elsewhere
and
it
would
be
bound
to
an
object,
an
API
object
like
the
service
account
or
or
a
particular
secret.
A
So
you
can
still
generate
them
and
take
them
outside
the
cluster.
You
have
the
ability
to
request
very
long-lived
time,
bound
ones,
subject
to
what
your
cluster
administrator
said
was
their
maximum
supported
token
lifetime.
So
the
cluster
admin
can
say:
I'm
not
gonna,
mint
tokens
longer
than
a
day
or
a
week
or
a
month,
and
you
can
say:
I
want
one
ballot
for
a
thousand
years
and
they'll
say
I'm.
Sorry,
here's
one
for
a
day
and
so
we're
trying
to
we're
trying
to
give
cluster
admins
the
tools
they
need.