►
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
Deep Dive: Auth SIG - Tim Allclair & Jordan Liggitt, 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 discuss designs for a couple of the features currently in development.
To learn more: https://sched.co/Grez
A
Welcome
to
the
sig
off
deep
dive
session,
my
name
is
Tim
all
Claire
I'm,
one
of
the
co-chairs
of
sig
off,
and
we
thought
you
might
all
be
a
little
tired
of
hearing
about
solutions
and
new
features
that
are
going
to
solve
all
your
problems.
So
we
thought
we'd
just
offer
you
some
problems
without
solutions,
and
so
the
first
one
of
these
I
want
to
talk
about
is
add-on,
auth,
authentication
and
authorization
there's
a
lot
of
different
features
that
are
going
to
be
run
on
the
cluster
to
add
functionality
to
the
cluster.
A
Similarly,
device
plugins
and
device
metrics
also
have
node
level
plugins
CRI
streaming
server
and
then
there's
a
bunch
of
cluster
level
add-ons
as
well,
and
so
the
cluster
level
add-ons
is
mostly
solved.
So,
for
instance,
you
have
a
controller
running
somewhere
in
the
cluster
to
talk
to
the
API
server.
It's
going
to
authenticate
the
server
with
the
cluster
CA
that
gets
auto
mounted
with
the
alongside
the
service
account
token.
The
client
authentication
is
done
through
service
accounts
and
authorization.
A
Typically
done
through
our
back,
but
any
other
authorizer
would
work
as
well
once
once
the
controller
needs
to
talk
to
node
level,
daemon
set
components
gets
a
little
more
complicated.
We
don't
currently
have
a
solution
for
the
controller
to
validate
that.
It's
talking
to
the
right,
daemon
set
pod.
One
solution,
we've
kind
of
discussed,
is
having
an
auto
approval
flow
along
with
per
pod.
A
A
This
would
require
a
custom,
TLS
validation,
flow
and
so
kind
of
custom,
client
code,
but
again
would
work
for
the
controller
one
other
thing
to
mention
here
is
this
is
sort
of
a
problem
that
is
solved
by
the
service
meshes,
but
because
these
are
add-ons
that
we
expect
to
run
in
most
or
maybe
all
in
some
cases,
deployment
our
kubernetes
clusters.
We
can't
depend
on
service
masters
to
solve
this.
For
us,
client
authentication
in
this
case
is
basically
solved
through
service
account
tokens
and
token.
A
A
This
the
authentication
here
is
mostly
solved
again
using
the
cluster
CA
to
validate
the
server
service
counts,
with
per
pod
identity
for
the
daemons
set
pods
and
then
for
the
authorization
piece
we've
discussed,
maybe
using
the
Noda
authorizer
and
extending
that
to
apply
to
daemon
sets
by
checking
where
that
pot
is
running
again,
sort
of
an
open,
open
question.
How
to
do
this
then?
A
Finally,
for
the
daemon
sets
to
talk
to
the
controller
we
so
again,
we
have
this
kind
of
auto
approval
flow
for
certs
potentially,
but
here
we
probably
don't
want
a
perp
odd
certificate.
We
would
want
a
service
certificate
so
trying
to
figure
out
some
way
of
Auto,
approving
that
with
the
service
account
identity,
client
authentication
is
mostly
solved
with
per
pod
identity
and
a
token
review,
and
then
an
authorization.
If
we
did
the
the
node
authorized
are
applied
to
the
demon
sets,
then
it
would
also
work
with
subject
access.
A
A
So
the
next
problem
we
wanted
to
talk
to
you
about
is
pod
admission
in
policy.
We
have
a
bunch
of
built
in
policy
controllers.
In
kubernetes
we
have
pod
security
policy,
Network
policy,
image
policy,
a
bunch
of
others.
They
all
work
kind
of
slightly
differently,
especially
when,
in
the
way
that
we
bind
the
policy
to
the
decide
whether
this
policy
should
be
applied
to
this
request.
So
for
pod
security
policy,
we
check
it
against
the
the
creating
in
kind
of
the
naive
approach
is
to
say:
does
this
user
have
permission
to
do
this
request?
A
The
problem
is
users
typically
don't
create
pods
that
create
deployments
or
replica
sets,
and
so
to
get
around
that
we
also
check
whether
the
pods
service
account
about
is
authorized
to
use.
That
policy,
which
is
sort
of
counterintuitive
network
policy,
is
namespaced
and
then
a
pod
selector
determines
which
pods
it
is
applied
to
image
policy
is
delegated
entirely
to
a
web
hook,
and
the
review
request
itself
includes
the
image,
annotations
and
namespace.
A
So
it's
kind
of
up
to
the
the
web
hook
to
decide
which
what
to
do
with
that
limit,
ranger
and
resource
quota
are
basically
namespaced
Singleton's,
but
kubernetes
doesn't
really
support
singleton
resources.
So
this
is
kind
of
strange
and
toleration
and
nude
selector
are
also
namespace
Singleton's.
But
this
time
just
attached
to
the
namespace
object.
A
So
there's
kind
of
a
few
patterns
that
fall
out
of
here.
The
first
is
just
apply
policy
at
the
namespace
level.
This
is
my
favorite,
it's
consistent
with
authorization,
because
when
you
create
an
object,
the
permission
is
checked
against
the
namespace.
Like
do
you
have
create
permission
in
the
namespace,
but
it
can't
really
be
applied
more
granularly,
although
I
think
we
should
also
include
label
selectors
personally.
A
The
second
one
is
basically
the
the
pod
security
policy
approach,
which
we
already
talked
about.
It's
it's
counterintuitive,
it's
not
really
any
more
secure
than
just
applying
it
at
the
namespace
level,
because
unless
you
have
a
second
policy
mechanism
to
limit
service
accounts,
then
you're
just
still
checking
permission
at
the
namespace
level
and
pod
security
policy.
I'll
mention
also
because
it
conflates
this
with
also
checking
the
user.
It
actually
ends
up
with
weaker
security,
so,
for
instance,
if
you
want
to
run
a
privileged
pod
that
needs
to
create
other
pods
and
other
namespaces.
A
That
means
that
any
pod
that
privileged
pod
creates
is
also
going
to
be
able
to
be
privileged.
Potentially,
since
you
have
to
have
a
privileged
pod
security
policy
to
run
that
privilege
pod
in
the
first
place,
and
then
the
last
approach
is
sort
of
the
one
that
kind
of
seems
the
most
natural
at
first,
it's
does.
The
user
have
permission
to
to
create
this
object
and
so
check
the
policy
on
the
creation
of
the
replica
set
or
the
job
or
deployment
by
looking
at
the
pod
template.
A
But
as
soon
as
you
start
to
think
about
how
this
would
actually
be
implemented,
it
gets
really
quite
complicated.
So
the
first
question
is:
how
do
you
handle
the
delegation
to
the
controllers
that
actually
create
the
pods,
and
even
if
you
come
up
with
some
system
of
looking
at
the
the
pod
template
and
comparing
it
to
the
actual
pod
that
starts
to
break
down
once
you
get
into
CR,
DS
and
third-party
controllers?
A
A
So
as
soon
as
you
add
mutation
into
the
policy,
so,
for
instance,
defaulting
what
happens
if
two
policies
are
trying
to
set
two
different
default
values
which
one
do
you
select?
Also,
if
you're
mixing,
allow
and
deny
policies
than
the
ordering
matters
it
doesn't
matter.
If
you
just
have
static,
non
mutating
deny
only
policies,
because
you
can
just
check
any
of
them
in
any
order
and
if
any
of
them
deny
similar
for,
if
they're
all
allow.
So
this
is
how
our
back
works
and
and
the
authorizers.
A
Another
kind
of
area
of
inconsistency
is:
do
we
do
domain-specific
policies
like
scheduling,
policy
or
image
policy
versus
resource
specific?
We
don't
really
have
any
resource
specifics
policies,
but
it
has
been
pitched
as
like
what
if
we
just
had
one
pod
restriction
policy
that
applied
to
every
field
on
the
pod
and
just
anything
you
want
to
limit
on
the
pod,
you
can
do
other
other
areas
we
discussed.
We're
default,
allow
versus
default,
deny.
So
what
happens?
If
you
don't
actually
have
any
policy
objects
created
default?
A
A
A
A
The
the
the
risk
of
default,
allow
is
suppose
you
have
a
policy
that
is
preventing
some
sort
of
dangerous
operation,
and
maybe
you
missed.
Maybe
you
had
a
namespace
selector
on
it.
That
said,
apply
to
all
these
pods
and
and
you
missed
a
namespace
right
and
so
now
that
namespace
didn't
have
any
policy
applied
to
it
and
suddenly
you
have
you
have
the
whole
or
maybe
you
delete
a
policy
thinking
that
it's
not
used
and
realized
that
oh
wait.
B
B
These
lists
of
problems
are
not
just
intended
to
paralyze
us
and
never
let
us
move
forward,
but
we
do
want
to
kind
of
think
deeply
about
the
implications
of
these
things
before
we
set
a
direction
and
make
sure
that
the
incremental
things
we
do
don't
shoot
us
in
the
foot
long
term.
So
I'm
going
to
talk
about
how
API
servers
authenticate
to
web
hooks.
So,
as
extension
mechanisms
have
been
added,
it's
kind
of
a
web
hook
all
the
things
approach.
So
initially
we
had
admission
web
hooks
in
the
current
release.
B
We
have
the
ability
to
have
conversion
web
hooks
for
custom
resources
and
audit
web
hooks
for
sending
audit
events
out
to
external
sources,
and
so
you
can
have
this
model
where
the
API
server
is
sending
data
out
to
some
web
hook
and
then,
in
some
cases
like
in
mutating
admission,
getting
data
back
or
in
conversion
getting
data
back
from
the
web
hook.
So
you
might
be
asking
why?
Why
does
the
API
server
need
to
authenticate
to
a
web
hook?
B
And
so
there
are
a
few
reasons
web
hooks
that
accept
data
need
to
know
that
the
data
they're
being
given
is
trustworthy.
So
if
an
audit
web
hook
is
gonna,
be
logging
like
Jordan
Liggett,
tried
to
access
this
secret
I
really
want
to
only
get
that
audit
event
log.
If
I
actually
tried
to
do
that,
I
don't
want
someone
to
be
able
to
spoof
that
and
like
trigger
responses,
also
Admission
web
books
that
take
external
actions,
something
that
might
be
recording
quota
or
recording
things
in
an
external
system.
B
You
don't
want
to
be
able
to
trigger
that,
except
if
that
action
actually
happened,
and
then,
on
the
flip
side
web
hooks
that
return
data
like
a
mutating
web
hook.
We
only
want
to
return
data
to
the
systems
that
should
have
access
to
it.
So
if
I
create
a
deployment
and
one
of
the
things
that
gets
injected
is
like
a
sidecar
container
with
some
information
based
on
an
external
system,
we
don't
want
to
give
that
information
back
to
just
anyone
and
then,
finally,
just
from
an
availability
perspective,
we
only
want
to
do
expensive
work.
B
If
the
person
asking
us
to
do
it
is
the
right
person.
So
the
simple
approach
is
to
just
add
in
credentials
or
a
credential
reference
into
the
web
book
config.
So
when
you
say,
I
want
to
call
out
to
this
web
book
also
like
point
to
this
secret
and
have
the
API
server
like
read
a
credential
from
the
secret
and
attach
it
to
the
web
book
request,
and
that
can
work
in
some
cases,
but
it
makes
a
couple
of
assumptions.
The
first
problem
with
that
approach
is
that
you
can't
distinguish
between
API
servers.
B
So
if
you
have
multiple
API
servers
and
all
of
them
are
making
articles
or
web
book
calls
and
they're
just
reading
this
shared
credential,
you
don't
have
the
ability
to
distinguish
between
them
and
then
the
second
problem
is
that
the
queue
API
server
is
not
the
only
one
making
calls
to
these
web
books.
So
if
you
have
other
aggregated
add-on
servers,
you
can't
assume
that
they
should
all
have
access
to
this.
This
shared
credential.
B
So
if
you
kind
of
look
at
the
the
problem
space
you
have
on
one
dimension,
you
have
whether
uniform
identity
is
okay
or
whether
you
want
per
caller
identity.
So
there
are
cases
where
you're
going
to
want
to
want
uniform
ID
in
it.
If
you're
calling
out
to
an
external
service-
and
it's
maybe
just
a
crash
logger
and
all
you
have-
is
an
API
key
and
you
don't
care.
You
want
all
your
servers
to
call
out
to
this
crash
logger
with
the
same
key.
B
Maybe
that's
fine
for
you,
but
we
need
to
preserve
the
ability
to
have
per
caller
identity
and
in
the
other
dimension
you
have
kind
of
how
aware
of
kubernetes?
Is
this
web
book?
If
it's
an
external
crash
logger,
it
might
not
know
anything
about
kubernetes
and
it
just
wants
a
particular
particular
credential.
But
on
the
other
hand,
you
might
have
a
web
book
that
was
built
to
interoperate
with
the
kubernetes
ecosystem,
and
so
it's
aware
of,
like
kubernetes
tokens
and
can
do
token
reviewed
type
type
requests.
B
So
if
uniform
identity
is
acceptable,
then
maybe
the
shared
credential
reference
could
work
and
so
we're
considering
having
that
as
an
option,
not
the
only
option
but
an
option
for
the
various
web
hook.
Configurations
that
you
could
say
when
you
call
this.
What
book
use
this
credential
and
if
uniform
identity
is
acceptable,
that
that
could
be
a
possibility?
That's
something
we're
considering.
B
If
you're
calling
out
to
kubernetes
aware
web
hooks,
then
the
work
that
we're
doing
now
to
have
these
service
account
tokens
that
can
be
generated,
on-demand
and
made
very
audience
specific
could
be
a
solution
so
having
an
option
on
the
web
hook.
Configurations
to
say,
when
you
call
me
do
so
with
a
service
account
token
scoped
to
this
web
hook
and
then
all
those
various
API
servers
could
request
that
token,
as
they
were,
building
requests
to
each
web
hook.
B
That's
a
possibility
as
well,
and
then
this
is
where
we're
kind
of
scratching
ahead
right
now
this
is
the
the
fourth
quadrant
and
maybe
important.
Maybe
not.
We
could
probably
do
work
to
make
the
first
ones
better
and
possibly
defer
working
on
this.
Fourth,
but
that
is
the
that's
the
problem
and
kind
of
the
ways
we're
thinking
about
it
and
the
use
cases
we're
trying
to
preserve
so
Mike
next.
C
I'm
gonna
do
a
quick
summary
of
the
current
state
of
the
certificates
API,
so
the
certificates
API
has
been
around
since
I
believe
a
1/4
was
introduced
as
alpha
beta
by
1/6.
That
was
almost
two
years
ago
at
this
point
and
it
still
hasn't
made
it
to
GA.
So
we
have
some
fundamental
issues
with
the
API
we're
debating
whether
they
need
to
be
addressed
before
we
bring
the
the
API
to
GA.
C
We
know
a
lot
of
lot
of
users
would
like
to
see
this
API
become
a
ga
API
and
where
it
hasn't
had
an
advocate
to
see
it
through
the
process.
So
to
highlight
some
of
the
issues
we
have
some
structural
changes
that
we
would
like
to
make
to
the
API.
If
you're
familiar
with
the
flow
which
was
covered
yesterday
and
workload
identity,
talk
that
I
gave
the
approver
is
is
responsible
for
approving
certificates.
C
D
C
C
Revocation
is
somewhat
independent
of
the
certificates
API
just
like
certificate
rotation,
its
client-side
behavior,
and
it's
not
part
of
the
certificates
API.
We
have
no
plans,
although
there
have
been
proposals
to
support,
revocation
I,
think
in
general
for
cluster
scoped
certificates
coming
out
of
the
cluster
root
CA,
it's
best
to
implement
automation
and
very
fast
rotation,
even
like
crl,
based,
revocation
those
those.
If
you
have
a
CR
L,
that's
valid
for
a
day.
C
Why
not
just
issue
a
certificate
for
a
day
and
and
avoid
the
problem
of
revocation
which,
which
is
actually
fairly
complex
and
is
not
perfect
in
itself.
However,
if
somebody
wants
to
come
and
implement
revocation-
and
it
makes
a
lot
of
sense
and
solves
these
cases-
we'd
be
happy
to
we'd,
be
happy
to
e
to
hear
it
out
and
help
Shepherd
that
through.
But
it
is
not
in
scope
for
the
certificates
API
to
GGA.
D
C
So
it's
a
balance
between
availability
and
security
here
so
an
hour
you're,
taking
a
pretty
hard
dependency
on
the
API
being
up.
Usually
you
can
solve
an
outage
of
the
API
server
within
a
day.
A
bad
situation
would
be
if
your
workloads
began
to
authenticate
because
of
some
extended
API
outage
if
CR
ELLs
are
usually
signed
for
24
hours,
if
you
sign
certificates
for
24
hours,
I
think
that's,
that's!
Okay,
pretty
good
thanks
it
up
yeah!
So.
B
E
C
C
It
depends
on
how
you
want
to
use
name
constraints.
I
think.
The
answer
to
that
question
depends
a
lot
on
what
what
you're
trying
to
do.
Spiffy
has
has
some
concept
of
name
constraints
and
also
signing
policy,
so
you
can
actually
do
a
pretty
expressive
delegation
that
isn't
even
a
lot
in
teal
aspect.
So
if
you
have
advanced
to
use
cases,
I
would
actually
recommend
that
you
look
at
that.
Spec
I.
B
Not
a
PKI
flow,
so
the
PKI
aspects
of
Kerberos
wouldn't
apply
as
much
it's
more
of
a
an
audience
bound
token.
So,
at
the
point
where
the
the
caller
was
going
to
make
a
call
to
a
web
hook,
it
would
go
obtain
token
bound
to
that
audience.
So
it
is
affordable,
credential,
but
because
it's
bound
to
the
audience
it's
providing
it
to
that's,
not
particularly
concerning
so
that
I
mean.
Maybe
it's
philosophically
similar
to
Kerberos,
like
you
get
a
per
hour
per
call.
Does.
B
B
F
B
The
currently
the
entity
requesting
the
certificate
has
to
know
everything
about
the
certificate
they
want,
so
the
primary
use
was
for
node
bootstrapping,
and
so
it
said,
I
want
a
client
certificate
for
this.
This
subject
in
cases
where
it's
like
a
pod
that
needs
to
serve
a
secure
server.
It
knows
that
it
wants
a
surfing
cert
and
it
knows
its
own
pod
name,
but
it
doesn't
necessarily
know
like
all
the
services
that
route
to
it
and
all
of
the
subject:
alternative
names
and
UIDs
and
various
things.
B
F
C
Credentials
for
cubelets
and
I
would
like
to
have
very
constrained
profiles
and
that
our
use
case
motivated
rather
than
have
a
very
generic
API,
where
you
can
have
certificates
of
all
shapes
flowing
out
of
this
API,
so
I
think
it's
more
around
creating
structured
profiles
of
what
are
produced
and
then
having
very
good
logging
of
what
actually
makes
it
out
of
that
certificate.
Api.
G
C
C
Yes,
so
I
think
that
the
general
philosophy
that
I've
had
is
that
we
want
to
enable
very
feature
full
authentication
systems
to
run
on
top
of
kubernetes.
So
whatever
we
can
do
to
secure
our
core
infrastructure
and
allow
people
to
build
integrations
is
is
where
we
draw
the
line
and
if,
if
somebody
wants
a
fully
featured
system
like
spire
or
is
do
we
want
to
make,
we
want
to
enable
that
use
case
on
top
of
kubernetes,
but
we
don't
want
to
be
in
the
business
of
implementing
like
credential
policy.
G
C
G
C
C
A
C
H
C
E
I
You
go
just
around
scalability,
so,
like
openshift
runs
some
of
the
largest
cube
clusters
in
existence
and
probably
our
biggest
pain
point.
Is
we
store
so
many
service
accounts
and
all
their
secrets.
So
we
might
gain
some
issues
from
having
a
token
request,
ephemeral,
tokens
everywhere,
but
I
guarantee
you
will
save
so
much
space
in
etsy
D.
Your
life
will
be
so
much
better.