►
From YouTube: Introducing SPIFFE: An Open Standard for Identity in Cloud Native Environments [I] - Evan Gilman
Description
Introducing SPIFFE: An Open Standard for Identity in Cloud Native Environments [I] - Evan Gilman, Scytale
Modern infrastructure patterns like microservices, container orchestration, and hybrid/multi-cloud deployments have turned conventional models for datacenter authentication and security on their heads. In the face of highly dynamic compute and network resources, a new challenge has risen: how to authenticate and secure service-to-service traffic in this brave new world? Enter the problem known as service identity.
Getting service identity right is surprisingly hard, with requirements extending well beyond simple secret management. What kind of credentials to settle on, how to rotate them, how to automatically (and securely) bootstrap them... and even more importantly, how to make sure a wide variety of external systems can authenticate them appropriately? These questions represent only a subset of the points that must be solved for.
In this talk, we introduce both SPIFFE and SPIRE - a new open source project designed to solve exactly these problems. SPIRE, backed by the SPIFFE open standard, performs seamless node and workload attestation across various platforms, and automatically issue short-lived certificates based on those attestations in a controlled manner. Even better, these certificates work across organizational boundaries and heterogeneous environments thanks to SPIFFE, which introduces a standardized identity format and validation methodology for X.509 certificates.
About Evan Gilman
Evan Gilman is an engineer with a background in computer networks. With roots in academia, and currently working on the SPIFFE project, he has been building and operating systems in hostile environments his entire professional career. An open source contributor, speaker, and author, Evan is passionate about designing systems that strike a balance with the networks they run on.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
My
name
is
evan
gilman.
Thank
you
for
coming
before
we
start
I
figured
I'd.
Tell
you
a
little
bit
about
myself.
I
started
my
career
in
academia
originally
doing
with
network
engineering,
did
all
sorts
of
stuff
systems,
administration
and
network
storage,
all
kinds
of
things
I've
been
bouncing
around
the
Bay
Area
for
the
last
five
years
or
so
now,
and
currently
at
this
company
called
Scytale,
where
I've
been
focusing
full-time
on
spiffy
inspire,
which
we'll
talk
about
today,
so
I
figure.
A
First,
we
talked
a
little
bit
about
cloud
native
network
security,
kind
of
what
that
landscape
looks
like
how
previous
patterns
fit
onto
the
current
cloud
native
architecture.
We'll
talk
a
little
bit
about
spiffy
the
problems
that
solves
what
it
aims
to
do
a
little
bit
about
spire
kind
of
from
a
high
level
just
how
it
functions
and
then
to
give
you
a
clearer
idea
of
that.
A
A
This
is
a
quote:
Marc
Andreessen
who's,
a
notable
Silicon
Valley
investor-
and
this
is
definitely
true
for
cloud
native
network
security
space,
the
controls
we
see
from
security
controls,
moving
up
in
the
software
out
of
hardware
and
out
of
the
network
where
they
have
been
historically
for
literally
decades,
and
there
are
lots
of
really
great
projects
which
are
aimed
to
kind
of
solve
for
this
network
security
automation.
But
when
you,
when
you
do
this,
when
you
solve
for
that
problem,
you
kind
of
have
to
choose
an
identifier.
A
You
need
a
way
to
describe
the
things
that
you're
writing
policy
against
right
and
most
most
compute
providers.
Most
cloud
providers
have
their
own
identifiers.
Security
group
is
the
example
here,
but
the
only
problem
is
that
this
isn't
very
well
generalized,
it's
specific
to
that
cloud
provider.
If
you
ever
need
to
move
cloud
providers-
or
you
ever
turn
up
an
on-prem
anything
like
this,
it
will
fault
your
security
system
will
fall
apart.
A
If
you
face
yourself
on
primitives,
which
are
cloud
specific,
so
while
some
folks
do
it
and
it's
ok,
if
you'll
never
ever
move
it,
it's
kind
of
ill-advised
to
start
to
start
in
this
way,
but
going
up
one
level
we
have
IP
addresses
right
and
so
we're
getting
a
little
bit
closer
to
what
we're
looking
for
here,
because
IP
addresses
are
fairly
generalized.
They'll
they'll
apply
kind
of
across
the
board.
You
know,
and
most
projects
today
which
provide
this
network
security.
Automation
we're
talking
about
are
using
these
IP
based
ACLs.
A
If
they're
not
I
supposed
to
the
first
class
citizen,
they're
kind
of
going
on
under
the
covers,
you
know
you
may
use
one
thing,
but
then
there's
a
level
of
indirection
and
then
they're
still
IP
tables
rules
and
all
sorts
of
other
stuff
layer.
Three
and
therefore
policy
gets
instantiated
underneath
and
while
this
is
largely
a
good
thing,
it
doesn't
come
without
as
pains,
for
instance,
these
apples
that
you
build.
This
can
grow
quite
large,
thousands
or
tens
of
thousands
of
rules
now,
particularly
if
you're
doing,
host
post
based
browser.
A
You
know
/rd,
twos
and
you're
doing
we're
also
layer
for
stuff
select
this
port,
so
each
individual
host
may
have
you
know
tens
of
rules
applied
to
it
and
then
it's
also
kind
of
dependent
on
a
network
topology.
So
if
you
have
Matt
anywhere
you're
doing
any
kind
of
thing
like
this,
how
do
you
know
which
IP
address
translates
where
and
particularly
in
cloud
a
lot
of
this
stuff
is
out
of
your
control.
You
there's
not
a
whole
lot.
You
can
do
about
it.
A
So
on
that
note,
you
know
if
you
don't
control
the
network,
you
know
how
easy
is
it
to
trust
Network,
because
what
we're
talking
about
here,
after
all,
is
like
a
security
control
and
this
IP
guarantee
that
you
build
security
controls
around
is
a
really
weak
guarantee
and
manipulation
is
practically
undetectable
by
either
endpoint.
If
the
IP
address
has
changed
in
the
middle
or
something
has
happened,
you
don't
really
don't
really
know
so.
A
So
it's
hard
to
build
security
policies
accurately
describe
things
using
these
IP
addresses
and
you
basically
have
to
trust
the
network
to
do
the
right
thing
in
this
case
I'm.
So
putting
that
side
that
problem
aside
for
a
moment,
I
I,
do
think
we
should.
We
should
think
more
critically
about
these
identifiers
x'
that
we've
chosen
and
when
we
use
these
this
IP
layer,
3
layer,
4
identifiers.
What
what
are
we
actually
modeling
here,
right,
I,
think
realistically
or
a
modeling
host-to-host
interaction
right,
but
is
this
what
we
were
really
intending
to
do?
A
A
Kubernetes
does
an
ok
job
at
approximating
this
by
giving
one
IP
address
per
pod
right
and
again
we're
getting
kind
of
closer
to
what
we're
looking
for,
but
it's
still
a
fairly
weak
assertion.
One
IP
address
can
represent
many
things,
even
even
in
kubernetes
pod.
There
can
be
lots
of
things
running
in
that
pod
that
share
the
same
IP
address.
So
we
really
want
to
be
more
granular
about
this.
A
What
we
really
want
to
describe
is
not
host
a
host
communication,
the
process
to
process
communication
right
and
the
reality
is
that
we're
trying
to
describe
process
process
communication,
but
in
the
whole
time
we've
been
using
these
IP
based
ACLs
to
do
this
right,
and
so
what
I'm,
trying
to
kind
of
the
point
I'm
trying
to
drive
here
is
that
IP
addresses
are
really
really
bad
at
describing
particular
workloads
right.
It's
just
not
the
right,
not
the
right
thing,
but
going
back
to
the
identifiers
they
have
available
to
us.
A
We
can
kind
of
see
that
there's
one
missing
here.
So
how
do
you
identify
a
software
process,
particularly
in
this
brave
new
world,
of
highly
dynamic
heterogeneous
systems?
So
this
problem
is
known
as
the
worklet
identity
problem,
and
there
are
lots
of
folks
for
on
this
problem.
Kubernetes
SIG,
off
container
identity
working
group
was
working
on
this
problem.
The
ISTE
Oh
folks
are
working
on
this
problem
and,
of
course,
myself
and
the
rest
of
the
site.
Ill
folks
are
working
on
this
problem
and
that's
just
within
the
cloud
native
umbrella.
A
You
know
we're
all
working
together,
but
there
are
folks
outside
of
this
I'm
Road,
we're
also
working
on
this
problem
and
and
the
direction
that
we're
going
thus
far.
There's
only
one
thing
here.
A
kind
of
nuance
point
here
is
that
the
solutions
that
were
coming
up
with
are
largely
dependent
on
the
underlying
orchestration
systems.
A
So
what
we
end
up
with
is
these
different
software
platforms.
I
have
different
ideas
about
what
workload
identity
is
right.
The
worker
identity
that
you
get
from
kubernetes
is
a
fundamentally
different
identity
than
the
one
that
you
would
get
under
DCOs,
for
instance,
and
it
can
be
really
really
difficult
to
rectify
the
differences
between
these
identities
mobbin.
So
there
are.
A
There
are
tools
to
to
accomplish
these
things,
but
again,
they're
they're,
very
focused
on
on
their
particular
deployments
right
and
there's
a
result
of
that,
none
of
them
interoperate
with
each
other
and
furthermore,
none
of
them
are
super
robust,
either
because
at
the
end
of
the
day,
they're
kind
of
tangential
to
the
projects
which
host
them
right,
like
kubernetes,
is
looking
to
schedule
container.
So
it's
not
necessarily
looking
them
in
certificates
or
do
other
things
like
this
right.
So
the
result
is
not
only
interoperability
problems,
but
also
that
you
know
these
things
rarely
meet.
A
The
users
needs
because
they're
not
super
flexible
and
it's
just
kind
of
like
a
necessary
evil
that
must
be
written
into
this
project.
So
what
we
really
need
to
solve
this
problem
is
what
we
call
Universal
workload:
identity
right:
the
idea
that
a
workload
identity
which
can
be
understood
by
everyone
right
and
not
only
can
you
start
to
solve
authentication
problems
and
policy
problems
with
Universal
workload,
identity,
but
you
know
solve
other
problems
as
well:
tracing
metering
auditing.
A
All
these
things
become
a
whole
lot
easier
if
you
have
a
stable
identity
paradigm
that
can
apply
across
different
types
of
software
stacks
and
you
can
trace
requests
as
they
traverse
different
ecosystems,
and
so
it's
really
interesting
and
promising
so
enter
spiffy.
This
is
the
problem
that
spiffy
solves
right.
It's
it
workload,
identity
that
is
standardized.
It
is
on
level
playing
fields
that
will
work
across
different
software
stacks
right
and
really
at
its
core.
Spiffy
is
just
a
set
of
open
specifications
and
these
specifications
are
community
driven.
A
It's
not
something,
you
know,
Scytale
didn't
wake
up
one
day
and
say
we
need
to
write
a
spec
for
this
thing.
This
is.
This
is
a
bunch
of
folks
who
come
together
for
many
many
companies
to
kind
of
the
consensus
upon
this
is.
This
is
the
way
that
we
think
generalized
identity
should
look
at
act
and
breathe
right.
A
So
there
are
many
specifications
under
the
spiffy
umbrella.
Today
we're
going
to
talk
about
three
of
them.
The
first
one
outlines
what
we
call
a
spiffy
ID,
and
this
is
what
the
spiffy
ID
looks
like
it's
modeled
as
a
URI,
which
is
basically
just
a
structured
string
and
the
spec
isn't
too
prescriptive
about
how
you
model
this
thing.
How
you
compose
this
URI?
A
We
looked
at
many
different
document
types
in
this
process.
The
next
time
I
made
X
file
and
I
made
a
lot
of
sense
to
start
with,
for
a
lot
of
reasons.
First,
it's
widely
deployed.
Second,
is
widely
understood.
This
behavior
is
widely
understood
and,
and
finally
it's
a
model
that
just
works
well
for
the
specific
problem
space
in
general.
A
So
what
these
specifications
really
talk
about
is
how
to
encode
a
spliffy
ID
into
an
x.509
certificate,
specifically
like
which
fields
to
use
etc
and
how
to
validate
this
certificate
and
a
spliffy
ID
inside
of
it
so
with
spiffy,
IDs,
fib
defi,
and
we
can
start
to
begin
to
address
this
universal
identity
problem
right.
We
have
an
identity
format
and
a
document
which
is
generalized
on
cross-cutting
can
be
used
anywhere
regardless
of
the
underlying
software
platform.
A
But
there's
still
one
missing
piece
here,
which
is
a:
how
does
workload
identity
get
issued
in
the
first
place
right?
Where
does
this
s
fit
thing
come
from
and
to
answer
that
spiffy
has
another
specification,
called
the
workload
API
specification
and
the
workload
api
is
a
standardized
node
local
interface
right.
So
when
a
workload
first
starts
the
thing
it
will
contact
this
API
and
this
API
to
some
work
to
identify
the
caller
and
Unruh
turn
the
correct
estimates
to
it
right.
A
It
will
also
return
the
trust
bundles
at
the
same
time,
so
that
the
workload
knows
which
other
things
that
should
be
trusting,
and
at
this
point
the
workload
is
ready
to
serve
traffic
because
their
traffic
using
the
suspenders
been
issued
actually
and
so
standardizing
on
this
estimate,
but
not
just
the
esterday,
but
also
the
workload
api.
A
super
duper
valuable
thing,
because
what
it
does
is
it
ensures
that
identity
is
available
in
a
platform.
A
Agnostic
way
doesn't
matter
if
you're
running
on
Metro
or
AWS
or
TCP
or
whatever,
let
it
be
compliant
workloads
should
be
able
to
run
anywhere.
You
pick
it
up
and
drop
it
anywhere.
This
identity
will
be
available
right,
so
this
this
paves
the
way
for
truly
heterogeneous
infrastructure.
Okay,
so
clearly,
spiffy
compliance
is
a
pretty
powerful
thing,
but
you
might
be
asking
like
okay
now
like
what
exactly
do
I
need
to
do.
How
do
I
spiffy
this
thing
right?
A
What
exposes
this
workload
API
right?
How
do
these
estimates
get
minted
and
distributed
to
where
they
need
to
be
now?
So
this
is
where
spire
comes.
Own
spire
is
an
open-source
project
which
implements
the
spiffy
standards,
namely
it
exposes
this
workload
API
and
framework
for
s,
vid
management
management
of
issue
of
so
these
s,
feds
and
I
should
note
that
you
know
spiffy
is
as
I
mentioned
before.
Spiffy
is
only
a
set
of
specification,
so
anyone
can
make
a
spiffy
implementation
right
as
an
example
of
sto
implements
spiffy
right.
A
So
spire
is
just
one
implementation
and
different
than
some
other
implementations
in
spire
as
a
standalone
project,
which
is
focused
purely
on
this
problem
of
the
universal
identity,
and
it's
fairly
thoughtfully,
designed
with
a
extensive
plugin
system
which
allows
it
to
operate
in
all
these
different
environments.
Even
if
you
have
some
custom
through
in-house.
A
A
The
agent
is
responsible
for
exposing
this
workload.
Api
on
every
host
is
also
responsible
for
doing
what
we
set.
What
we
call
workload
at
to
station,
which
is
verifying
the
authenticity
of
the
caller
and
making
sure
that
it
is
who
we
think
it
is
spire
server,
is
responsible
for,
as
an
issuance
of
the
minting
of
these
certificates
is
responsible
for
node
attestation,
or
you
know,
measuring
the
authenticity
of
new
nodes
that
are
coming
online,
as
well
as
registering
these
identity.
A
Mappings,
basically
saying
you
know
who
should
get
what
stiffy
ID
right
and
to
demonstrate
how
this
kind
of
works?
It
I
think
it's
a
good
to
step
through
a
worked
example
of
this.
So
the
first
time,
of
course,
is
deploy.
Spire
server
can
run
pretty
much
anywhere
that
it
has
no
special
requirements
of
its
own
and
on
the
first
boot
it
generates
a
self-signed
certificate,
and
this
is
a
certificate
that
we'll
use
to
sign
s
vids
for
all
the
workloads
which
are
managed
underneath
this
particular
server.
A
A
At
the
same
time,
we
turn
on
this
registration
API
and
this
radio
station
API
is,
let's
use
to
configure
these
identity
mappings,
who
gets
what
essentially
and
these
properiy
we
in
order
to
make
that
mapping,
we
need
to
be
able
to
describe
a
workload
in
a
node
in
a
particular
way,
so
we
use
these
properties
properties.
We
call
selectors
are
natural
properties
of
the
nodes
and
the
workloads
that
we're
trying
to
describe
so
as
an
example.
This
is
one
register
what
we
call
registration
mapping.
A
So
this
is
saying
that
in
kubernetes,
cluster
foo
in
the
namespace
operations
and
the
service
account
MediaWiki
with
workloads
with
this
particular
docker
image.
Id
will
get
speci,
ID
op,
slash
with
you
right
and
since
this
is
an
API,
it's
really
easy
to
automate.
So
this
can
be
a
human
putting
this
information
in
or
you
can
have
automation
systems
which
are
kind
of
curating.
These
mappings
and
updating
these
mappings
those
things
change
in
your
environment.
A
So
as
soon
as
the
server
is
up,
it's
ready
to
take
on
agents
and
for
this
part
of
the
example
I
kind
of
have
to
choose
a
provider,
so
I
chose
AWS
and
the
server
doesn't
necessarily
have
to
run
in
AWS,
as
I
mentioned
before.
But
let's
say
we
turn
up.
Ec2
VM
and
the
first
thing
to
start
on.
Ec2
VM
will
generally
be
spire
agent
and
the
first
thing
that
the
agent
does
is
perform
what
we
call
no
data
station.
It
simply
stated
this
means
strongly
prove
that
I
am
a
valid
AWS
server.
A
A
So
the
agent
exercises
this
noted
tester
plug-in,
which
is
another
plug-in,
and
this
plug-in
is
platform
aware.
So
it
knows
how
to
speak
to
AWS
and
gather
the
necessary
proof
that
it
is
the
Machine
it
claims
to
be
right
and
so
for
AWS.
The
AWS
case
means
this
is
probably
an
instance
identity
document.
A
It
then
presents
this
instance,
identity
document
to
the
spire
server
and
it
uses.
Does
this
using
like
regular
server
verified
TLS?
If
there's
a
hardware
here,
this
might
be
a
TPM
quote
instead
of
a
instead
of
a
ID,
so
you
can
see
how
this
is
fairly
flexible.
You
can
change
different
types
of
documents
here,
mom
once
the
server
receives
this
proof,
it
has
to
validate
it
in
some
way
right.
So
in
our
case,
this
means
calling
the
AWS
API.
Now
an
additional
checks
can
be
done
at
this
time.
A
Like
I
said,
a
fresh
boot
was
the
was
the
Nick
and
the
hard
drive
just
attached
to
it.
Recently,
like
you
can,
depending
on
your
risk
profile,
you
can
look
up
all
these
different
properties
and
make
all
these
different
tracks
right.
So
the
ones
AWS
acknowledges
this.
You
know
you
know
that
the
aside
any
document
is
valid.
One
all
of
your
custom
checks
pass.
Finally,
an
s-video
fish
ood
to
the
agent
assessment
represents
the
identity
of
the
agent
itself,
and
everything
happening
after
this.
A
After
this,
no
data
station
has
been
completed
occurs
with
mutual
TLS
using
this
agent
identity
as
the
client
certificate.
So
at
this
point
aspire
agent
is
fully
blue
strapped,
and
the
next
similar
does
is
turn
on
workload.
Api
and
the
workload
API
is
accessible
by
any
process
on
the
node
and,
crucially,
perhaps
a
little
bit
counter-intuitively.
A
It's
actually
unauthenticated-
and
this
is
a
really
important
property
for
bootstrapping
trust,
because
otherwise
we'd
have
to
somehow
uncheck
credentials
into
this
workload,
and
it
turns
out
that
that's
kind
of
the
hard
part
right,
but
we
obviously
still
want
some
control.
We
don't
want
to
just
give
certificates
out
to
any
willy-nilly
process
to
ask
for
them
on
this
socket.
So,
instead
of
direct
authentication,
we
the
agent,
performs
this
out
of
band
process
interrogation,
which
enables
it
to
identify
and
verify
the
workload
authenticity
without
like
the
use
of
direct
credentials.
A
So,
for
instance,
let's
say
that
a
workload
calls
the
agent
socket
and
requests
a
nested
I'll
linux.
The
agent
will
interrogate
the
kernel
for
information
about
the
caller
all
right.
So
first,
it
will
figure
out.
What's
the
process
ID
of
this
thing,
which
is
calling
me
and
from
there
can
discover
many
many
other
properties,
things
like
UID
GID,
even
the
Shah
of
the
binary
which
was
running
and
these
properties
that
are
discovered
at
this
time
are
the
selectors
that
we
saw
in
a
previous
mapping
right
and
these
selectors
are
properties.
A
They
get
returned
to
us
from
another
plugin.
What
we
call
the
workload
a
tester
plug-in.
The
agent
supports
we're
gonna
test
our
plugins.
They
can
be
mixed
and
matched,
and
so,
when
the
call
comes
in,
we
fan
out
on
all
these
attestation
plugins
and
then
they
return
to
us
all
these
selectors
or
properties
about
the
thing
which
called
us
right
and
once
we
get
all
the
selectors
back,
we
can
consult
that
identity
mapping
in
the
server
and
say.
Ok.
A
We
now
know
that
this
is
the
s
vid
you
should
be
issued
or
you
are
not
are
not
authorized
to
have
this
particular
s
VIN,
so
the
selector,
as
I
mentioned
before
you
idgi,
D,
etc.
Those
are
coming
from
the
UNIX,
a
tester
right,
like
those
are
UNIX
primitives
that
we're
using
to
describe
the
process,
but
if
you're
using
kubernetes,
for
instance,
we
would
have
a
kubernetes,
a
tester
and
that
a
tester
or
speak
to
the
cube
load
right.
A
A
So
going
back
to
the
idea
of
trusted
third
party,
we
can
see
that
we
used
AWS
as
a
trusted
third
party
for
the
server
attestation
piece,
and
then
we
use
the
Linux
kernel
as
a
trusted.
Third
party
for
the
workload
attestation
piece
right
and
this
pattern
using
a
trusted
third
party
to
establish
trust
between
two
between
previously
untrusted
entities
is
a
problem
is
known
as
secure
introduction.
A
security
reduction
is
a
famously
challenging
problem.
Most
folks,
don't
even
know
that
this
problem
exists.
A
It's
really
easy
to
unlock
additional
support
for
platforms
by
writing
these
small
little
plugins
that
just
go
in
and
so
Dillo
talking
and
I
realize.
This
is
a
lot
of
sometimes
it's
kind
of
hard
to
hold
it
all
in
your
head
and
visualize
just
from
something
like
this,
so
I
actually
have
a
demo
prepared
to
show
you
all.
A
Okay,
so
this
is
I'm
right
here,
I'm
in
a
spiffy
example.
Repo.
Is
that
clear
enough
for
you
guys
in
the
back?
Can
you
all
see
this?
Okay?
No!
Is
that
better?
Okay,
so
this
is
the
spiffy
example
repo.
This
is
where
we
have
all
the
demo
code
check
them,
so
you
can
go
actually
and
run
this
demo
yourself,
so
we'll
be
working
out
of
this
repo
today
and
so
here's
a
diagram
of
what
this
demo
looks
like
and
I
know
I'm
sorry
in
the
back
of
probably
a
little
fuzzy,
but
all
up
through
it.
A
This
whole
demo
is
run
under
vagrants
essentially,
and
there
are
three
virtual
machines
in
this
demo:
the
top
right,
the
green
box.
Virtual
machine
is
the
kubernetes
master
vm.
This
is
gonna,
run
kubernetes
api
server,
it's
gonna
run
also
our
spire
server
on
the
bottom
right.
We
have
a
database
virtual
machine.
This
is
vagrant.
Vm
is
kind
of
meant
to
be
an
analog
of
a
bare
metal
host
right.
So
it's
ready
Mario
to
be
there
on
the
Left.
A
The
green
one
here
is
kubernetes
node
and
like
cubelet,
and
it's
running
a
pod
which
has
this
blog
slash
forum,
sort
of
application,
running
a
side
of
it,
and
you
can
see
we're
using
ghost
tunnel
here.
Ghost
tunnel
is
providing
the
mutually
authenticated
TLS
between
both
database
and
the
blog
application,
and
you
might
also
notice
this
little
sidecar
kind
of
box
here,
it's
a
little
bit
poorly
named,
but
this
is
just
a
small
bit
of
code
which
hits
that
workload
API
pulls
out
the
identity.
A
A
A
So
on
he.
What
you're
seeing
here
is
those
three
VMs.
Each
each
horizontal
row
is
a
single
VM,
so
the
top
the
top
row,
the
top
row
is
the
Cates
master.
This
running
API
server
will
run
the
aspire
server
they're.
The
middle
row
is
the
Kate's
node,
which
is
running
to
blitz
a
worker
node
and
the
bottom
row
is
the
database
host
alright.
A
So
the
first
thing
we
need
to
do
here
is
obviously
start
the
spire
server.
So
we
don't
have
a
lot
of
screen
real
estate
here.
So
I
hope
that
this
goes.
Okay,
we'll
see
so
just
fire
server
run
a
spider
server.
It's
not
running
in
here.
Okay,
so
now
it's
fire
server
is
running.
What
we
need
to
do
is
start
there.
First
agent
will
start
first
agent
on
database
host.
Now
we
talked
about
like
trusted
third
party
at
to
station
and
all
this
stuff.
A
We
don't
really
have
a
great
way
to
perform
this
automated
attestation
and
the
vagrant
environment
right
so
rather
than
automating
the
provider
base
attestation
we'll
use
human
as
trusted
third-party
here.
So
what
we're
gonna
do
is
well
tell
the
server
to
generate
that's
a
joined
token,
similar
to
the
way
docker
swarm
and
some
other
projects
work.
A
Okay,
so
we
see
that
the
agent
has
started,
and
it's
picked
up
this
spiffy
idea
of
a
DB
node
that
we
gave
to
it
is
kind
of
arbitrary,
just
something
to
get
the
demo
going.
So
now
that's
running
on
the
same
machine
over
here
on
the
right
hand,
side
what
I'll
do
is
we
have
this
script,
and
this
script
basically
just
starts
that
little
sidecar
code,
which
grabs
the
certs
and
then
also
starts
ghost
tunnel.
Okay,
so
I'll
run
this
real,
quick
just
to
kind
of
show
you
what
happens
here.
A
You
can
see
that
it's
actually
panicked
and
the
output
is
cut
zero,
bundles
and
that's
because
we
haven't
registered
this
particular
work.
Lidya
aspire
server.
Sorry
favor
doesn't
know
about
this
thing.
That's
not
entitle
to
any
identity
just
yet.
So
what
we
need
to
do
is
we
need
to
register
this
egg
so
that
I
can
get
it
certs
and
we'll
use
the
UNIX
a
tester
to
describe
this
particular
one
and
because
it's
running
under
my
user
account
here,
we
can
just
see
that
I
am
UID
1,000.
So
we
use
that
to
describe
this
particular
process.
A
A
A
When
I
call
it
database
okay,
so
you
can
see
that
it's
been
registered
here,
there's
a
unique
ID
for
it,
and
everything
like
that-
and
you
can
also
see
on
this
other
side
that
the
agent
has
now
picked
up
this
new,
just
new
identity
that
it
can
issue.
So
now,
if
we
go
back-
and
we
run
this
thing
again-
you
can
see
that
we
did
not
panic
and
we
actually
got
a
key
and
we
got
a
certificate.
And
now
ghost
tunnel
is
running.
So
if
I
actually
look
for
a
ghost
tunnel
here,
real
quick.
A
We're
gonna
see
that
we've
we
fired
it
to
say
that
you
should
only
be
allowing
spec
the
ID
of
blog
to
access
this
particular
database
right.
So
this
is
mutually
often
Aikido,
TLS
right.
So
now
this
thing
is
running.
We
need
to
start.
Do
the
same
thing.
We
need
to
start
the
agent
on
the
kubernetes
host,
so
we'll
generate
another
token,
except
we'll
call
it
tube.
Node
and
I
should
note
that
you
know
you
can
join
all
the
hosts
and
your
kubernetes
cluster
in
the
same
way.
So
they
all
have
a
similar
spiffy
idea.
A
Okay,
so
you
can
see
that
this
is.
It
looks
a
little
bit
different
than
the
last
one.
You
don't
see
that
these
logs
are
kind
of
rolling
over
right,
and
the
reason
that
this
is
happening
is
because
we
saw
that
sidecar
code
just
panics
if
there's
no
bundle
available.
So
for
the
purposes
of
this
demo,
what
we've
done
is
we've
thrown
that
sidecar
code
into
a
while
true
loop
inside
the
pod,
so
it's
just
hitting
waiting
for
an
identity
to
be
available
right.
So
now
we
need
an
inner.
A
We
haven't
registered
it
yet,
so
there
is
no
identity
for
it.
That's
why
it
rolls
over
like
this.
So
we
need
to
register
something
for
it
and
when
we
register
you
know,
we
don't
necessarily
want
to
register
it
using
these
UNIX
primitives
right.
We
want
to
describe
it
in
ways
the
kubernetes
understands
so
we'll
register
this
thing.
A
A
We'll
call
it
blog
okay,
so
now
you
can
see
this
has
been
registered
and
this
time
it
has
two
different
selectors
right.
So
these
are
compound
selectors.
Both
of
these
things
must
be
true
in
order
to
be
issued.
The
spiffy
ID
you'll
further
notice
that
this
log
is
stopped
rolling
over,
so
odd
identity
is
actually
been
issued
and
it's
been
picked
up
by
this
ghost
tunnel
and
if
we
look
forward
over
here,
oopsies.
A
Should
see
it
there,
it
is
so
it
is
running
and
similarly,
it's
running
a
verifying
the
spiffy
idea
of
the
route
and
there's
being
database,
the
PID
right.
So
now
that
these
tunnels
are
both
up,
we
should
be
ready
to
go
here
so
going
back
to
our
situation
here.
If
I
open
this
up,
hopefully
with
any
luck,
we'll
be
able
to
see
a
forum
application.
A
A
You
can
see
on
the
bottom
here
now
that
the
server
side
has
recognized.
It's
been
closed,
whoops
and
if
we
refresh
this
page
500,
so
that's
automatic
certificate
issuance
of
identity,
which
is
understood
both
by
kubernetes
and
by
a
bare-metal,
and
you
can
imagine
that
if
you
scope
these
lifetimes
down
you
can
you
can
really
really
easily
rotate
these
credentials
without
problem
right.
A
Okay,
so
this
is
almost
the
admin
submarine
kind
of
explored
the
value
of
universal
work,
fluid
identity.
What
you
can
get
with
it,
why
you
probably
need
it?
We
learned
about
the
spiffy
specs
themselves,
what
they
do
and
how
they
solve
this
universal
identity
problem,
and
we
also
learn
about
spire
a
problem.
It
solves
how
it
works.
I
saw
a
cute
little
demo
of
it.
Actually
in
action
and
looking
forward,
we
had
a
lot
of
exciting
things
for
for
spire
spiffy
project.
A
A
So,
if
you're
interested
in
any
of
this
stuff
at
all,
we'd
really
love
to
hear
from
you,
we
have
a
super
active
community
of
over
150
people
from
40
different
companies,
including
Google
Square
hep
tio,
are
all
actively
involved
in
this
project.
We
have
regular
special
interest
group
meetings
as
well,
which
are
open
to
the
public
so
you're
more
than
welcome
to
join.
A
We
have
a
bunch
of
github
repos,
which
are
also
available,
so
this
first
one,
the
spiffy,
the
spiffy
spiffy
repo,
is
where
the
specs
themselves
are
housed
and
we
also
have
all
the
community
information
there
too.
So
if
you
want
to
join
the
SIG's
or
anything
like
that,
this
is
a
repo
to
go
to
the
second
repo,
the
spire
repo.
This
is
where
both
agent
and
server
spire
codebase
live,
so
you
can
go
check
out
how
all
that
code
works
and
how
we
do
this
magic.
Finally,
the
third
one
is
spiffy
example.
A
This
is
the
one
that
we
did
the
DRAM
the
demo
out
of
today
and,
as
you
saw
us
fairly
well
automated,
so
you
can
visit
this
repo
and
you
can
go
run
this
demo
at
home.
Finally,
the
last
slack
thing
slack
is
also
public
and
where
they're
pretty
much
all
time
every
day.
So
if
you
ever
have
any
questions
or
comments
or
anything
like
that,
we
would
love
to
hear
from
you
and
our
slack
Channel
and
last
but
not
least,
we
have
a
drink
up
tonight
and
I
apologize
for
the
crazy
obnoxious
link.
A
Here,
that's
my
bad,
but
if
you'd
like
to
come,
we
would
love
to
it.
We
would
love
to
have
you,
so
this
is
a
really
exciting
time
for
spiffy
there's
a
lot
of
stuff
going
on,
and
we
think
this
is
a
really
really
important
problem.
Please
do
keep
an
eye
out
for
these
projects
because
we're
only
just
getting
started.
Thank
you.
Everyone.