►
From YouTube: Deep Dive: Auth SIG - Mo Khan & Matt Rogers, Red Hat
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 - Mo Khan & Matt Rogers, Red Hat
We present a thorough walkthrough of the Kubernetes authentication and authorization codebase, where we will cover interface contracts and give specific examples of how they are implemented in Kubernetes. The audience will also be given a high level overview of the request processing pipeline. The generic nature of these interfaces will be explored along with a look into areas where Kubernetes has a strong opinion on the implementation specifics such as service accounts and the node authorizer. As a case study, the OpenShift auth stack will be discussed. OpenShift’s use of OAuth for authentication and role based access control for authorization will lead into discussions around token delegation, auditing, access controlled resource lists, etc.
https://sched.co/MXvp
A
A
A
Okay,
to
start
with
an
outline
we
are
going
to
cover
the
request
flow,
the
request
handler
registration,
the
the
request
context,
request
metadata.
All
of
the
items
in
the
request
flow
we're
going
to
go
over
the
authentication
piece,
we're
going
to
look
at
some
of
the
Authenticator
types,
we're
also
going
to
cover
the
Authenticator
Union
semantics,
how
the
authenticators
interact
with
each
other
and
the
same
thing
for
the
authorization
of
peace.
A
So
this
diagram
shows
the
flow
that
an
incoming
request
goes
through.
The
HTTP
request
starts
off
by
being
converted
into
request
info
metadata
and
it's
passed
to
the
authentication
layer,
the
authentication
layer,
authenticates
the
request
and
passes
it
to
the
audit
layer
where
there
might
be
a
log
generated
somewhere
about
the
request.
A
After
the
audit
layer
comes
the
impersonation
layer,
this
layer
we're
not
going
to
cover
this
in
detail,
but
this
layer
checks
if
there
was
the
desire
to
perform
an
action
as
some
user.
If
so,
then,
there's
some
check
to
see
if
the
requester
has
permission
to
act
as
the
user
and
assuming
that
that
checks
out
the
request
is
modified,
so
that
the
action
is
performed
as
the
requested
user.
A
So
the
authentication
authorization
framework
is
implemented
as
a
series
of
HTTP
server
handlers.
So
if
you're
familiar
with
go,
you've
most
likely
come
across
this
code
or
written
some
variant
of
it,
you
define
your
handler
function.
That
might
that
might
do
something
with
the
request
and
write
to
the
response,
and
then
you
register
the
hand
the
handler
to
handle
under
a
specific
path
on
the
server,
and
then
you,
you
start
your
server.
A
So
since
the
request
has
to
go
through
multiple
layers,
as
you
saw
from
the
earlier
slide,
processing
is
implemented
as
a
series
of
wrapped
HTTP
handlers,
the
registration
function,
which
the
signature.
Here
you
takes
an
existing
Handler
and
here's
some
configurable
data
item
that
defines
the
behavior
of
the
handler,
and
then
it
wraps
that
existing
Handler
and
returns
a
new
handler.
A
So
this
slide
shows
some
example
code
to
display
the
ordering
of
these
wrapped
handlers
during
registration.
The
handler
that
implements
your
business
logic
is
wrap
is
wrapped
first
with
an
authorization
Handler
here
and
then
an
authentication
handler
right
there,
so
the
last
handler
to
be
registered
acts
on
the
request
first.
So
in
this
example,
we
have
an
authentication.
We
have
authentication
that
will
act
on
the
request
first
and
then
the
next
in
line
would
be
authorization.
So
it's
it's
a
basically
a
stack.
A
The
request
comes
up
dude
that
way,
so
these
wrapped
handlers
are
distinct
and
they
don't
communicate
with
each
other
directly
only
through
the
past
in
requests.
So
during
the
request
flow,
each
layer
communicates
with
the
next.
By
modifying
the
request
context
object
at
each
layer
with
context
is
called
to
include
the
data
specific
for
that
layer.
The
flow
of
information
here
is
just
one
way
down
the
chain
delay:
they
don't
ever
communicate
back
up
to
the
previous
layer.
A
A
So
here's
the
context
implementation
returned
by
with
value
we're
calling
value,
follows
the
parent
context
in
order
to
find
the
value
under
the
key.
This
highlights
something
about
the
key
that
we
use
here.
If
the
key
is
not
guaranteed
to
be
unique
across
all
contexts,
then
you
could
potentially
have
a
collision
and
return
the
wrong
data.
So
as
you
and
as
you
might
have
noticed
that
this
context,
I
mean
this
chain
is
effectively
a
linked
list.
A
So
we
don't
care
about
the
key
itself.
We
just
want
to
make
it
unique
across
the
entire
program.
So
how
we
do
that
and
go
normally,
is
the
you
define
a
private
type
alias
to
int
and
making
a
constant
of
that
alias
is
guaranteed
to
be
unique,
as
that's
a
private
type
for
your
package.
So
even
if
a
type
with
the
same
name
is
declared
in
a
different
package,
they
won't
compare
as
equal
as
you
saw
before.
A
A
A
So
this
slide
shows
an
expanded
example
of
the
context.
After
moving
through
the
request
flow,
as
you
can
see,
there
are
nested
context
with
key
value
data
and
added
at
each
layer
at
the
deepest
nesting.
We
have
the
request
info
data,
which
we'll
look
at
look
at
that
a
little
closer
after
that
is
the
user
info
data.
Here,
that's
added
by
the
authentication
layer
and
finally,
at
the
at
the
highest
level
of
nesting.
We
have
the
audit
data
added
by
the
audit
layer.
A
A
It
contains
a
minimal
amount
of
request,
information
that
the
author,
that
a
later
handler
can
base
and
access
decision
on,
and
it
could
feasibly
cache
this
as
opposed
to
doing
something
like
caching,
though
the
entire
HTTP
request,
which,
even
though
it
might
be
a
request
for
the
same
path
and
everything
the
body
would
be
different
and
that
wouldn't
work
for
for
caching-
and
you
can
expect
later
handlers
to
always
like
reach
out
to
to
something
or
fetch
any
other
data
about
the
request.
So
it
prepares
this
for
the
whole
stack.
A
So
if
you
look
at
the
default,
build
handler
chain
function
in
the
API
server
package,
there's
a
lot
of
coal.
A
lot
of
code
here
hold
on
you
can
see
how
the
standard
handler
chain
is
set
up,
where
the
handlers
are
registered
in
an
order
where
the
last
to
be
registered
are
the
first
to
touch
the
request.
So
you
can
see
that
with
request
info
down
here,
and
it
goes
up
authenticates.
The
second
step,
authentication,
audit,
impersonation
and
authorization.
A
A
Otherwise,
we're
wrapping
the
input
handler
with
a
hand
with
another
handler
function
that
first
tries
to
authenticate
the
request
here.
If
there's
an
unsuccessful
authentication,
then
the
handler
returns.
Otherwise,
the
user
is
added
to
the
existing
context,
and
the
request
with
the
new
context,
is
passed
on
to
the
next
handler
in
the
chain.
A
So
here
we're
starting
to
look
at
the
authenticator
interfaces,
so
this
is
the
request
interface.
As
you
can
see,
it
has
an
authenticate
request,
method
that
takes
an
HTTP
request.
It
returns
the
response,
object,
a
boolean
if
you're
authenticated
or
not,
and
an
error
for
there
being
a
hard
failure
now
to
give
a
an
example
of
the
behavior
of
the
bull
in
the
error
returned
together.
A
A
A
Yet
UID
returns
a
unique
value
for
a
particular
user
that
will
change
if
the
user
is
removed
from
the
system
and
another
user
is
added
with
the
same
name.
There's
also
the
groups
that
the
user
is
a
member
of
and
an
extra
map
that
contains
information
that
the
Authenticator
thought
was
interesting
and
one
example
of
that
is
scopes.
On
a
token
now,
a
note
about
the
name
versus
the
UID,
so
cube
is
generally
named
based
in
in
this
area.
So
the
use
of
the
UID
is
not
particularly
common.
A
So
here's
the
x.509
request
Authenticator
here
the
certificate
is
verified
using
a
CA
that
the
Authenticator
is
configured
with
and
then
the
user
information
is
extracted
from
the
certificate
subject
and
returned.
So
if
you
look
at
the
verify
options
struct
in
the
corner,
this
is
configuration
for
the
verify
for
the
verifier,
where
you
can
configure
the
see
a
pool
and
any
acceptable
key
usage
for
the
certificate.
A
So
there's
also
a
header
Authenticator
that
gathers
the
user
information
from
specific
request
headers
and
that's
all
it
does
and
use
the
loan.
It's
completely
insecure
configuring,
this
name
headers
group
headers,
it
could
be
an
it
could
be
like
cube
underscore
or
whatever,
whatever
you
defined
here.
It'll
just
grab
that
information
from
the
header
and
stick
it
into
the
user
info.
A
So
this
is
the
other
variant
of
the
x.509
request
Authenticator.
So
this
one,
instead
of
just
verifying
and
just
returning
the
user
conversion
results,
it
verifies
the
certificate
and
then
checks
the
common
name
against
a
configured
set
of
allowed
common
names.
So
if
the
name
checks
out,
then
it
continues
on
to
call
the
wrapped
request.
Header
Authenticator,
that
we
showed
in
the
previous
slide,
since
this
Authenticator
provides
the
right
certificate,
authentication
and
then
cause
the
header
authenticate
Authenticator
right
afterwards,
then
it
makes
the
use
of
the
header
Authenticator
secure.
A
Here's
the
OID
C
Authenticator,
it's
a
common
one
to
configure,
since
you
might
use
it
with
many
other
providers,
such
as
Google
and
get
lab.
Some
of
the
configuration
for
IDC
includes
the
server
audiences
which
will
be
compared
against
audiences
in
the
request,
if
configured
an
issuer
URL
to
verify
against
the
issue
or
claim.
In
the
token,
and
if
these
preliminary
checks
succeed,
we
verify
and
then
start
to
extract
claims.
A
From
the
token
the
claim
names
are
also
configure
configurable,
so
you
can
think
of
that
at
that
part
of
it
as
similar
to
the
simple
header
Authenticator
that
we
showed
earlier,
and
this
slide
shows
the
Authenticator
which
is
used
to
authenticate
service
account
tokens.
The
token
is
parsed
claims
are
claims,
an
audience
is
our
process
and
then
the
token
is
validated
and
the
user
info
is
returned.
A
So
we've
talked
about
different
kinds
of
token
authenticators
already,
so,
if
you
think
about
what
authenticating
a
token
might
entail,
it
could
involve
some
expensive,
lookup,
remote
lookup
or
an
encryption
operation
in
this
case
being
able
to
wrap
the
token
auth
with
a
customizable.
Caching.
Authenticator
allows
for,
like
a
short-lived
token,
cache
for
optimization.
A
So
here's
the
Union
Authenticator
handler,
so
this
Authenticator
is
configured
with
a
slice
of
authenticators
and
a
fail
on-air
option.
So
all
authenticators
are
tried
in
a
successful
authentication
from
any
of
them
returns
an
okay
response.
If
fail,
an
error
is
set
to
false,
then
a
fatal
error
from
one
Authenticator
can
be
over.
I
did
buy
a
successful
return
from
a
later
Authenticator.
So
if
fail
and
error
is
true,
then
an
error
from
any
Authenticator
in
the
slice,
short-circuits
the
rest
of
the
authenticators
and
returns
the
air.
A
So
this
is
the
authenticate
request
version
of
the
Union
and
there's
also
an
authenticate
token
varying
it.
The
parts
that
are
highlighted
in
blue
is
literally
the
only
thing
that
changes
in
the
code
between
requests
and
token
unions
right
and
I'm
going
to
pass
it
off
the
mode
to
wrap
it
up
with
the
full
example.
Ok,.
B
So
here
we
have
like
a
visual
representation
of
what
we
sort
of
talked
so
far.
So
I'll
walk
you
guys
through
it,
so
I
walk
from
the
outside
or
the
inside
out.
First,
so
pretend
you
have
a
service
account
token
Authenticator
here
right
and
we
also
want
to
honor
Oh
a
DC
tokens,
so
we're
gonna
Union
those
two
things
together
right.
So
now
we
have
a
singular
token
Authenticator
and
these
two
things
can
be
expensive.
B
You
may
have
some
lookups,
you
do
in
verification,
so
we
go
ahead
and
wrap
it
with,
and
at
that
point
you
still
can't
honor
requests,
because
this
is
a
token
Authenticator.
Another
request
Authenticator.
So
we
need
to
wrap
it
with
a
glue
code
that
gives
us-
and
perhaps
you
also
wanna,
honor,
nine
search
as
was
covered
earlier,
and
they
kind
of
look
at
the
order
of
these
things.
B
X1I
x.509
is
a
super
cheap
check,
you're
just
looking
at
metadata
on
the
request,
so
we
put
that
one
first
and
similarly,
service
accounts
are
super
common
right,
they're
part
of
the
core
infrastructure,
whereas
why
do
you
see?
Is
users
interacting
with
the
system?
Generally
speaking
right?
So
we
put
that
one
first,
we
want
it
to
be
tried
first
and
all
of
this
gets
Union
together.
So
like,
let's
walk
a
request
coming
in
right,
so
someone
tries
to
authenticate-
and
this
is
a
request
that
does
not
have
a
client
cert
on
it.
B
It
just
has
a
very
quick
time.
So
it's
gonna
go
through
here.
It's
gonna
hit
the
x509
certifcate
ER,
which
will
say
there's
nothing
here
for
me,
so
they'll
keep
going
down.
Well,
let's
pretend
that
these
unions
are
both
don't
fail
on
any
errors.
It's
going
to
pass
things
through.
The
bear
took
an
Authenticator
will
strip
out
the
bearer
token
for
us
pass
it
down.
The
cache
is
empty
and
keep
passing
it
down.
We'll
hit
the
Union.
If
it,
the
service,
account
authenticator.
Let's
say
this
was
a
user.
B
C
B
B
So,
as
a
actual
example
from
the
codebase
for
how
we
wire
these
things,
look
together,
so
this
is
the
delegating
hot
code,
so
things
like
the
cubelet
inside
should
lie
on
this
any
sort
of
external
component
that
wants
to
delegate
it's
off
to
the
QA.
Tester
can
use
this
type
of
code.
So
now
you
guys
said
we
might
use
this,
so
we
have
the
best.
I
dropped
indicator
first,
client.
Sir
token,
all
of
this
is
getting
Union
together
at
the
end.
B
B
And
then
all
of
those
authenticators
get
Union
together.
If
you're
authenticated,
you
need
to
have
the
system
for
authenticated
group
added
to
you
automatically,
so
we
have
just
a
little
wrapper
that
does
that
and
then
that
final
Authenticator
is
what
seems
so,
if
you
remember
back
earlier,
the
widow's
education
bit
takes
a.
B
Well,
let's
walk
through
this,
so
it's
gonna
get
some
kind
of
authorization
attributes
from
the
complex
we'll
see
in
the
next
slide.
What
that
looks
like,
then,
the
authorizer
is
going
to
attempt
an
authorization
and
decisions
based
on
those
attributes,
and
here
we
see
sort
of
the
most
distinct
difference
between
authentication
authorization.
Thank
you.
Instead
of
having
a
boolean
state,
we
actually
have
a
tri-state
of
allowed
in
I.
In
my
opinion,
this
allows
an
authorizer
to
say
that
I
explicitly
know
that
this
is
a
denied.
B
B
B
A
A
B
It
looks
at
the
user
on
the
request,
check,
cert
groups
and
sees
if
that
group
intersects
with
a
configured
set
of
groups
and
think
does
it
says,
listen
aloud.
So
we
generally
refer
this
to
this
as
the
system
for
masters
magic
authorizes,
it's
effectively
the
way
of
saying
that,
if
you're
a
user
with
this
group,
you
can
do
anything.
B
Authorizer
in
the
sense
that
it
delegates
the
cube
api
server
to
do
some
authorization
decision
so
with
the
external
component
asking
the
qubit
castle,
so
we
have
an
API
call
subject:
access
review
that
helps
us
sort
of
do
this.
Let
me
walk
through
this
there's
a
conversion
from
these
attributes
and
to
subject
access.
It's
really
straightforward,
because
subject
access
review
is
basically,
can
some
user
perform
some
action,
which
is
exactly
what
attributes
has
within
it
right?
B
B
B
B
B
B
B
B
B
B
B
A
B
B
B
B
A
B
B
B
B
The
mistake
I
made
when
I
wrote-
this
was
I
was
thinking
in
my
mind.
Well,
this
user
can
do
anything
so
I
should
give
them
the
script.
I
don't
have
to
check
anything
else,
except
what
happened
is
when
they
would
get
a
scope
token
scopes
would
never
get
a
chance
to
deny
would
always
just
approve
and.
B
B
E
B
C
E
B
E
B
C
A
B
E
B
B
E
C
So
one
other
thing
I've
been
looking
for
so
one
particular
problem
solved.
Actually
by
implementing
some.
These
interfaces
is
authentication
with
firebase
kind
of
a
weird
use
case.
There
I
wasn't
able
to
use
OID
C,
even
though
it's
an
OID
c2
token,
because
they
don't
have
to
discover
URLs
is
initially
I
was
looking
to
find
webhook,
implementations
or
like
scaffolding,
but
really
couldn't
find
it
other
than
inside
existing
API
server.
Is
there
a
plan
with
the
cig
to
maybe
provide
a
framework.
A
C
C
C
B
It's
like
you
should
have
you
had
the
public
keys
somewhere
right
that
somebody
has
that
great,
so
you're
not
minting
the
token
with
yourself
right.
You
just
want
to
educate
them,
so
I
mean
so.
There
are
plans
in
general,
like
if
you've
been
following
the
new
token
request,
API
for
service
accounts.
If
we
want
those
identities
to
be
able
to
assert
it
outside
of
the
cluster,
like
inside
of
like
your
cloud
provider
and.
B
On
making
it
so
that
the
cube
API
server,
it's
so
exerts
metadata
about
tokens.
But
on
to
your
specific
question
that,
like
it's
very
like
I,
would
expect
they're
like
you,
should
be
able
to
technically
postal
on
URL
to
pass
to
our
o
IDC
educator
attended
a
verification
because,
as
long
as
the
issuer,
URL
is
correct
and
all
the
public
key
business
practice
should
be
able
otherwise
I'm
trying
to
think
about.