►
From YouTube: Securing Multi-Cloud Cross-Cluster Communication with SPIFFE and SPIRE - Evan Gilman, Scytale, Inc.
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
Securing Multi-Cloud Cross-Cluster Communication with SPIFFE and SPIRE - Evan Gilman, Scytale, Inc.
Securing network traffic that traverses multiple software stacks and platforms is challenging. Difficulties involving platform-aware applications, supporting multiple authentication schemes, and maintaining complex authorization logic are all commonplace, despite the fact that we'd really rather avoid these things. SPIFFE provides a platform-agnostic identity layer that can be used to authenticate and secure workload communication regardless of where the workload lives. AWS, Azure, and on-prem? Ok! Kubernetes, Mesos, and bare metal? No problem! SPIFFE allows you to mix and match without the need to worry about how workloads within them will securely communicate with each other. In this talk, we will leverage SPIRE to demonstrate automated issuance of SPIFFE identity across disparate orchestrators and platforms, allowing for seamless authentication of systems within and between them.
https://sched.co/MPdr
A
Okay,
so
hi
everybody
we're
gonna
get
started
just
like
normal
I.
Think
we'll
have
questions
at
the
end,
so
save
your
questions.
I'll
run
around
with
a
microphone.
My
name
is
Tim
Hendricks
I'm
from
Styron
the
open
policy
agent
I'm
your
track
host.
The
other
thing
I'll
remind
you
of
is
to
please
rate
the
talk
at
the
end,
you
log
onto
sched
to
do
that
and
then
you
just
rate
it
without
further
ado.
A
B
So
welcome
to
multi-cloud
cross
cluster
authentication,
a
spiffy
inspire
so
before
we
start
a
little
bit
about
myself,
I'm
born
in
Miami
Florida
in
the
United
States
and
started
my
career
in
network
engineering
bounced
all
around
after
that
from
storage
systems
to
automation,
traditional
ops,
I.
Sorry,
all
that
kind
of
stuff
been
living
in
San
Francisco
in
the
US
for
about
six
years
now
and
I'm,
currently
working
at
a
company
called
Scytale,
focusing
full-time
on
the
Smithey
inspired
projects.
B
So
first
talk
a
little
bit
about
spiffy,
so
I
mentioned
spiffy
as
a
specification
or
set
of
specifications.
Actually,
it's
really
just
a
bunch
of
markdown
Docs
and
a
github
repository,
but
the
goal
of
that
is
to
kind
of
define
a
standard
for
platform-agnostic
workload,
identity,
so
we're
clear
identity
that
is
not
necessarily
tied
to
a
particular
platform.
A
runtime
and
there's
three
main
concepts
in
in
this
spiffy
specification
set.
There's
a
fourth
one.
B
Actually
that
I'll
talk
about
kind
of
towards
the
end,
but
the
first
of
this
of
those
three
is,
what's
called
a
spiffy
ID,
and
this
is
what
one
looks
like
it's,
basically
just
a
structured
string
that
is
modeled
as
a
URI
and
the
one
way
to
think
about.
It
is
like
kind
of
like
a
username
for
workloads
that
is
somewhat
human
friendly,
and
this
specification
isn't
super
prescriptive
about
what
values
you
put
in
here
like
it
doesn't
actually
have
to
be
a
dns
name
like
in
this
example.
B
You
can
choose
whatever
values
you
want,
whatever
makes
sense
for
your
particular
deployment
as
long
as
you
follow
this
kind
of
overall
structure,
so
in
terms
of
meaning
in
terms
of
that
structure,
you
have
this
middle
part,
the
blue
bit
here,
which
is
representing
an
issuing
authority
or
what
we
call
a
trust
domain
and
everything
after
that.
The
green
part
is
the
the
worklet
identity
which
is
residing
within
this
trust,
domain
or
authority,
and
these
things
like
you,
can
form
them
hierarchically.
B
If
you
wish,
but
like
I
said
the
spec
isn't
prescriptive,
so
you
don't
really
have
to
if
it
doesn't
make
sense
for
you.
The
next
thing
we
have
is
what
we
call
an
S.
Vin
stands
for:
spiffy,
verifiable
identity
document,
and
basically
these
are
just
signed
documents
that
you
use
to
prove
your
identity
to
a
remote
system
right
and
there's
lots
of
existing
document
types
out
there.
So
we
didn't
really
want
to
reinvent
the
wheel,
and
we
also
wanted
this
to
work
with
currently
deployed
software's.
So
we
have
two
types
of
estimates
defined.
B
Currently,
one
is
based
on
x.509
certificates
and
the
other
is
based
on
job.
And
finally,
the
third
piece
is
what
we
call
the
workload
API,
this
kind
of
answers,
the
question
of
how
do
I
get
my
identity
right,
and
this
is
a
really
important
piece
of
the
vision
so
to
speak,
because
it
abstracts
the
platform
and
the
implementation
away
from
the
workload.
B
So
this
is
a
node
local
API.
It's
not
like
a
centralized
API
and
the
reason
it's
not
authenticated
is
because
we
don't
want
to
require
the
workload
to
provide
a
secret
or
something
in
order
to
bootstrap
it.
So
if
we
wanted
to
be
able
to
be
deployed
without
any
kind
of
knowledge
of
what
its
identity
is
or
any
kind
of
secret
that
is
baked
into
it
or
anything
like
this,
be
able
to
kind
of
pop
up
and
just
get
this
identity
ambiently,
so
to
speak.
B
So
it
removes
the
need
to
inject
like
credentials
at
deploy
time.
It
removes
the
need
for
your
CI
CD
system
to
have
access
to
all
the
things
so
on
and
so
forth.
So
what
you
end
up
at
the
end
of
the
day
with
is
something
that
looks
like
this,
and
this
is
really
where
spiffy
shines.
I
think
because
work
loads
can
do,
they
can
get
their
identity
ambiently
from
this
workload
api
and
they
can
use
it
to
do
direct
mutual
TLS
with
other
workloads.
And
you
don't
really.
B
This
workload
doesn't
really
care
where
it
is
because
the
workload
api
is
a
is
a
standardized
interface.
It
doesn't
really
care
where
its
peers
are
or
where
they're
running,
because
we
have
this
kind
of
standardized
definition
of
identity
and
how
you
how
you
authenticate
it.
So
you
can
see
in
this
in
this
diagram
that,
like,
if
you've
just
defined
the
right
interfaces
between
these
things,
then
securing
this
kind
of
cross
cloud
cross
cluster
stuff
becomes
fairly
straightforward,
because
all
the
things
are
important
in
order
to
do
it
aren't
necessarily
tied
to
those
implementations.
B
So
that
leaves
one
big
remaining
question,
which
is
how
do
I
get
this
workload
API?
Where
does
it
come
from
and
who
gives
it
to
me
and
that's
kind
of
where
spire
comes
another
picture
so
aspire
is
a
software
implementation
of
these
spiffy
specifications
and
its
goal
in
life
is
basically
to
light
up.
This
work
live
API
and
as
many
as
virus
as
possible.
B
In
order
to
accomplish
this,
it's
written
in
go
so
it's
portable
and
it's
very
highly
pluggable
about
some
of
those
plugins
here
in
a
second
of
course,
it's
a
security,
sensitive
project
so
before
diving
in
to
the
architecture,
I
thought,
maybe
it
makes
sense
to
just
quickly
go
over
it's
a
high-level
security
model
that
we
try
to
follow
in
this
project,
to
help
reason
about
some
of
the
design
choices
that
we've
made
along
the
way.
Now.
B
So
the
first
is
that
spire
does
not
assume
that
the
network
is
trusted,
so
IP
addresses-
and
things
like
this
are
pretty
much
unusable.
As
a
security,
primitive
and
spire
I
said
we
rely
on
solely
on
cryptographic
mechanisms,
and
the
second
is
that
the
workloads
also
considered
untrusted,
because
at
the
end
of
the
day,
application
can
be
compromised
and
it
can
then
be
in
a
position
to
abuse
this
worklet
api
or
provide
false
information
so
on
and
so
forth.
B
So
the
workload
api
must
not
trust
any
data
that
is
provided
directly
by
the
workload
and
finally,
we
designed
for
node
compromise.
So
you
know
we
expect
that
a
compromised
workload
may
be
able
to
escape
a
container
or
something
like
this,
and
when
that
happens,
this
evil
node
shouldn't
be
able
to
get
or
otherwise
make
identities
that
it
shouldn't
have
access
to.
B
So
with
that
out
of
the
way,
let's
have
a
look
at
the
architecture
quickly,
Spira
can
prize
us,
two
major
components:
a
server
and
an
agent.
The
spire
server
is
responsible
for
identity
mapping.
So
that's
like
you
know
what
smithy
ID
should
be
given
to
whom
and
when,
and
it's
also
responsible
for
a
process
that
we
call
no
data
station
which
I'll
talk
about
in
a
minute
and
it's
also
responsible
for
s
fit
issuance.
B
So
creating
these
certificates,
minting
them
and
issuing
them
aspire
agent,
on
the
other
hand,
is
responsible
for
a
process
that
we
call
workload
out
to
station,
which
is
similar
to
no
data
station,
but
for
work
lives
which
will
also
kind
of
dive
into,
and
it's
ultimately
responsible
for.
Turning
on
the
workload
API
so.
A
B
How
this
works
we'll
start
from
the
beginning.
We
have
this
spire
server
at
the
very
top
and
it
acts
as
the
authority
right.
So
when
it
first
boots,
it
generates
like
a
CA
certificate
that
is
gonna,
be
used
to
sign
all
the
identities
in
this
particular
trust.
Amazed,
remember.
A
trust
domain
is,
as
represents
this
authority,
so
there's
kind
of
this
one-to-one
relationship
with
spire
server
and
Trust
domain,
so
I
mentioned
inspire
is
really
pluggable,
so
spire
server
does
have
a
plugin
called
an
upstream
CA
plugin.
B
But
with
that
in
mind,
you
have
to
ask
the
question
like
how
does
the
server
know
that
is
actually
an
agent
requesting
a
certificate
and
not
an
attacker
or
something
else?
And
if
you
recall
the
security
model,
we
can't
just
let
any
agent
ask
for
any
certificate
either.
So
we
have
to
know
exactly
which
agent
is
requesting
this
thing
right,
and
we
have
to
know
that
it's
supposed
to
be
requesting
this
thing
that
it's
allowed
to
do
that.
B
So
the
first
step
in
answering
this
question
is
this
concept
of
note
attestation,
and
this
allows
the
server
to
precisely
identify
a
particular
agent
instance,
and
this
is
how
it
works.
This
server
and
the
agent
both
have
a
plug-in
called
a
node,
a
tester
plugin,
and
this
plug-in
is
platform
dependent.
But
the
server
supports
loading.
An
arbitrary
number
of
these
note,
a
tester
plugins.
So
it
allows
you
to
mix
and
match
the
agent
platform.
B
So,
for
instance,
you
might
have
a
set
of
agents
in
AWS,
a
set
of
agents
and
GCP
set
of
agents
and
Azure
on
from
so
on
and
so
forth,
and
the
server
the
server
knows
how
to
perform.
It
a
station
for
all
of
those
so
when
the
agent
starts
up
the
first
thing
that
it
does,
is
it
pokes
this
no
to
tester
plug-in
and
this
nerd
a
tester
plug-in,
gathers
proof
of
the
platform
identity
that
it's
running
on.
B
So
the
agent
grabs
this
thing
and
then
it
sends
that
document
over
to
the
server
know
with
AWS
and
was
similar
in
Google
Cloud.
This
process
is
mostly
one-way,
but
the
protocol
between
the
server
and
the
agent
actually
supports
challenge/response
so,
depending
on
the
node,
a
tester
that
you're
using
you
can
get
a
lot
more
exotic
than
simply
passing
a
document
back
and
forth.
B
B
This
s
feel
like
uniquely
identifies
that
particular
agent
on
that
particular
platform
and
at
this
point,
all
connections
going
forward
between
the
agent
and
the
server
are
done
with
mutually
authenticated
TLS
using
this
agent
identity
is
the
client
certificate.
So
now
we
can
kind
of
differentiate
exactly
which
agent,
as
which
one
is
calling
spire
server,
but
we
still
need
to
kind
of
figure
out
which
workload
is
which
right,
in
fact,
we
actually
have
to
give
them
a
name
or
an
identity.
B
So
we
have
to
teach
spire.
What
is
what
so?
This
is
how
we
do
that.
This
is
what
we
call
a
registration
entry,
it's
basically
an
identity,
mapping
that
I
was
kind
of
alluding
to
and
before,
and
a
server
exposes
an
API
for,
adding
and
deleting
these
things,
there's
also
a
CLI
utility
that
you
can
use
to
interact
with
them.
B
So
if
we
look
at
this
entry,
you
can
see
a
few
things
on
there
now.
The
first
is
what
we
call
a
parent
ID,
which
is
essentially
like
where
the
workload
is
supposed
to
run.
So
in
this
case,
the
workload
is
running
in
a
kubernetes
cluster
named
foo
right.
We
additionally
give
these
things
that
we
call
selectors,
which
are
kind
of
these
innate
properties
of
the
workload,
and
we
use
that
to
describe
the
workload,
because
when
it
comes
up,
it
doesn't
already
have
an
identity.
It
doesn't
already
have
any
secret.
B
You
know
we
can't
there's
no
easy
way
to
identify
right,
so
these
are
kind
of
like
the
dimensions
of
the
workload.
So
in
this
case
who
said
hey
this
workload
is
running
in
the
kubernetes
namespace
operations.
It
should
be
running
on
fear
and
IT
service
account
MediaWiki,
and
it's
running
this
particular
docker
image
ID.
B
Finally,
if
we
define
a
spiffy
ID,
hey
where
all
these
things
match-
and
you
see
this
workload
come
up,
then
this
is
the
spiffy
ID.
You
should
give
it
so
now,
spire
can
tell
which
agents
are
authorized
to
issue
this
thing,
because
we
know
that
hey
should
be
at
any
agent
is
running
in
cluster
foo.
We
also
kind
of
know
the
basic
shape
of
the
workload,
and
we
know
that
when
we
see
that
that
particular
workload
shape
in
this
particular
place,
then
we
should
give
it
Mississippi
ID,
okay.
B
So
now
the
question
is:
how
does
the
agent
figure
out
all
this
information
right?
The
server
knows
that
the
agent
can
request
it,
so
the
agent
can
request
it
with
them.
The
agent
has
to
be
able
to
tell
hey
you
know
what
service
encounter
you
in
so
similar
to
no
data
station.
We
have
this
flow
called
workload
out
to
station
and
talked
a
little
bit
about
how
that
works
when
the
agent
boots
up
after
following
no
data
station,
it
exposes
this
workload
API
on
a
UNIX
domain.
Socket.
B
B
So
now
it's
the
agent's
job
to
figure
out
the
shape
of
this
workload
and
who
it
is,
and
in
order
to
do
this,
the
agent
uses
the
kernel
in
this
case
the
Linux
kernel,
but
works
on
BSD
is
to
to
find
out
what
process
is
calling
it
and
once
it
knows
what
process
is
calling
it.
It
can
do
further
lookups
to
find
more
information
about
that
particular
process.
So
basic
example
might
be
what
user
and
group
is
this
process
running
as
what
is
the
shah
of
the
binary?
B
That
is
calling
me
right
now
things
along
those
lines
and
similar
to
no
data
station
workload.
Attestation
is
also
fully
pluggable
and
you
can
have
multiple
workload
and
test
your
plugins
per
agent
and
you
can
mix
and
match
those
selectors
right.
So
here
using
the
UNIX
workload,
a
tester
I
can
surface
all
these,
like
UNIX
oriented
properties,
but
we
can
use
others
too.
So,
for
instance,
we
have
a
kubernetes
workload,
a
tester
that
knows
how
to
call
the
qubit
nicely
cubelet
all
kinds
of
questions.
B
B
So
the
agent
takes
all
this
information
that
it
gets
back
from
these
workload
of
testers
and
it
forms
the
selectors
that
we
were
looking
at
before
and
that's
how
we
describe
the
particular
workload
right.
So
now
we
know
number
one
where
this
workload
is
running,
because
we
know
hey
is
talking
to
this
particular
agent,
which
is
in
this
particular
cluster,
and
we
know
to
what
identity
to
issue
it,
because
the
agents
been
able
to
figure
out
all
this
information
about
the
caller.
B
So,
finally,
our
workloads
are
all
issued,
spiffy
ideas
and
once
received
I
mentioned
before
they
can
be
used
directly
for
TLS
at
least
the
x.509
s.
Feds
can-
and
this
forms
a
really
valuable
building
block
for
authorization
of
systems
like
OPA,
because
it
gives
you
kind
of
this
stable
concept
of
identity,
stable
identifier
that
is
gonna,
be
kind
of
very
well
defined
and
the
same
pretty
much,
no
matter
what
platform
you're
on.
B
So
at
this
point,
you
might
be
asking
like,
what's
the
deal
with
this
server
component,
like
how
am
I
supposed
to
how
am
I
supposed
to
do
this
cross
cloud
thing
when
I
have
this
server
component
so
like
how
many
of
them
might
I
be
able
to
have,
and
if
I
have
more
than
one
like
how
do
they
interact
with
each
other?
So
this
is
the
part.
I
want
to
talk
a
little
bit
about
kind
of
what
I'm
just
called
deployment
topologies
or
like
configurations
of
Speyer.
B
We've
been
thinking
about
this
for
a
long
time
and
in
order
to
kind
of
support
these
cross-platform
deployment
is
ideally
we've
implemented.
Three
different
kinds
of
general
topologies.
Each
one
of
them
solves
a
different
problem.
So
let's
have
a
look
at
those.
The
first
of
these
options
is
scaling.
Spire
server
horizontally
in
this
configuration
spire
servers
have
to
share
a
datastore,
and
each
one
of
these
servers
maintains
a
separate
root
certificate
in
key.
B
So
there's
still
one
trust
domain
here,
but
the
bundle
the
validation
keys
for
that
particular
trust
domain
is
the
essentially
the
union
of
all
the
CA
search.
The
spire
servers
are
maintaining,
so
this
option
can
be
pretty
good
for
dealing
with.
Load
can
also
be
okay
for
running
across
availability
zones,
or
things
like
that,
but,
as
many
of
you
might
be
familiar
with,
it
can
be
hard
to
manage
across
cloud
datastore
for
system
stores.
B
The
second
option
is
something
that
we
call
nested
aspire,
and
so
what
this
allows
us
spire
service
to
kind
of
be
chained
together
and
to
form
like
arbitrary
trees
and
it
works
by
collocating,
an
agent
with
a
spire
server.
We
call
these
like
downstream
spire
servers
and
that
allows
that
downstream
node
to
perform
no
doubt
test
ation
and
workload
attestation
back
up
to
the
spire
server
in
the
next
level,
which
is
kind
of
cool,
because
it
lets
just
turn
on
new
servers
automatically.
B
There's
no
intervention
required
or
operators
to
be
juggling
access,
control,
lists
or
keys,
or
anything
like
you
can
throw
these
things
I'm
like
an
auto
scale
group
and
it's
just
gonna
work.
So
this
is
much
much
better
for
multi
cloud
deployments.
You
can
imagine
this
top
server
kind
of
being
like
this
global
global
server,
a
global
cluster,
and
then
these
downstream
servers
might
be
it
like
the
regional
level
or
the
cluster
level
or
something
along
those
lines
and
because
you
can
mix
and
match
those
Notah
testers.
B
So
in
this
configuration
the
this
global
tier,
the
one
at
the
top
is
the
one
that
holds
the
routes
and
these
downstream
servers
got
intermediate
certificates.
So
this
means
that
this
global
tier
can
go
down
or
connectivity
to
this
global
tier
can
be
severed
or
perhaps
you
take
it
offline
purposefully
and
the
intermediates
will
continue
to
operate
without
a
problem
now.
So
this
is
a
pretty
robust
configuration
that
can
help
to
address
load
and
differing
failure
domains,
but
it
is
still
just
one
trust
domain
with
one
set
of
routes.
B
The
final
configuration
is
what
we
call
federated
speier.
This
allows
you
to
carve
like
multiple
trust
domains
with
disparate
routes,
and
this
concept
of
federation
is
actually
a
spiffy
concept,
not
a
spire
concept,
and
it
is
in
fact
the
fourth
concept
that
I
alluded
to
earlier
and,
as
you
can
see
from
this
slide
is
still
kind
of
a
work
in
progress.
B
Oh,
if
I
didn't
include
it
in
the
beginning,
spiffy
Federation
specification
has
been
under
development
for
about
the
last
six
months
or
so
and
has
in
the
last
month
stabilized
fairly
well,
so
we
have
a
spire
prototype
underway
and
you
should
see
a
preview
of
that
feature
land
pretty
soon.
So
with
this
feature,
we
can
the
spire
servers
can
essentially
swap
with
each
other,
not
the
keys,
of
course,
but
the
certificates,
and
you
can
then
like
pass
these
roots
down
to
the
workloads.
B
The
workloads
know
how
to
validate
workloads
and
other
trust
domains
or
in
other
platforms.
So
it
gives
this
really
nice
kind
of
loose.
Coupling
that
is
not
just
can
can
address
failure.
Domain
concerns
we
can
also
address
security
domain
concerns
if
a
particular
CA
certificate
is
stolen,
or
something
like
that,
you
can
be
assured
that
you
won't
be
able
to
mint
identities
in
this
and
this
other
trust
Amin.
B
So
that's
really
really
cool
I
think
at
least-
and
you
should
probably
see
a
preview
of
that
drop
in
the
next
one
month
or
so
and
aspire
and
I
did
have
a
demo
prepared
for
you
guys,
a
really
cool
and
actually
with
two
mini
cubes
and
all
this
stuff,
but
unfortunately,
I
can't
show
it
to
you
today.
There's
some
problems
with
my
local
environment.
So
that's
a
bummer
I'm
going
to
push
it
up
to
my
github,
though,
and
I'll
write
a
short
blog
post
on
it.
B
For
you
all,
so,
if
you're
interested
in
seeing
that
please
just
keep
an
eye
on
my
Twitter
and
I'll
put
some
links
up
there
in
the
next
week
or
two.
No,
but
if
you
want
to
learn
more,
we
have
the
existing
github
repos.
The
first
one
is
the
spire
as
that
software
implementation
that
we've
been
talking
about
a
second
one
is
the
spiffy
github
repo.
That's
where
all
the
specifications
live,
all
the
markdown
documents,
and
things
like
that.
B
So
if
you
want
to
build
your
own
spiffy
implementation,
that's
the
the
place
that
you
should
go
and
then
finally,
our
slack
channel
is
open
to
the
public.
We
have
a
very
active
community
there,
so
if
you
have
any
questions
at
all
or
just
like
to
try
some
stuff
out
or
even
hack
on
some
of
these
things,
please
just
pop
in
we'd
love
to
see
you
there.
That
is
all
I
have
for
you
today
guys.
Thank
you.
B
B
The
sto
Citadel
does
not
use
Acme
internally,
they
have
an
agent
which
pushes
a
security.
A
security
service
account
token
back
up
to
an
authority.
The
Citadel
server
said
all
server
validates
the
token
and
then
cuts
the
cert
with
that
identity
and
ships
it
back.
They
did
not
use
Acme,
they
may
use
acne
in
the
ingress
gateways
for
like
public
certs,
and
things
like
this,
but
internally
for
the
Envoy
identity
is.
It
is
not,
though
there
are
some
problems
with
acne
that
prevent
it
from
being
applied
here.
B
D
B
To
you,
the
workload
can
request
directly.
It
was
designed
for
a
workload
to
request
directly
because
you
don't
need
anything.
The
the
the
message
you
send
of
the
workload
API
is
literally
just
an
empty,
empty
message
and
you
get
back
your
identity.
It
can
be
a
sidecar
if
you
want
to
use
a
sidecar,
then
in
that
event
the
sidecar
communicates
with
this
workload
API
and
we
issue
the
cert
to
the
sidecar.
So
depends
on
what
model
you
choose
to
use.
B
See
so
SPO
has
a
spiffy
implementation.
They
issue
50
certs
internally,
using
component
called
Citadel
that
this
gentleman
was
asking
about
a
minute
ago.
Hoshi
Corp
console
also
issues.
Spiffy
certificates
and
Hoshi.
Core
vault
knows
how
to
issue
spiffy
certificates,
but
I
wouldn't
quite
go
so
far
as
to
say
that
it's
a
spiffy
implementation.
E
B
I,
don't
think
we
don't
have
one
that
is
that
is
built
into
spire,
but
I
have
seen
one
on
github
that
a
plugin
that
someone
wrote
that
does
upstream
CA
to
vault.
So
you
can
keep
the
root
and
vault,
and
then
you
can
point
this
up
free
PCI
at
it,
and
then
it
will
use
fault
to
cut
an
intermediate
cert
in
stead
of
self
signing
their
routes.
So
the
long
answer
is
yes,
it
can
workers
vault
and
there
are
some
plugin
implementations
out
there.
B
The
short
answer
is:
hey
it's
not
built
in
yet,
but
there's
no
reason
it
shouldn't
be.
We
probably
should
add
it.
There's
also
another
kind
of
facet
which
is
that's
the
upstream
CA
plug
them.
This
server
also
has
another
plugin
called
the
key
manager
plugin,
and
this
is
the
plug-in
that's
used
for
key
persistence.
So
it's
not
necessarily
like
a
PKI
aware
plug-in,
but
it
knows
like
it
has
a
pkcs
11
like
interface.
So
if
you
wanted
to
store
a
key
only
involved,
you
could
do
it
like
this
too.
B
That's
a
great
question:
I
have
a
few
thoughts
on
that.
The
first
is
that
spire
doesn't
support
TRL's
or
like
traditional
exercise
or
9,
revocation,
as
you
know
it
today.
The
answer
that
we
have
right
now
is
is
that
you,
because
all
this
stuff
is
automated,
a
short
lived
certificate
is
a
pretty
reasonable
thing
to
have.
So
you
know
maybe
a
day.
Maybe
two
days
could
be
as
short
as
an
hour
too.
B
So
this
kind
of
you
know
it's
not
quite
revocation,
but
it
it
gets
close
and
it
can
get
close
without
providing
a
lot
of
the
headaches
that
come
with
crl
management.
I,
don't
know
if
you're
familiar
with
some
of
those
headaches,
the
workload
API
the
smithy
specification
for
workload
API
does
support
sending
CRLs.
So
if
you
have
it
now,
the
spire
implementation
doesn't
support
CRO.
But
if
you
have
a
Smithfield
limitation,
which
does
the
kind
of
cool
thing
about
that
is,
we
can
push
a
crl
straight
into
the
workload.
B
So
you
don't
have
all
these
failure
modes
associated
with
like
having
to
go
fetch
it,
and
if
that
endpoint
is
down
and
how
long
does
that
take
and
so
on
and
so
forth?
So
that's
the
general
replication
answer.
We
also
have
a
feature
where,
if
you
know
at
a
particular
node
was
compromised,
you
can
evict
that
node
and
it
will
prevent
that
node
from
being
able
to
rotate
or
obtain
any
further
identities.
So
that's,
revocation,
II,
I
hope
that
answers
your
question.
B
B
That
for
on-prem,
what
you're,
mostly
worried
about
I
think
is
no
data.
Station
localization
can
be
done
using
UNIX
or
other
primitives
that
are
widely
available.
No
data
station
is
a
big
concern
for
on-prem,
but
you
know
because
it's
pluggable
you
can
write
kind
of
whatever
makes
sense
for
you.
We
have
two
kind
of
standard
approaches
that
we
see
people
taking
for
on-prem
right
now.
B
The
first
is
to
use
what
we
call
join
token,
so
we
have
a
method
of
quote
attestation
where
you
can
ask
the
server
to
generate
a
one-time
use
token,
and
then
you
pass
that
to
operators
or
some
configuration
management
or
something
like
this
passes
that
token
to
the
agent
which
is
booting,
and
then
we
kind
of
short-circuit,
some
of
the
more
advanced,
no
doubt
to
station
stuff.
In
that
way.
So
that's
one
option.
B
Another
option
is
to
use
TPMS
or
trusted
platform
module,
which
is
a
chip
that
ships
on
most
servers
these
days,
and
that
gives
a
lot
of
nice
cryptographic
primitives
and
it's
actually
the
strongest
attestation
method
that
we
have
today.
We
don't
have
support
for
TPM
in
core
aspire,
but
you
could
certainly
build
a
node,
a
tester
plug-in
that
interfaces
with
the
TPM
some
of
the
challenges
there
are
around
procurement.
B
You
have
to
be
able
to
understand
which
serial
numbers
are
coming
in
and
when
and
where
they
should
be
coming
online
and
so
on
and
so
forth.
So
those
implementations
tend
to
be
kind
of
a
little
bit
specific
to
the
sites
that
they
run
on,
but
the
interfaces
are
all
set
up
and
because
the
agent
and
server
can
do
challenge
or
spots
together
then
use
a
what
they
call
a
TPM
attestation
quote
as
possible.
D
B
So
the
spiffy
project
until
now
has
had
a
lot
to
worry
and
reason
about
and
a
lot
of
work
to
do
so.
We
kind
of
cut
scope
and
said
we
were
explicitly
going
to
call
user
off
and
user
identity
out
of
scope
for
spiffy
project.
So
we
don't
have
any
text
that
directly
addresses
it
and
we
don't
have
any
like
big
use
cases
to
show
for
it.
However,
that's
not
to
say
that
it
couldn't
be
used
to
solve
some
of
these
problems.