►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Production Workload Identity with SPIRE - Ryan Turner, Uber
Have you ever wondered how to effectively enable secure authentication between workloads and operationalize TLS within your production network at scale? SPIRE, a CNCF Incubating project, addresses these concerns by providing short-lived, automatically rotated identities to workloads based on the SPIFFE specification. This session will introduce the core design of SPIRE and how it can be leveraged in cloud-native architectures to provide defense-in-depth to production environments. To conclude, this session will take a look at some upcoming features that further extend the possibilities of SPIRE as a production identity platform.
A
So
first
they
come
up
with
a
three-tier
architecture
to
represent
different
layers
of
the
application.
So
this
is
composed
of
three
different
layers.
One
is
the
storage
layer
which
is
a
persistent
stateful
layer,
and
that
contains
data
that
is
represented
in
the
system.
Then
there
is
an
application
layer
which
interacts
with
that
stateful
storage
and
creates
reads:
updates,
deletes
that
data
and
then
there's
a
web
presentation
layer
which
is
accessible
to
users
and
that's
how
they
interact
with
the
platform
and
that
web
layer
talks
to
the
app
layer
to
do
different
operations
in
the
system.
A
So
this
is
all
in
this
example
running
in
an
aws
vpc
and
as
an
online
retailer.
This
company
wants
to
provide
some
level
of
security
so
that
not
everything
in
their
production
deployment
is
accessible
over
the
internet.
So
they
do
this,
naturally
through
vpc
at
goals,
and
they
basically
set
up
three
different
echo
policies.
One
says
that
only
things
from
the
internet
can
access
the
web
subnet
only
things
from
the
web
subnet
can
talk
to
the
app
subnet
and
only
things
from
the
app
subnet
can
talk
to
the
storage
subnet.
A
So
they
move
more
towards
a
microservice
architecture
and
suddenly
their
deployment
has
gotten
much
more
complicated,
so
you'll
see
in
the
middle
and
bottom
layers,
where
there
was
only
one
subnet
there.
Now
that's
tripled,
where
the
service
in
the
app
subnet
has
now
been
decomposed
into
three
different
services,
the
account
service
and
order
service,
which
talks
to
the
account
service
to
get
information
about
an
account
and
then
a
recommendation
service
which
talks
to
both
the
account
service
and
the
order
service
to
provide
customized
recommendations
to
users,
and
each
of
these
services
has
its
own
database.
A
Additionally,
the
operations
team
has
come
up
with
a
requirement
to
be
able
to
access
the
instances
running
in
production
through
a
jump
box,
and
so
there's
a
new
admin
jump
box
subnet,
which
is
a
much
more
privileged
subnet
and
can
talk
to
things
in
the
web
subnet,
as
well
as
things
in
the
app
subnets
so
quickly.
The
organization
realizes
this
is
something
that's
difficult
to
manage.
A
A
A
A
They
also
want
to
protect
users,
privacy
and
confidentiality,
and
this
is
important
because
they
are
now
introducing
physical
meetups
for
the
board
game
tournaments.
So
something
about
users,
location
at
a
certain
time
could
be
exposed
if
an
unauthorized
actor
or
malicious
actor
was
able
to
obtain
that
data.
So
this
is
kind
of
sensitive
data
that
we
want
to
protect.
A
A
Additionally,
this
perimeter-based
security
model
is
really
not
sufficient
on
its
own
to
protect
unauthorized
access
to
services
in
the
network.
Take,
for
example,
this
admin
jump
box.
If
anyone
were
able
to
compromise
an
operations
team's
credentials
and
get
ssh
access
to
that
vm
in
the
subnet
for
the
admin
jump
box,
they
basically
have
unfettered
access
to
any
of
the
microservices
running
in
the
vpc.
A
A
What
we
really
need
is
a
secure,
precise
way
of
identifying
workloads
to
enable
strong
authentication
in
service
to
service
communication
in
order
to
limit
access
to
only
authorized
actors
in
the
system.
So
this
is
kind
of
the
mission
statement
here.
This
is
what
we're
trying
to
achieve
to
satisfy
the
business
challenge
security
challenges
that
we've
identified.
A
Well,
this
is
where
spiffy
comes
in,
so
spiffy
stands
for
secure
production,
identity
framework
for
everyone,
and
it's
an
open
source
set
of
specifications
that
define
what
is
a
workload
identity.
How
do
you
represent
it
and
how
do
you
as
a
workload
obtain
its
identity,
and
this
concept
of
a
workload
identity
in
spiffy
is
not
tied
to
any
network
level
constructs
like
ip
address
or
dns
name,
so
it
allows
us
to
in
this
more
microservices
container-based
world
identify
workloads.
A
So
this
is
one
example.
We
have
three
components
to
spiffy
id.
One
is
a
static
scheme
which
indicates
that
this
is
a
spiffy
id,
so
it
just
is
a
static
component
and
then
the
host
portion
of
the
uri
is
something
called
a
trust
domain
and
a
trust
domain
is
really
like
a
logical
security
and
or
administrative
boundary
for
trust.
A
And
then,
finally,
the
path
component:
this
is
really
a
user
defined
value.
It
can
be
anything.
The
specification
does
not
really
dictate
what
the
value
is
other
than
what
characters
can
be
in
the
path.
But
basically
this
path
is
what
is
representing
the
name
of
the
workload
that
other
workloads
can
use
to
identify
it.
A
A
A
A
So
there
are
two
different
kinds
of
defined
in
spiffy
today.
One
is
an
x509
and
svid,
so
this
is
an
x
509
certificate
with
certain
constraints
defined
in
spiffy,
and
then
there
is
also
a
jaw
tested,
type
json
web
token
and
additionally,
this
s-vid
type
also
uses
the
standard
jwte
format,
but
with
some
additional
constraints
introduced.
A
So
here's
an
example
of
an
x509
svid
and
I've
just
highlighted
the
portions
that
are
relevant
to
highlight
today,
so
we
have
an
issuer
in
this
case.
This
is
issued
by
an
organization
called
spiffy
and
we
also
have
a
subject-
and
here
this
is
the
subject-
is
basically
an
organization
called
spire
and
then
you'll
see
in
the
validity
portion
here,
there's
a
not
before
and
not
after,
and
these
are
actually
only
an
hour
apart
from
one
another.
A
But
the
core
thing
we
want
to
highlight
here
is
this
uri
subject:
alternative
name
in
the
certificate,
and
this
contains
the
spiffy
id
of
the
workload.
So
this
is
really
what
identifies
what
this
certificate
is
issued
for.
In
this
example,
it's
issued
for
the
service
orders
in
the
example.org
trust
domain
and
then
here's
an
example
of
a
jawasvid
so
very
similar.
A
There's
also,
these
other
two
claims
exp,
which
stands
for
expiration
time
and
iat,
which
stands
for
issued
at
and
you'll,
see
here
that
these
values
only
differ
by
300
unix
seconds
here
and
300
seconds
is
5
minutes.
So
again,
this
is
highlighting
that
this
is
a
short-lived
identity
which
is
really
powerful,
because
if
the
identity
was
compromised
in
any
form,
it
would
only
be
valid
for
up
to
five
minutes.
In
this
example,.
A
A
It's
a
server
streaming,
rpc,
meaning
that
when
the
client
connects
it
opens
this
long
live
stream
over
which
the
server
can
actually
push
things
later,
so
we'll
see
how
that
works
later
and
then
there's
a
jawdsfit
api
which
in
this
case
is
a
unary
rpc.
So
that
means
the
client
will
request
its
identity
and
then
it'll
just
receive
the
response
and
anytime
it
needs
another
identity.
It
just
re-requests
it
from
this
rpc.
A
A
A
A
So
there
are
three
components
here
on
the
right:
we
have
the
spire
database,
and
this
contains
information
about
the
different
types
of
workloads
that
can
receive
identity
in
this
environment
and,
in
this
case
we're
talking
about
a
trust
domain,
which
is
the
logical
boundary
for
aspire
deployment
and
aspire
server.
Deployment
here,
talks
to
the
spire
database
and
manages
those
workload
registrations,
and
this
can
be
deployed
as
a
highly
available
active
active
deployment
and
then
on
the
left.
A
So
at
the
top
here
we
have
a
component
called
workload
orchestrator,
and
this
could
be
something
that
is
like
a
deployment
engine
which
launches
containers
or
launches
processes
that
need
identity.
It
also
could
be
a
separate
service
which
uses
a
source
of
truth
that
shares
with
a
workload
orchestrator.
A
A
What
its
purpose
in
this
diagram
is
is
to
actually
make
those
registrations
in
the
spire
server
to
designate
that
these
are
identities
which
should
be
available
in
this
environment,
and
so
in
this
example,
where
our
workload
orchestrator
is
going
to
deploy
an
instance
of
the
order
service
and
the
account
service,
and
so
when
it
goes
to
do
that
deployment.
It's
going
to
reach
out
to
this
fire
server
and
it's
going
to
register
identities
for
the
orders
and
accounts
services,
and
then
spire
server
is
going
to
persist
those
workload
registrations
in
its
database.
A
Okay.
So
this
is
kind
of
the
registration
onboarding
flow.
Now
on
the
left.
Here
we
have
two
different
hosts:
a
host,
a
and
host
b
again,
and
each
of
those
is
running
an
instance
of
aspire
agent,
so
spider
agent
is,
has
a
secure
channel
set
up
with
aspire
server
and
it
requests
all
of
the
workload
identities
that
it
can
serve
on
the
host
that
it's
running
on.
A
So
it's
going
to
send
certificate,
signing
requests
for
all
the
x
509
identities
that
I
can
serve
and
the
spire
server
will
sign
those
certificate,
signing
requests
for
all
those
work,
related
entities
and
send
them
back
to
the
agents
that
were
requested,
those
signings
okay.
So
now
the
agent
has
the
identities
for
the
workloads
cached
locally.
A
A
Now,
both
of
those
services
get
their
identities
from
spire
and
they
set
up
the
secure
channel
over
mutually
authenticated
tls,
and
now
the
order
service
can
issue
an
rpc
over
the
secure
channel
and
using
the
spiffy
id
present
in
the
x510
and
s
vid.
The
account
service
can
actually
verify
whether
or
not
the
service
that
is
making
the
request
is
is
authorized
to
issue
that
request,
so
it
can
basically
define
an
authorization
policy
which
says
the
only
the
order
service
is
allowed
to
access
the
get
user
account
api,
for
example.
A
And
then
the
next
part
of
the
life
cycle
of
the
x510
svid
is
that
at
some
point
it's
going
to
expire.
So
the
agent
has
to
request
new,
updated
rotated
s-vids
for
these
workloads,
so
it
reaches
out
to
the
spire
server
and
asks
for
newly
signed
certificates
and
the
spyer
server
refreshes,
those
x509
edit
identities,
in
the
same
way
that
it
originally
issued
them
by
signing
the
certificate
signing
request
sent
by
the
agent
and
then
once
the
agents
get
those
updated
identities,
they
actually
pushed
them
to
the
services
which
contacted
them
over
the
workload
api.
A
A
A
So
that's
really
how
spire
identifies
different
workloads
which
run
on
the
different
hosts
in
the
environment,
and
this
is
how
we
represent
registration
inspire,
and
there
are
three
key
properties
I
want
to
focus
on.
One
is
this
50
id,
and
this
is
at
the
top
here.
This
represents
the
workload
itself,
so
this
is
what
the
identity
is
is
issued
for,
as
we
issued
for
the
service
orders
here
then
there's
a
concept
called
a
parent
id,
and
this
parent
id
is
really
powerful.
A
And
so
what
this
means
is
any
service
which
has
is
running
as
a
docker
container
and
has
this
service
name?
Environment
variable
sets
to
the
value
of
orders
and
has
a
pod
name
of
orders
service
and
has
a
kubernetes
namespace.
So
production
is
entitled
to
this
identity
of
service
orders
and
then
selectors
are
powerful
and
there
are
several
that
you
can
choose
from
so
other
examples
here
would
be
like
pod
attributes
in
kubernetes
and
labels
of
docker
containers.
A
Okay,
so
let's
talk
a
little
bit
about
workload
attestation,
so
this
is
the
process
of
identifying
a
workload
and
issuing
an
identity.
So
at
the
top
here
we
have
a
workload
which
reaches
the
spire
agent
over
the
workload
api
to
request
its
identity,
and
this
is
not
on
authenticated
requests.
The
workload
doesn't
provide
any
sort
of
like
certificate
or
token
or
key
or
anything.
It
just
says:
hey
give
me
an
identity,
and
the
spire
agent
uses
these
different
configured
workload,
tester
plugins,
to
determine
what
that
workload
is.
A
So,
in
the
case
of
a
unix,
it's
going
to
reach
out
to
the
linux
kernel
in
the
case
of
docker,
it's
going
to
reach
out
to
the
docker
demon
on
the
host
and
in
the
case
of
kubernetes,
is
going
to
reach
out
to
the
local
kubelet
agent
running
on
the
host
okay.
So
the
workload
contacts
the
workload
api
asks
for
its
svid.
The
agent
asks
for
all
the
selectors
about
that
process
from
these
different
plugins,
and
then
it
gets
a
set
of
all
of
these
selectors
available
about
that
process.
A
So
we
know
that
this
process
is
running
with
this
uid
of
one
two
three
four
five
with,
which
is
a
user
called
bob,
and
then
it
has
the
service
name.
Environment
variable
set
in
docker
called
orders,
and
it
has
a
pod
name
in
kubernetes
called
orders
hyphen
service,
and
it
has
a
kubernetes
namespace
of
production.
A
So
that's
how
workload
attestation
works
now,
what
have
we
seen
so
far?
Okay,
this
is
there's
been
a
lot
of
concepts
we
talked
about
and
how?
What
does
it
all
mean?
So
we've
seen
that
the
orders
and
the
account
services
are
now
bootstrapped
with
cryptographically
verifiable
identities
and
in
this
case
it's
an
x509s
vid.
A
Using
that
verification
they
can
use
secure
communication
using
mutually
authenticated
tls
to
encrypt
traffic
between
the
orders
and
account
services
and
using
this
svid
concept,
the
accounts
service
can
now
actually
identify
in
a
very
precise
and
secure
way
what
the
workload
is
on.
The
other
side
of
the
channel
using
the
spiffy
id
present
in
the
svid
and
based
on
that
authentication
method,
it
can
actually
start
to
write
some
authorization
policies
to
say
only
service
orders
can
contact
this
account
service
for
this
particular
api.
A
A
So
an
example
might
be
like
a
proxy
on
a
host
where
services
all
route
their
traffic
through
a
local
proxy
and
then
the
proxy
determines
what
is
the
identity
of
the
caller.
And
how
do
I
propagate
that
identity?
In
like
a
tls
connection,
for
example,
then
we
are
also
working
on
improving
the
support
for
federation
and
federation
is
really
a
concept
in
spiffy,
where
based
on
different
trust
domains.
A
We
are
also
trying
to
enable
secret,
less
authentication
to
gcp
using
openid
connect
federation.
Then,
in
the
long
term
we
are
working
on.
How
do
we
improve
the
key,
revocation
and
forced
rotation
within
spire
and
then,
similarly
for
azure?
We're
also
trying
to
enable
secret
list
authentication
using
oidc
federation
and
we're
working
on
some
production?
Readiness
kind
of
work
like
improving
the
health
check
subsystem
to
be
more
robust
and
improving
error
messages
so
that
they're
more
actionable
to
users.