►
From YouTube: Uniform Workload Identity Everywhere: SPIRE Integrations and Extensibility - Ryan Turner, Uber
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Uniform Workload Identity Everywhere: SPIRE Integrations and Extensibility - Ryan Turner, Uber
Distributing strong identity securely throughout a production environment often requires integrations with a number of platforms. Learn how SPIRE can be adapted to support production workload identity in heterogeneous infrastructure across a variety of software systems. This talk will cover some examples of different kinds of systems where SPIRE can provide identity and what deep integrations exist in SPIRE today. We’ll also dive into the plugin-based architecture used throughout SPIRE that provides open extensibility points to support the needs of your organization’s bespoke infrastructure and tooling.
https://sched.co/f3j7
A
A
A
So
what
are
we
going
to
talk
about
today?
First,
I'd
like
to
just
give
a
brief
overview
of
what
spiffy
and
spire
are
for
those
who
are
not
too
familiar,
and
just
kind
of
talk
about
some
of
the
terminology
that
we'll
be
using
throughout
the
talk.
Then
I'm
going
to
go
into
some
of
the
integrations.
That's
fire
provides
and
some
of
the
external
systems
that
spire
can
integrate
with.
A
A
Then
the
second
part
of
the
specification
it
defines
an
identity
document
standard.
So
how
does
this
identity
get
represented?
And
this
is
what
we
refer
to
as
an
svid,
so
that
stands
for
spiffy,
verifiable
identity
document,
and
that
comes
in
two
different
forms.
One
is
an
x509
certificate
and
another
is
a
json
web
token
and
then
the
third
part
of
the
spiffy
specification
is
this
workload
api,
which
talks
about
how
to
retrieve
and
issue
s-vids
throughout
an
environment.
A
A
A
So
it's
essentially
a
certificate
authority
which
provisions
these
identities
and
two
different
agents
that
run
throughout
an
environment.
So
this
agent
component
is
the
second
component
of
spire,
which
talks
to
the
server
and
requests
different
identities
that
it
can
manage
on
the
host.
And
so
how
does
the
user's
workloads
come
into
the
picture
here?
A
So
I
just
want
to
show
like
a
big
picture
here,
there's
a
lot
going
on.
It's
the
details
are
not
super
important
here,
but
I
just
want
to
kind
of
hammer
home
that
spire
can
really
be
versatile
and
work
in
a
variety
of
environments
here.
So
I'm
just
showing
like
one
example.
Maybe
you
have
deployments
in
different
private
and
public
clouds.
A
So
here
I
have
pictured
an
aws
deployment
where
you
have
kubernetes
cluster
with
some
nodes
running
different
workloads
and
those
workloads
are
docker
based
workloads
and
so
in
that
environment
spire
can
function.
It
has
a
spire
server
deployed
in
the
kubernetes
cluster
and
then
there
are
agents
which
are
deployed
on
all
the
nodes
in
that
cluster
and
the
workloads
connect
to
those
agents
on
those
nodes.
A
You
may
just
have
bare
metal
hosts
running
in
a
data
center,
and
so
how
do
you
manage
spire
there?
Well,
spire
can
also
work
there.
You
can
have
different
hosts
running
spire
server,
and
then
you
can
have
agents
running
on
the
hosts
in
your
infrastructure
and
again
you
can
support
a
variety
of
these
workloads.
So
it's
very
adaptable.
A
So
I
want
to
talk
about
what
are
the
different
types
of
integrations
available
with
spire.
So
really
we
can
categorize
these
into
two
different
buckets.
One
is
integrations
that
enable
the
operations
of
spire,
so
this
is
controlling
some
of
the
key
functionality
and
behavior
of
spire
and
some
of
the
security
properties
as
well
to
meet
the
compliance
requirements
that
you
may
have,
or
your
own
internal
requirements
and
then
so,
really,
that's
all
about
getting
spire
up
and
running.
A
That's
just
how
do
I
manage
spire
and
make
it
work
in
my
infrastructure
in
the
secure
way
that
you
know
I'm
comfortable
with
the
second
part
here
is:
how
do
you
actually
consume
spire
issued
identities
in
a
way?
That's
seamless,
so,
ideally,
not
every
workload
needs
to
implement
their
own
integration
with
spire,
just
to
get
their
identity
and
get
bootstrapped.
A
Maybe
that
works
in
a
small
environment
where
you
just
have
you
know
very
few
number
of
services
or
applications,
and
you
can
make
those
code
changes
and
all
the
services
to
get
identity,
but,
as
you
scale
further
up
and
you
have
more
and
more
services
in
your
environment
that
becomes
very
difficult
to
manage,
and
so
how
do
we
actually
propagate
these
s?
Vids
across
remote
procedure
called
boundaries
and
provide
secure,
authentication
across
our
service
requests,
and
then
how
do
you
use
svids
outside
of
your
own
ecosystem,
for
requests
to
external
services?
A
So
one
is
that
you
may
have
in
your
organization
already
some
public
key
infrastructure
likely
you
do
and
that
might
be
a
public
web
pki
chained
to
some
well-known
trusted
ca
on
the
internet,
or
it
might
be
a
private
pki.
So
you
may
have
your
own
root
ca
in
your
infrastructure
or
your
organization,
and
you
have
processes
around
how
it's
managed,
and
maybe
you
want
to
manage
all
of
your
workload
identities
in
your
environment,
such
that
they're
all
chained,
to
this
pki.
A
Another
integration
point
we
have
to
consider
here
is
we
have
this
distributed
system
architecture
where
there
are
agents
running
across
different
hosts,
vms
virtual
nodes
throughout
infrastructure?
So
how
do
we
securely
identify
those
agents
and
the
nodes
that
they're
running
on,
so
that
we
can
trust
those
agents
with
the
identities
that
spire
server
will
distribute.
A
A
Another
key
integration
here
is
how
you
manage
your
identity
registrations,
so
this
is
something
that
we
call
host
categorization,
so
this
enables
creating
identity
registrations
that
we
call
node,
alias
registrations
and
essentially
what
these
node
alias
registrations
are
for
are
to
give
you
logical
groupings
of
registrations
per
host
or
maybe
for
a
group
of
hosts,
so
that
identities
are
not
globally
available
throughout
your
entire
infrastructure.
You
may
scope
those
identities
to
certain
nodes
running
in
your
environment,.
A
A
So
we
call
this
workload,
attestation
inspire,
and
so
this
is
all
about
clearing
runtime
attributes
of
a
workload
to
identify
it
against
a
set
of
registrations
already
inspired
and
then.
Lastly,
there
are
some
event
hooks,
so
you
may
have
some
downstream
processes
or
downstream
storage
that
you
may
want
to
link
different
key
events,
inspire
to
some
workflows
or
you
know,
storage,
and
so
this
is
kind
of
providing
you
these
hooks,
so
that
you
can
plug
into
the
event
life
cycle
of
different
things
that
happen.
Inspire.
A
So
that's
what
enables
both
the
in-memory
and
external
plug-ins
and
these
plugins
are
all
designed
on
top
of
this
framework
called
apache,
corp,
goblet
plugin,
and
that's
a
pretty
commonly
used
plugin
system
available
in
go
and
is
used
widely
in
hashicorp
and
by
other
projects
in
the
open
source
community.
So
I
have
a
link
to
the
reference
for
that
project
later
on
in
the
slides,
if
you're
interested
in
looking
into
that
more
so
I
want
to
kind
of
just
touch
on
what
are
the
different
plug-in
types
for
each
of
these
components.
A
We
talked
about
inspire
the
server
and
the
agent,
so
this
is
just
kind
of
intended
to
be
an
illustration.
I'm
going
to
dive
into
all
these
different
plug-in
types
more
detail
here.
Coming
up.
This
diagram
is
slightly
outdated
in
that
the
plug-in
on
the
left
there,
the
data
store,
plug-in,
doesn't
exist
anymore,
so
you
can
kind
of
ignore
that
part,
and
there
should
also
be
a
notifier
plug-in
in
here
as
well.
A
But
overall,
these
are
the
plugins
that
are
available
today
in
the
server
there's
the
key
manager
and
upstream
authority,
which
is
kind
of
how
you
link
to
your
pki
and
I'll
talk
about
that
later.
And
then
these
node
plugins
called
nodatester
node
resolver,
which
are
used
to
authenticate
nodes
in
your
environment
and
also
label
them
with
different
key
metadata.
A
And
then
the
agent
has
its
own
set
of
plugins
available
as
well,
and
these
are
the
three
that
are
supported
today.
The
noda
tester,
which
pairs
with
server
node
tester
plug-in
the
workload
tester
plugin,
which
identifies
workloads
that
connect
to
the
workload
api
in
the
host
and
then
the
key
manager,
which
also
manages
the
private
keys
and
signing
operations
in
agent.
A
A
A
It
also
allows
spire
to
publish
gwt
signing
keys
that
it
has
generated,
or
you
know,
and
publish
those
to
some
third-party
store.
It
also
can
handle
the
certificate
signing
requests
for
this
buyer
ca.
So
if
you
want
to
avoid
or
off
avoid
that
signing
operation
happening
in
the
spire
server
process
itself-
or
you
want
to
offload
that
to
some
other
system,
you
can
do
that.
These
are
the
available
built-in
plugins.
A
A
So.
This
defines
the
bridge
of
trust
between
your
host
identity
system
and
spire.
So
this
is
how
you
authenticate
nodes
in
your
system
and
so
that
these
are
the
different
plugins
which
are
supported
right
now
we
have
native
plugins
for
aws
azure
and
gcp
virtual
machines,
and
these
generally
all
work
by
querying
a
local
metadata
endpoint
in
the
virtual
machine
and
using
a
trustline
first
use
security
model
to
provide
that
identity
metadata
to
aspire
server
and
spire
server
can
authenticate
that
and
I'll
show
you
an
example
flow
of
that
after
this
slide.
A
Some
of
the
other
plugins
that
are
supported
today
are
join
token.
This
is
essentially
a
one-time
pre-shared
key
that
you
can
generate
and
you
provide
that
key
to
the
agent
and
then
the
server
knows
about
it,
because
it
was
the
one
that
generated
the
key,
and
so
that's
just
a
simple
way
to
authenticate
a
node
there's
also
native
integration
with
kubernetes
there's
a
couple
different
ways:
this
can
work.
One
is
through
a
projected
service
account
token,
which
is
kind
of
the
recommended
way.
There's
also
kind
of
a
more
legacy
plug-in
for
service
count.
A
Tokens
such
as
the
older
wave,
providing
a
node
identity
in
kubernetes,
and
then
we
also
have
ssh
and
x509
proof
of
possession
plug-ins
as
well.
So
if
you
are
running
on
bare
metal-
and
you
have
some
other
host
identity
system
like
an
ssh
certificate
authority
and
or
maybe
some
out
of
band
x,
509
host
identity,
then
you
can
use
those
as
out-of-station
material
as
well.
A
A
A
A
So
here's
kind
of
like
an
example
of
how
you
might
do
that.
So
let
if
you
look
at
the
top
registration
here,
this
is
a
node,
alias
registration,
and
you
see
that
spiffy
id
is
for
my
domain.
Slash
host
a
so.
This
is
we're
calling
this
host
a
in
her
infrastructure
and
the
selectors
here
are
appended
by
the
node
resolver,
which
I've,
let's
say,
I've
created
some
node
resolver.
In
this
example,
it's
called
my
fancy
node
resolver,
and
so
it
depends
this
selector,
which
says
hey.
I
know
something
about
this
host.
A
So
some.
What
are
some
example
authorities
that
we
trust
inspire,
might
be
an
operating
system
kernel
like
the
linux
kernel.
It
might
be
some
sort
of
orchestration
platform,
and
so
here
are
the
examples
of
the
plugins
that
we
support.
Today
we
support
docker
and
kubernetes
and
unix-based
workloads,
so
workloads
that
are
just
native
processes
on
a
host.
A
A
A
A
What
kind
of
a
key
it
is
and
then
also
doing
things
like
computing
digital
signatures
on
different
identity
documents
that
we
make
is
something
we
may
want
to
offload
to
a
third
party
system,
and
so
or
the
built-in
plug-ins
today,
for
the
key
manager
are
the
disk
and
memory
plug-ins.
So
you
can
store
the
keys
on
disk
which
allows
you
to
retrieve
them
on
the
host
after
the
server
or
the
agent.
A
A
What
this
does
is
it
publishes
notifications
of
different
key
operations
in
spire,
and
it
currently
is
only
used
to
publish
trust,
bundle
events,
so
when
a
bundle
is
changed,
you
can
publish
that
new
bundle
out
to
some
third-party
storage.
So
the
plugins
that
you're
supporting
here
today
are
google
cloud
storage
or
in
kubernetes
bundle
where
you
can
write
out.
This
bundle
submit
to
some
external
storage.
A
A
A
My
node
is
ester
and
then
there
are
three
key
things
to
point
out
here:
one
is
you
have
a
plug-in
command,
which
is
a
path
to
the
binary
on
the
host
that
the
spire
server
inspire
agent
processes
can
launch,
and
then
you
can
optionally
provide
a
sha-256
checks
from
of
that
binary
so
that
you
can
know
that.
That
binary
is
something
that
you
expected
and
not
something
that's
been
modified
on
the
host
and
then
whatever
data
is
required.
For
that
plug-in.
A
A
So
a
very
common
paradigm.
Now
is
this
idea
of
the
service
mesh
where
you
have
these
proxies,
which
manage
the
network,
connectivity
and
routing
between
different
services
in
your
environment,
and
you,
you
know
center.
You
know
the
logging
and
you
know,
centralized
operations
of
authentication
and
things
like
that.
So
spire
actually
has
a
native
integration
with
envoy.
A
Another
example
here
is:
how
do
you
use
an
svid
outside
of
your
own
infrastructure?
So
if
you
have
external
services,
which
are
part
of
your
environment,
which
is
probably
pretty
likely,
if
that
supports
open
id
connect
federation,
you
can
set
up
federation
with
inspire
it
supports
federation,
and
so
there's
an
example
that
has
been
put
together.
It's
pretty
cool
that
actually
shows
how
you
can
authenticate
to
aws
management
apis
using
svids.
A
So
what
are
some
future
extensions?
We're
considering
there's
a
proposal
going
out
currently
called
in
age
list
mode,
where
you're
able
to
request
spire
issued
identity
directly
from
the
server
as
opposed
to
from
the
agent.
So
this
kind
of
enables
things
like
the
serverless
use
case,
where
you
don't
have
like
a
dedicated
node,
where
the
process
is
running,
it's
something
that
you
know
comes
up
and
it's
transparent
to
you.
A
You
don't
have
control
of
that
node
entirely,
and
then
we
also
have
started
exploring
some
integrations
with
apache
data
projects,
so
in
that
hadoop
kind
of
ecosystem,
there's
kerberos
based
identity.
So
how
do
we
translate
the
kerberos
based
identity
into
spiffy
identities
and
make
that
coexist
in
this
environment?
A
So,
to
conclude,
here
we
showed
how
spire
can
be
extended
for
different
use
cases
and
bring
identity
to
complex
environments
that
may
have
a
variety
of
proprietary
or
open
source
or
cloud
native
tooling,
and
we
showed
how
this
plug-in
model
inspire,
enables
you
to
develop
your
own
internal
proprietary,
extensions
or
open
source
extensions
that
other
people
can
consume
as
well,
and
so
here
are
the
the
links
to
reach
out
to
the
community.
We'd
love
to
hear
from
you.
A
If
you
have
input
on
any
potential
future
plugins
or
you
know,
if
you
have
questions
about
some
of
the
existing
plugins
or
what's
available,
we're
very
happy
to
engage
with
you
further.
We
have
a
website
here,
and
these
are
our
github
links.
We
also
have
a
slack
and
a
twitter
if
you're
interested
in
subscribing
to
some
of
the
news
around
the
spiffy
inspired
projects.