►
Description
Two of Pinniped's maintainers, Margo Crawford and Matt Moyer, show you how to install and use Pinniped to link your Kubernetes clusters into common enterprise single sign-on solutions, and how you can provide your cluster users with easy login flows for multi-cluster scenarios.
Matt and Margo also did a deep-dive into the architecture and tricks that Pinniped uses to integrate with Kubernetes. They tell the story of how and why Pinniped was built, describe how they approach security and testing, and talk about how you can contribute to Pinniped.
Link to original CNCF Webinar: https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-easy-secure-kubernetes-authentication-with-pinniped/twitt
A
Good
morning,
good
afternoon,
good
evening,
my
name
is
matt
moyer,
I'm
here
to
talk
to
you
today
about
pinniped,
I'm
here
with
margo
crawford.
We
are
engineers
at
vmware
on
the
pinniped
team
and
today
we're
going
to
talk
about
what
the
problem
is
with
kubernetes
authentication
as
it
stands,
what
we
built
in
pinuped,
how
it
works,
how
you
can
use
it
to
enable
smooth
authentication
on
your
kubernetes
clusters
and
then
go
into
some
time
for
questions,
there's
really
two
gaps
in
the
kubernetes
authentication
user
experience
that
we
set
out
to
solve
with
penpad.
A
The
first
is
that,
even
though
kubernetes
auth
is
very
extensible
and
there's
lots
of
options,
they're
mostly
all
configured
with
cli
flags
on
the
kubernetes
api
server,
and
this
means
that
at
best
you'll
have
to
restart
the
api
server
anytime.
You
want
to
change
one
of
them
and
at
worst
it
means
that
you
won't
even
have
access
to
those
flags,
because
they're
managed
by
your
cloud
provider.
A
The
other
gap
is
that,
even
though
kubernetes
has
all
these
options,
it
sort
of
doesn't
come
with
any
opinionated
login
flow.
It
doesn't
come
with
sort
of
an
end-to-end
way
to
take
an
external
identity
provider
and
provide
a
way
for
users
to
log
into
a
cluster
sort
of
just
gives
you
the
tools
that
you
can
use
to
build,
one
of
those
by
yourself.
So
pinniped
takes
the
options
that
are
existing.
Kubernetes
extends
them
to
have
a
dynamically
reconfigurable
and
end-to-end
out-of-the-box
login
flow.
It's
the
batteries
included
for
your
kubernetes
auth
experience.
A
So
what
is
piniped
piniped
is
an
open
source
project.
We've
been
building
it
for
a
bit
over
a
year.
Now
it
enables
dynamic
configuration
of
kubernetes
authentication.
This
means
that
you
can
install
it
onto
any
existing
running
kubernetes
cluster.
Then
you
can
reconfigure
it
to
add
or
remove
different
authenticators
at
runtime,
and
it
provides
a
better
login
user
experience
for
coop
ctl.
A
So
you
have
a
coupe
config
that
doesn't
have
any
hard-coded
secrets.
You
can
easily
connect
with
openid
and
ldap
identity
providers,
and
you
can
have
an
experience
that
spans
across
multiple
clusters.
So
you
can
have
a
login
once
in
the
morning
to
your
let's
say
your
oidc
identity
provider
and
then
for
the
rest
of
the
day.
You're
you're
logged
in
transparently
to
all
your
kubernetes
clusters,
even
if
you
have
10,
even
if
you
have
100
or
a
thousand
everything
just
works
throughout
your
day.
A
So
pinniped
is
a
vmware
open
source
project,
but
it
works
with
any
kubernetes
cluster.
We
ship
piniped
as
a
core
component
of
some
of
our
commercial
products,
but
it
was
important
for
our
use
cases
that
it
works
with
any
existing
kubernetes
cluster
that
a
customer
has.
So,
even
if
your
cluster
is
running
on
google,
gke,
azure,
aks,
amazon,
eks
or
any
other
commercial
distribution
of
kubernetes
pinniped
should
work
great.
A
A
When
we
built
pinniped,
we
envisioned
a
common
deployment
scenario,
something
like
this.
So
on
the
left,
you
have
an
admin
user
that
installs
and
operates
some
kubernetes
clusters
they
have
access
to
and
what
we
call
an
admin
config
that
they
got
when
they
created
each
cluster.
This
is
typically
a
super
powerful
coup
config
with
some
hard-coded
secret
key
and
it
does
not
identify
any
individual
user.
A
Usually
it
encodes
the
system,
colon
masters
group,
so
that
it
even
bypasses
all
are
back
on
the
cluster.
It's
dangerous
to
keep
this
around,
but
it's
usually
necessary
to
bootstrap
the
rest
of
the
system
and
as
a
failsafe
on
the
right,
you
have
regular
users
that
just
want
to
log
into
the
cluster
and
deploy
applications.
These
might
be
developers,
for
example,
and
in
a
typical
organization.
We
expect
that
even
the
admin
users
don't
use
their
admin
level
access
on
a
daily
basis
just
when
they
need
to
perform
low
level
operations
on
the
cluster
infrastructure.
A
So
in
pinniped
the
admin
user
is
responsible
for
installing
and
configuring
piniped
they
can
set
up
logins
via
their
enterprise
identity
provider
such
as
active
directory
or
something
like
octa,
and
then
they
can
generate
a
coupe
config
for
regular
users
to
use,
and
these
piniped
based
coupe
configs
are
somewhat
special.
They
don't
contain
any
credentials
for
accessing
the
cluster
and
they're,
not
user
specific.
A
Instead,
they
just
describe
how
to
connect
to
the
cluster.
All
users
can
download
and
use
the
exact
same
cubeconfig
file,
but
when
they
log
in
they'll
have
their
correct,
individual,
username
and
groups
from
the
external
identity
provider
and
as
an
admin.
This
means
it's
easy
to
manage
access
to
the
cluster
via
kubernetes
rbac
role,
bindings.
B
Input
has
a
few
different
components
that
can
be
deployed
independent
of
each
other.
First
up
we
have
the
concierge.
This
can
be
deployed
on
any
cluster.
It
takes
an
oidc
token
and
translates
it
into
something
that
the
kubernetes
cluster
can
process
in
one
of
two
ways,
depending
on
your
cluster
architecture,
one
is
creating
an
x
509
certificate
that
is
signed
and
therefore
trusted
by
the
cluster.
The
other
is
forwarding
requests
via
an
impersonation
proxy
on
behalf
of
the
user.
B
Next
up
we
have
the
supervisor,
which
is
typically
deployed
once
on
a
very
trusted
cluster.
It's
an
oidc
server
that
allows
users
to
authenticate
with
an
external
oidc
or
ldap
provider,
and
possibly
other
identity
providers
in
the
future
and
issues
its
own
tokens
based
on
user
information
from
the
idp
that
can
be
used
by
the
kubernetes
clusters.
B
B
B
We
do
pass
a
token
with
user
information
to
each
cluster,
but
we
make
them
unique
tokens
from
each
other
by
changing
the
audience
via
an
rfc
8693
token
exchange.
This
happens
behind
the
scenes
without
the
user
having
to
log
into
each
kubernetes
cluster
independently,
so
users
can
still
log
in
once
per
day
to
access
all
of
their
clusters
while
being
secure.
B
Now
we'll
take
a
look
at
this
architecture,
diagram
for
a
finiped
deployment
in
this
case,
one
where
the
kubernetes
control
plane
is
accessible.
This
is
usually
the
case
for
self-posted
clusters
on
the
user's
first
cube
cuddle
command.
The
pinniped
login
is
triggered
via
the
kubernetes
exact
plugin
and
the
cli
requests
a
federated
login
via
the
supervisor.
B
The
cli
turns
around
and
requests
a
new
second
token
from
the
supervisor,
with
the
same
information,
but
with
a
cluster-specific
audience
which
the
supervisor
mints
and
passes
back
next.
The
cli
will
create
a
credential
request
to
the
pinped
concierge's
aggregated
api.
Using
the
token
that
just
received
the
concierge
uses
the
cluster's
signing
key
from
the
kubernetes
control
plane
to
create
a
short-lived
certificate
for
the
cluster
subsequent
kubernetes
api
requests
will
use
the
short-lived
certificate,
refreshing
it
as
needed.
B
B
The
first
steps
are
the
same
as
before
the
initial
login
happens
to
the
supervisor,
which
means
cluster
specific
tokens
after
login
to
the
external
idp,
the
pinniped
cli
will
still
create
a
credential
request
to
the
pinniped
concierge's
aggregated
api.
However,
the
concierge
will,
instead
of
minting
certs
that
are
using
the
clusters.
Signing
key
issue
certs
using
its
own
keys
that
are
not
automatically
trusted
by
the
cluster
requests,
will
include
this
certificate
and
be
passed
through
the
piniped
concierge
impersonation
proxy,
which
uses
the
cert
to
construct
impersonation
headers.
A
A
B
A
A
A
A
Now
that
the
concierge
is
installed
on
our
cluster,
we
can
configure
it
to
use
an
openid
connect
provider
for
authentication
in
this
demo.
We've
chosen
gitlab
because
it's
free
and
easy
for
anyone
to
get
started
with,
but
you
could
also
use
octa
ping,
identity,
azure,
ad
adfs
or
any
other
oidc
provider.
A
A
A
A
But
we
forgot
to
add
our
back
permissions.
Let's
take
a
look
at
what
username
we
are
actually
authenticating
with.
We
can
do
that
with
another
peniped
subcommand.
Who
am
I,
which
tells
you
everything
about
your
current
identity?
Let's
use
that
with
our
admin,
coop
config.
First,
where
we
can
see
that
our
username
is
kubernetes
admin.
A
A
A
A
If
we
take
a
close
look
at
the
credential
issuer
on
this
new
gke
cluster,
we
can
see
that
the
concierge
is
operating
on
a
different
mode
on
this
cluster
and
isn't
quite
healthy.
Yet,
that's
because
pinniped
only
supports
this
type
of
cluster
via
a
special
impersonation
proxy
mode,
which
takes
a
moment
to
initialize
in
order
to
safely
use
gitlab.
On
this
second
cluster,
I
need
to
create
a
second
oadc
client
in
gitlab.
A
We
set
up
the
second
cluster
completely
independently
from
the
original
kind
cluster.
If
I
clear
my
local
session
cache,
we
can
see
that
when
I
run
coop
ctl
against
the
kind
cluster
I
initially
need
to
log
in
with
my
browser,
and
if
I
run
that
same
command
against
the
gke
cluster,
I
have
to
do
the
browser
login
a
second
time.
You
can
imagine
that
if
I
had
10
or
100
clusters,
all
this
client
setup
and
all
these
browser
logins
might
become
arduous,
which
is
why
we
also
made
the
peniped
supervisor.
A
Now
that
it's
installed,
we
can
see
some
new
pods
running
in
the
penipet
supervisor
namespace,
and
we
can
see
that
there
are
more
new
kubernetes
apis
for
configuring.
The
supervisor
I've
done
a
bit
of
setup
ahead
of
time
and
registered
a
dns
name
demo.peniped.dev,
pointing
at
a
static
ip
address
on
this
cluster.
A
I've
also
pre-provisioned
a
tls
certificate
from
let's
encrypt
which
we'll
use
to
configure
secure
ingress.
I
have
a
load
balancer
service,
that
routes,
inbound
https
traffic
on
our
static
ip
address
to
the
supervisor.
Pod
endpoints
we'll
apply
that
service
object
to
the
cluster
and
wait
for
it
to
be
ready.
A
Now
we
should
expect
that
something
is
listening
on
that
port,
but
we
still
get
a
strange
tls
error
to
configure
the
supervisor
to
listen
on
our
new
host.
We
use
the
federation
domain
custom
resource.
This
tells
the
supervisor
to
act
as
an
oidc
issuer
at
the
given
url
we
set
demo.piniped.dev
and
reference
a
secret
called
demo
tls
that
will
contain
the
tls
certificate
and
private
key
we'll
create
that
secret.
Using
the
let's
encrypt
certificate
I
provisioned
earlier
and
now
we
can
see
that
we
get
an
http,
not
found
error
when
we
crawl.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Instead
we'll
add
an
ldap
identity
provider,
custom
resource
this
resource
describes
how
to
connect
and
authenticate
to
the
directory,
how
to
search
for
users
and
groups
and
how
to
map
their
ldap
attributes
into
kubernetes
user
and
group
names
I'll
apply
that
object
and
we'll
create
the
secret
with
our
ldap
bind
credentials
just
like
other
piniped
apis.
I
can
check
the
status
of
the
new
object
to
see
that
it's
connected
and
ready
I'll
run.
Piniped
get
coop
config
again
to
get
an
ldap
based,
cube
config.
A
A
A
Pinniped
is
a
community
project
if
you're
interested
in
getting
involved
in
the
project,
either
as
a
user,
a
contributor
or
a
future
maintainer,
please
reach
out.
We
hang
out
in
the
pinniped
channel
in
kubernetes
slack,
we
hold
a
public
community
call
twice
a
month
and
we're
on
twitter
at
project.
Peniped,
we'd
love
to
hear
your
use
cases,
your
bug,
reports,
feature
requests
or
any
ideas
you
have
for
the
project
and,
of
course,
you're
always
welcome
to
file
a
github
issue
or
start
a
discussion.
A
Next,
I
want
to
show
you
some
of
the
work
we
have
planned
for
the
project.
Most
of
these
are
early
stages
of
planning.
So
if
you
have
specific
ideas
about
how
you
think
they
should
work
or
particular
features
that
are
important
to
you,
let
us
know
this
is
our
roadmap,
which
you
can
also
find
in
github.
The
first
two
items
are
well
in
progress
and
should
land
by
the
end
of
this
month.
A
The
first
is
support
for
password-based
logins
to
compatible
oidc
identity
providers.
This
is
basically
pass-through
support
for
the
resource
owner
password
credentials
grant
and
it
lets
you,
for
example,
use
oadc
based
service
accounts
for
service
to
service
authentication
such
as
from
a
ccd
system.
If
your
idp
supports
that
flow,
the
next
is
specific
support
for
microsoft.
Active
directory,
an
active
directory
already
works
with
our
generic
ldap
support,
but
we've
taken
a
shot
at
really
streamlining
the
experience,
because
ad
has
a
lot
of
consistent
defaults.
A
We
can
give
our
apis
much
better
defaults
and
we
can
handle
some
of
the
ad
specific
edge
cases
better
than
in
the
generic
ldap
case.
The
next
item
on
our
list
is
support
for
multiple
idps
in
the
supervisor.
Currently,
you're
only
allowed
to
have
exactly
one
identity
provider
configured,
which
is
somewhat
limiting.
A
This
is
a
bit
of
a
table,
sticks
feature,
but
I'm
really
happy
with
how
we've
designed
it
to
fit
into
our
apis.
Next
up
we've
got
wider
concierge
cluster
support.
Our
goal
has
always
been
to
support
any
kubernetes
cluster,
but
today
we
fall
a
bit
short
of
that.
We're
planning
to
write
some
new
concierge
back-end
strategies
so
that
we
can
support
openshift
clusters
and
we're
planning
to
add
a
new
strategy
that
uses
the
short-lived
certificate
support.
That
was
just
added
in
kubernetes
122
and
that
should
be
a
nice
portable
option
for
modern
clusters
moving
forward.
A
Next
up,
we
have
what
we've
been
calling
identity
transforms,
which
is
probably
the
feature
on
the
list
that
I'm
most
excited
about.
Currently,
when
you
connect
to
an
oidc
or
ldap
identity
provider,
we,
basically
just
let
you
choose,
which
attribute
from
the
idp
maps
to
the
kubernetes
username
and
which
attribute
maps
to
the
group
names
we'll
still
support
that
mode,
but
we're
planning
to
give
you
a
ton
of
new
customization
options
by
embedding
a
small
scripting
engine
called
starlark
into
the
supervisor.
A
Next,
we
have
extended
idp
support.
We
already
support
any
oidc
or
ldap
provider,
but
there
are
a
couple
of
popular
providers
that
either
don't
work
because
they're
not
oidc
or
don't
work
perfectly
because
they
use
non-standard
features
of
oadc
and
two
examples
here
are
github
and
google
github
is
not
an
odc
provider,
but
it
has
a
similar
oauth
based
authentication
protocol
and
google
works
today,
but
they
have
a
custom
groups,
api
and
some
tricky
edge
cases
related
to
their
hosted
domain
claim.
A
As
you
can
see,
there
are
a
bunch
more
items
after
that
we
try
to
stay
flexible
and
agile
and
how
we
prioritize
features.
So
once
again,
if
you
have
thoughts
about
anything
you
see
here
or
you
think
we're
missing
something
that
would
make
pennipet
a
perfect
fit
for
your
use
case.
Let
us
know,
thank
you
all
so
much
for
attending.
I
also
want
to
thank
my
teammate
margo
for
co-presenting
and
thanks
to
the
rest
of
the
team,
for
helping
build
this
awesome
tool.