►
From YouTube: SPIFFE Project Intro - Andrew Jessup & Emiliano Berenbaum, Scytale, Inc. (Any Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
SPIFFE Project Intro - Andrew Jessup & Emiliano Berenbaum, Scytale, Inc. (Any Skill Level)
Join SPIFFE and SPIRE contributors for an overview of the newest project to join the CNCF. Modern software development relies on many microservices working together, that in production may be distributed over different middleware systems, container schedulers, PaaS platforms and even different cloud providers. As production environments become more complex, and dynamic - establishing trust between microservices is becomes more difficult, creating challenges for developers, operations teams, and security teams alike. Enter SPIFFE (Secure Production Infrastructure for Everyone) and which builds on designs first championed at Google, Twitter and elsewhere to provide robust authentication and trust between disparate micro-services. SPIFFE and SPIRE make it trivial to establish trust between workloads that may be elastically scaled and dynamically scheduled, and deployed in deeply heterogenous environments. We'll walk through the design goals for SPIFFE (a specification) and SPIRE (a multi-cloud implementation of SPIFFE), an overview of SPIRE's modular architecture, and an overview of how it can be used in conjunction with other tools such as secret stores and service meshes to build secure and scalable microservice architectures.
About Andrew
Andrew is the co-founder of Scytale, who are helping bring SPIFFE into the world. Find out more at https://github.com/spiffe/spiffe Andrew is an engineer, and entrepreneur with a passion for building tools that help bring simplicity to software development. Prior to co-founding Scytale, Andrew was a product manager on Google’s Cloud Platform, launching many of the automation primitives on Google Compute Engine (including Auto-scaling, Managed Instance Groups, and Deployment Manager), helping improve developer workflow with the Spinnaker and Container Builder projects, and helping improve accessibility to developers and operations teams. As an Australian in the San Francisco Bay Area, Andrew spends most of his spare time trying to sell his Midwestern wife on the virtues of Vegemite.
About Emiliano
Emiliano is the CTO at Scytale, Inc.
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
A
We
we
also
have
another
session
on
tomorrow
the
spiffy,
deep
dive,
where
we're
going
to
take
some
of
the
ideas
that
we
talk
about
at
a
very
hand,
wavy
conceptual
graphical
level
and
dive
into
the
meat
of
how
they
actually
work,
and
so
my
colleague
Emiliano,
along
with
a
couple
of
friends
of
ours
from
VMware,
are
going
to
run
that
so
I'd
encourage
folks
who
find
this
interesting
and
want
to
get
to
the
meat
of
it.
If
we
don't
get
to
your
questions
later,
please
do
please
do
get
involve
there
as
well.
A
There's
a
few
other
events
as
well,
a
few
panels
and
things
like
that
and
then,
of
course
we're
all
on
slack
and
github,
so
to
jump
into
spiffy.
So
spiffy
is
fundamentally
solving
for
the
problem
of
trust
between
workloads
and
by
workloads.
We
really
is
a
general
term
we
use
for
any
software
system.
You
might
also
use
the
word
service,
which
is
also
kind
of
an
overloaded
term,
but
fundamentally
we're
trying
to
solve
for
trust
and
by
that
by
trust.
A
What
is
a
new
problem,
though,
or
is
becoming
increasingly
a
more
acute
problem,
is,
is
really
twofold.
One
of
them
is
just
simply
the
number
of
workloads
that
need
to
establish
trust
between
each
other
in
order
to
deliver
some
kind
of,
let's
call
it
customer
experience,
and
this
is
kind
of
a
contrived
piece
of
market
texture.
But
you
get
the
idea
when
people
start
throwing
around
words
like
micro
services
and
or
service
orientated
architecture.
A
What
that
means
in
practice
is
that
you
have
a
number
of
discreet,
independent,
running
processes
that
are
connected
over
a
network
that
need
to
be
able
to
trust
each
other.
The
number
of
these
things
is
growing
as
an
industry
we're
starting
to
build
more
and
more
and
build
more
maturity
and
practice
and
tooling
around
taking
monolithic
applications
that
just
shared
memory
and
breaking
them
out
into
these
different
components.
So
we
have
more
things
that
need
to
trust
each
other.
A
For
one
thing,
the
other
thing
that's
something
of
an
emerging
trend
over
the
last,
maybe
five
years
or
so
has
been
the
heterogeneity
that
we're
starting
to
deploy
these
systems
into
no
longer.
Are
they
just
running
in
a
data
center
somewhere
where
the
hardware
has
been
spectin
fitted
out
by
a
single
team?
Now,
maybe
some
of
my
solutions
running
in
one
cloud
provider,
some
of
my
solution
is
still
running
on
premise.
A
Maybe
some
other
part
of
my
solution
is
running
on
another
cloud
provider
when
I
used
to
work
at
Google
as
a
product
manager
at
Google,
I
saw
more
and
more
I
saw
this
becoming
an
increasing
problem
rather
than
a
decreasing
problem.
The
heterogeneity
of
infrastructure
is
becoming
a
real
challenge,
the
other
dimension
of
heterogeneity.
That's
often
a
challenge
is
than
the
middleware
layer.
The
number
of
different
systems
I
can
use
to
manage
these
running
workloads.
Now
that
might
be
a
you
know:
I
container
shed,
yellow
like
kubernetes.
A
It
might
be
a
pass
system
built
on
top
of
a
container
scheduler.
It
might
be
something
independent
like
say:
Cloud
Foundry.
It
may
be
JBoss
or
WebSphere
or
something
you've
rolled
yourself.
But
again
you
have
this
rich
diversity
of
different
ways.
You
can
run
systems
and
when
most
and
when
you
build
a
project
in
isolation,
maybe
you'll
just
pick
one
of
these
for
the
case
of
simplicity,
but
when
you
have
legacy
and
when
you
have
for
that
matter,
just
different
teams
operating
independently.
They
may
all
make
different
technology
choices.
A
Even
if
you
standardize
on
something
like
say
kubernetes
you
may
well
have.
May
well
even
desire
to
have
multiple
kubernetes
clusters,
either
for
availability
or
for
isolation
or
for
some
other
reason
so
either
way
we
also
have
heterogeneity
at
the
middleware
layer
and
then,
of
course,
people
pick
and
choose
their
own
stacks
for
actually
doing
or
thin
and
Odyssey
and
so
forth.
A
Then.
Finally,
we
have
third
party
ap.
Is
you
know,
as
we
as
we
start
to
see
these
rich
services
that
provide
third
party
infrastructure?
Things
like
you
know
whether
that's
something
as
transactional
or
sending
an
email
or
something
more
robust,
like
say,
invoice
management?
We
start
to
farm
out
a
lot
of
our
workloads
to
third
party
systems
where
we
have
no
idea
what
the
infrastructure
is
that
they're
running
on.
So
this
is
kind
of
the
world.
A
The
first
is
what
I
might
consider
kind
of
classical
trust
management
or
classical
for
that
matter,
authentication
and
I've
kind
of
crudely,
generalized
here
Morais,
every
shared
secret
form
of
authentication
that
you
can
manage,
but
it
basically
works
the
same
way
you
have
a
destination
workload
has
some
concept
of
identities
for
the
cysts
for
the
sauce
workloads
that
want
to
connect
to
it
might
be
a
registry
of
accounts.
A
concrete
example
might
be
I'm
running
a
my
sequel
database
and
I.
A
Have
my
sequel,
usernames
and
passwords
that
are
stored
in
a
table
in
that
database
and
then
I
I.
Send
that
I
then
create
an
accounts
to
represent
my
source
work
load
I.
Take
that
credential
I,
give
it
to
the
source
work
load.
The
source
work
load
then
uses
that
to
authenticate
as
part
of
a
handshake,
so
that
hopefully
looks
in
abstract
fairly
familiar
to
you
in
some
form.
There's
a
couple
of
problems
with
this
model,
though,
for
one
we
need
to
fit,
we
need
it's.
It
doesn't
really
eat
itself
well
to
being
automatable.
A
We
need
to
create
these
accounts
for
one
thing
and
the
way
you
create
these
accounts
is
different
for
every
different
system,
because
it
has
a
different
author
and
all
three
model.
You
then
need
to
distribute
these
secrets
or
the
the
the
token
for
these
secrets
and
the
identity
metadata
over
to
the
source
workload,
so
that
can
actually
authenticate
and
then
you
need
to
and
and
we
need
to
figure
out,
a
distribution
system-
that's
robust.
A
We
also
need
to
figure
out
how
to
rotate
these
things.
You
know
to
constantly
manage
them
and
there
are
a
number
of
secret
stores
and
other
products
that
do
a
great
job
of
maintaining
secret
credentials
on
your
behalf,
and
they
can
dynamically
in
some
cases,
dynamically
create
accounts
and
dynamically
rotate
them
for
you,
but
even
with
secret
stores,
you
have
a
problem
which
is
the
secure
introduction
problem
or
the
trust
bootstrapping
problem,
which
is
how
does
your
workload
actually
connect
to
the
secret
store
in
the
first
place,
to
authenticate
itself?
It's
using
a
token.
A
A
Instead,
this
platform
mediated
privileged
API
is
able
to
say
well,
we
we
have
some
existing
concept
of
who
you
are,
if
you're
running
an
AWS
or
say
an
ec2
instance,
for
example.
Well,
we
know
what
security
group
you
in
we
know
what
I
am
roles
you
might
have
associated
with
you.
So
we
already
know
we
have
some
concept
of
identity
for
you
already
and
we
can.
We
can
allow
you
to.
A
We
know
that
you
are
they
caller
requesting
that
identity,
so
we
can
retrieve
for
you,
your
specific
identity
and
the
documents
that
you
might
need
to
prove
that
likewise,
a
remote
API
is
able
to
verify
those
documents
or
verify
key
or
verify
say
a
nonce.
That's
been
encrypted
using
those
documents,
so
a
destination
workload
is
also
able
to
to
lean
in
this
with
this
as
well,
and
this
is
a
much
more
preferable
model
for
several
reasons
for
one
of
it
is
its
API
driven.
So
it's
it's
much
more
amenable
to
automation.
A
Another
nice
property
of
this
API
is
that
every
identity
is
that
you
have
one
identity
per
workload
effectively,
so
rather
than
the
former
model,
where
you
might
have
where,
as
a
workload,
I
need
multiple
different
identities
for
every
other
workload.
That
I'm
gonna
need
to
talk
to.
I
need
I
need
to
identify
myself
to
an
API
I
need
to
identify
myself
to
a
database.
I
need
to
identify
myself
to
my
queuing
system
with
this
model.
Instead,
I
have
one
identity,
which
is
me,
and
then
I
can
prove
that
identity
asserted
to
anyone
else.
A
That
I
need
to
talk
to
and
then
that
other
system
can
make
a
decision
based
on
that
identity
as
to
whether
or
not
it
wants
to
actually
allow
a
connection
or
allow
me
to
perform
some
action.
So
this
is
a
really
nice
model
conceptually.
It
has
one
problem,
though,
which
is
that
it
requires
every
workload
to
be
running
on
that
platform,
or
at
least
every
source
workload
to
be
running
on
that
platform.
A
Business
call
one-on-one
shot
on
the
the
strengths
of
spiffy
as
a
system,
we're
trying
to
have
our
cake
and
eat
it
to
to
a
certain
extent,
in
terms
of
a
reliable,
primitive
to
build
authentication
on
top
of,
but
that
it
does
not
require
us
to
lock
into
a
single
platform.
So
when
we
talk
about
spiffy,
we
actually
talked
about
two
projects.
Spiffy
itself
really
refers
now
to
a
specification
in
a
particular
specification
for
this
work,
with
an
API
and
I'm
going
to
talk
about
some
of
the
components
for
that.
A
A
second,
the
other
project
we
talk
about
is
spire
the
spiffy
runtime
environment,
which
is
the
software
that
actually
implements
that
specification.
That
allows
you
to
use
it
yourself
fairly
early
on
in
the
project.
We
recognized
the
benefits
of
actually
separating
these
as
concerns
that
there
may
be
multiple
providers
that
implement
the
spiffy
interface.
It
may
even
be
cloud
providers
at
some
point
start
to
implement.
This
spire
is
one
implementation
that
you
can
use
and
in
fact,
something
that
we
won't
get
too
much
time
to
talk
about
today.
A
But
this
this
is
spiffy
inspires
kind
of
the
core
of
the
project,
so
the
spiffy
specifications
are
covered
in
detail
three
things.
The
first
is
the
format
of
an
ID
itself,
which
is
really
a
string
and
an
ID.
You
know
a
string
format
sounds
boring,
but
it's
important,
the
the
spiffy
ID
it's
it's
a.
You
probably
recognize
this
format.
Broadly,
it's
a
URI
and
there's
two
really
important
parts
of
this
URI.
A
The
first
is
what
we
call
a
trust
domain,
a
trust
domain,
effectively
maps
to
the
the
identity
issuing
infrastructure,
so
every
spire
installation
corresponds
to
a
trust.
Amin
trust
domains
can
be
hierarchical,
much
as
much
as
domain
names
can
be
and
if
you've
ever
worked
with
PKI
and
you've
worked
with
kind
of
named
constraint
delegated
certificates,
you
can
do
the
same.
You
can
you
can
lean
on
similar
properties
with
with
spiffy
as
well.
The
other
piece
of
this
is
the
workload
identifier.
A
So
once
we
have
a
trust
domaine
now,
I
I
need
to
identify
specific
workloads
inside
it,
and
this
is
you
know,
looks
a
lot
like
and
behaves
a
lot
like
a
file
path.
Spiffy
itself
just
treats
this
as
an
opaque
string.
It
doesn't
really
reason
about
hierarchy
or
anything
like
that,
but
you
can.
You
can
implement
hierarchy
if
you
want
to
say
for
for
a
chling
rules
and
policy.
A
So
once
you
have
this
string,
then
we
need
a
way
of
for
a
workload
to
be
able
to
prove
that
in
that,
in
fact
has
Bob
to
provide
proof
of
possession
to
prove
that
it
is
entitled
and
has
claimed
on
this
particular
spiffy
ID,
and
so
for
that
we
use
the
what
we
call
the
spiffy
verifiable
identity
document.
This
is
actually
a
fairly
generic
idea
over
time.
We
expect
multiple
different
formats
of
estimates.
A
For
now,
though,
the
spiffy
there's
we
have
a,
we
specify
a
particular
flavor
of
the
spiffy
verifiable
identity
document
which,
from
now
on
I'm
gonna
call
s
vid
as
a
particular
flavor
of
the
Esprit
called
the
x.509
s,
vid,
that's
based
on
x.509
certificates.
Basically,
what
we've
done
is
taken
the
x.509
spec
and
provide
and
worked
out
a
robust
but
meaningfully
for
a
size,
subset
of
that
that's
used
to
encode
spiffy
IDs
inside
certificates
and
provide
keys
that
can
be
used
to
assert
that
and
crucially,
you
know
we.
A
We
expect
these
documents
to
typically
be
short-lived,
and
it's
feasible
for
us
to
do
that
in
part,
because
these
things
are
API
driven.
There
are
other
formats
of
espied
we're
looking
at
such
as
you
know,
one
based
on
jot,
for
example,
in
cases
where
you
want
a
document
format
that
might
survive.
You
know
layer
7,
but
generally
speaking,
these
are
the
documents
that
the
API
provides,
and
then
we
have
the
workload
API
itself.
The
workload
API
runs
is
available
to
every
workload
that
needs
it
inside.
A
spiffy
a
set
of
spiffy
enabled
workloads.
A
If
you
will,
the
workload
API
is
node
local,
it
doesn't
require
any
authentication,
and
this
is
actually
crucial,
because
the
core
problem
we're
solving
for
is
trust
bootstrapping.
So
if
we
required
you
to
provide
some
kind
of
API
key
to
authenticate,
the
spiffy
would
somewhat
defeat
the
whole
purpose.
So
this
workload
is
node
local
in
practice.
A
In
UNIX,
it's
exposed
via
a
UNIX
domain,
socket
we're
looking
at
other
ways
of
exposing
it
as
well
and
a
workload
when
it
wants
to
retrieve
its
identity
when
it
wakes
up
and
wants
to
know
who
it
is,
it
doesn't
need
any
a
priori
knowledge
of
who
it
is.
It
doesn't
need
to
know
if
it's
running
in
kubernetes
on
Azure.
It
doesn't
need
to
know
if
it's
running
on
Prem
in
jboss,
it
doesn't
need
to
know
if
it's
in
staging
or
production
or
development
it
can
it
can.
A
It
can
ask
this
of
the
system
itself,
so
it
does
this
by
calling
a
workload
API
the
workload
API,
the
infrastructure
behind
it
is
then
responsible
for
figuring
out
who
this
workload
is.
In
the
case
of
a
cloud
platform,
it
might
already
know
who
this
workload
is,
because
it's
already
got
metadata
from
its
control
plane
to
figure
that
out
in
the
case
of
spire,
we'll
talk
a
little
bit
about
the
mechanics
of
how
this
works
in
a
second,
but
it
makes
a
Who
am
I,
call
the
workload
API
attests.
A
This
workload
verifies
who
it
is
and
once
if
it,
if
it's
fine
a
if
it
can
identify
this
workload,
it
will
retreat.
It
will
send
it
both
back
the
spiffy
ID
and
then
also
these
short-lived
documents
that
it
can
use
the
keys.
It
can
use
to
prove
that
identity
to
other
systems
and
also
a
what
we
call
a
certificate
bundle,
a
set
of
certificates
that
allows
it
to
verify
the
identities
of
any
other
running
workload.
That's
been
suitably
spiffy
enabled
as
well,
and
these
are
just
x.509
certificates.
A
A
I'll
talk
a
little
bit
more
about
some
of
the
use
cases,
we're
seeing
out
of
spite
spiffy
inspire
in
a
moment,
but
I
I
wanted
a
sec
to
talk
about
how
spire
actually
works
because
I
think
that's
a
useful
exercise.
So
spire
is
composed
of
an
agent
and
a
server.
The
agent
runs
on
every
node
inside
your
infrastructure,
again
its
node
local,
and
this
is
what
exposes
the
workload
API.
A
The
registry
that
it
contains
you
know,
contains
metadata
that
looks
I'm
simplifying
a
little
here,
but
it
looks
a
little
bit
like
this.
You
have,
firstly,
the
ID
that
you
want
issued,
and
then
you
have
a
set
of
selectors
that
define
the
conditions
that
a
workload
must
match
in
order
to
be
granted
that
identity
and
there's
a
number
of
different
spire
is
extremely
modular.
So
there's
a
number
of
different
mechanisms.
A
You
can
use
to
describe
a
workload,
but
typically
you
would
do
it
in
with
with
at
least
two
forms
of
selector
one
at
the
infrastructure
level
and
then
one
at
the
workload
or
middleware
level.
So
the
infrastructure
level
might
be
in
this
case
we're
saying
the
billing
payments
service
of
Acme
com
must
be
running
in
this
particular
security
group
within
AWS,
but
you
could
use
other
mechanisms
there
as
well.
It
might
be
a
particular
network
policy
or
a
particular
label
inside
other
constructs
like
say
VMware.
A
You
might
use
other
ways
of
describing
the
set
of
virtual
machines,
the
set
of
nodes
that
comprise
the
workload,
but
that's
often
not
enough.
You
know,
particularly
when
we're
talking
about
kubernetes,
and
we
may
have
a
cluster
with
multiple
different
workloads
running
on
it.
It's
important
for
us
to
be
able
to
distinguish
beyond
the
node
level.
What
a
you
know
what
constitutes
a
workload,
and
so
therefore
we
need
no
workload
level
selectors
in
this
case,
we
have
a
very
simple
example,
which
is
the
workload,
must
also
have
the
UNIX
UID
of
1001.
A
A
So
now
I'm
going
to
work
through
a
contrived
example
of
how
a
workload
when
it
wakes
up
actually
retrieves
an
identity
so
and
in
this
case
we're
going
to
assume
we're
going
to
assume
basically
the
the
set
that
we
talked
about
before
our
workload
running
in
a
particular
security
group
inside
AWS,
and
that
is
also
running
as
a
particular
UNIX
process.
So
for
those
who
aren't
necessarily
familiar
with
AWS
or
UNIX
I'm,
going
to
ask
you
to
squint
a
little
bit
with
some
of
the
detail
here,
but
this
is
just
a
work
example.
A
So,
first
of
all,
we
have
a
workload
running
on
an
ec2
instance.
It's
this
billing
service.
The
ec2
instance
is
booted
for
the
first
time
and
running
on
the
cc2
instance,
as
well
as
the
workload
is
this
spire
agent
running
as
a
daemon,
this
Meier
agent
wakes
up
and
the
first
thing
it
needs
to
do-
is
authenticate
itself
to
the
spire
server.
The
way
it
does.
A
The
the
ECE
process
running
on
the
ec2
instance
can
retrieve
this
without
again
any
authentication
and
they
can
provide
it
to
the
spire
and
it
can
provide
it
to
another
process
in
order
to
assert
that
this
instance
is,
in
fact
the
instance,
it
claims
to
be
so.
We
use
this
in
the
handshake
to
the
spire
server
we
pass.
We
pass
this
document.
The
spire
server
is
they
unable
to
verify
it
with
Amazon's
public
key.
It's
then
also
able
to
look
up
back
into
Amazon
and
retrieve
additional
metadata
about
this
workload.
A
At
this
point,
the
workload
doesn't
know
anything
by
the
way.
So
now
the
workload
wakes
up,
the
workload
wants
to
know
who
it
is
so
it
makes
its.
Who
am?
I
call
to
the
local
workload
API,
which
is
provided
by
the
spire
agent.
The
spire
agent
needs
to
figure
out
who
this
workload
is.
We
expose
this
workload
API
as
a
UNIX
domain
socket,
which
means
that
we
can
retrieve
metadata
from
the
kernel
to
figure
out
who
this
workload
is
again.
A
The
spire
agent
can
also
then
go
and
look
up
against,
say
the
couplet
to
cross-reference
and
say:
hey
cubed
is
this:
does
this
PID
a
correspond
to
a
workload
that
you
scheduled
on
this
node
and
if
so,
can
you
tell
us
a
bit
about
it,
given
me
a
pots
back
foreign
and
so
forth?
So
what
collects
all
of
this
data
about
the
workload
and
then
again,
it
goes
through
its
list
of
attestation
policies
and
finds
the
list
of
identities,
and
hopefully
there's
only
one
the
correspond
to
this
workload.
A
If
it
finds
one,
then
the
first
thing
it
will
do
is
it'll
generate
the
key
for
that
workload
on
that
node,
and
this
is
actually
a
pretty
important
property
of
spire.
The
key
material
for
this
workload
never
should
leave
this
node
so
generates
a
key
and
then
sends
a
certificate.
Signing
request
back
to
the
spire
server
saying:
hey
I've
got
a
I've
got
an
identity.
I've
got
a
have
an
identity.
I
have
a
I
know
that
it's
meant
to
be
running
on
this
node.
A
Please
issue
a
so
please
issue
certificates
to
every
other
identity
so
that
they
can
prove
so
that
we
can
associate
this
key
with
that
ID.
So
it
sends
a
CSR
of
the
spire
server.
That's
by
a
server,
make
sure
that
this.
Yes,
we
do
expect
this
workload
to
exist
on
this
machine
and
it'll
and
it'll
issue
to
both
back
to
the
original
workload
and
to
every
other
workload.
The
certificate
that's
necessary
to
verify
it
and
then
finally,
the
workload
API
will
wrap
all
of
this
up
and
deliver
this
material
to
the
workload
itself.
A
So,
as
I
said,
this
is
basically
the
spire
authentication
mechanism.
In
a
nutshell,
one
thing
that
I
have,
in
this
case
I've
provided
a
contrived
example,
but
one
really
important
point
about
spire
is
it's
extremely
modular,
so
it
supports
a
number
of
different
attestation
mechanisms
via
a
plug-in
model
and
through
that
a
number
of
different
selectors,
so
selectors,
maybe
in
terms
of
infrastructure
concepts.
It
might
also
be
in
terms
of
kubernetes
concepts.
A
You
might
also
say,
for
example,
that
a
particular
doc,
a
a
the
workload,
must
also
correspond
to
a
particular
docker
image
or
have
been
started
from
a
particular
docker
image,
with
a
particular
content
char,
for
example.
So
in
terms
of
use
cases
for
for
spiffy
inspire,
you
know
we're
starting
to
see
quite
a
few.
A
very
key
one
actually
is
secure,
introduction
to
secrets
doors,
be
they
things
like
vaults.
A
Pinterest
have
started
using
this
for
security
action
to
know
because
it
solves
quite
nicely
for
the
biggest
problem,
with
secret
stores,
which
is
the
secure
introduction
problem,
some
we're
starting
to
see
integration
into
some
low-level
libraries
that
perform
authentication
again.
You
know
by
hooking
directly
into
the
workload
API
you
can
avoid
a
lot
of
the
nastiness
involved
in
generating
PKI
and
delivering
it
to
nodes
and
and
the
significant
nuance
involved
if
you
want
to
automatically
rotate
those
keys,
really
interesting
use
cases
for
proxies.
A
You
know
having,
rather
than
necessarily
building
all
of
this
into
existing
software
systems,
use
a
proxy
as
an
ambassador
and
have
that
proxy
call
into
the
workload
API
to
retrieve
the
identity
of
the
workload
and
the
key
material
to
prove
it
and
use
that
to
establish
trust
between
trusts
to
another
workload.
Another
use
case
that
we
haven't
seen
a
ton
of
use
of
yet,
but
we
think
is
a
really
compelling
use
case.
Perspire
is
actually
simplifying
the
simplifying
the
bootstrapping
of
existing
distributed
systems.
A
Things
like
kubernetes,
although
Kuban
is
now
has
a
few
projects
to
solve
for
this
projects
like
hadoop
projects
like
chef
and
puppet
and
so
forth,
where
you
also
have
these
distributed
systems
where
you
have
different
nodes
with
different
roles
that
need
to
be
able
to
establish
material
to
them.
If
you've
ever
tried,
if
you've
ever
followed,
Kelsi
Hightower's
cubing,
it
is
the
hard
way.
A
You'll
know
you
spend
the
first
four
or
five
months
of
following
their
tutorial
setting
up
PKI,
so
there's
potentially
a
role
for
something
like
spire
to
help
I'll
help
with
that
significantly
we're
trying
to
build.
Basically,
though,
two
communities
in
this
one
of
them
is
the
community
of
projects
that
are
starting
to
adopt
the
spiffy
workload
API,
to
simplify
authentication
and
to
simplify
trust
establishment.
An
equally
important
community
is
the
community
around
spire,
both
getting
it
in
place,
helping
to
build
it
out
and
making
it
more
robust
and
contributing
components
to
it
again.
A
A
Another
thing
we're
working
on
is
a
security
audit.
That's
due
in
the
next
couple
of
months,
I
think
it's
alright
Justin
yeah!
You
know.
Ultimately,
this
is
a
security
product,
so
having
a
good
understanding
of
what
the
threat
model
is
best
practices
for
implementing
and
and
and
what
spiffy
doesn't
solve
for
as
much
as
what
it
does
solve
for
is
particularly
important,
and
so
you
know,
we've
wanted
to
make
sure
that
we
have.
A
You
know
good
visibility
and
a
certain
a
certain
position
from
the
community
on
where
and
how
you
should
be
able
to
trust
spiffy
and
for
that
matter,
to
help
us
understand
our
roadmap.
So
we
should
be
I
think
in
the
next
couple
of
months.
We
should
be
having
some
some
more
public
discussion
about
that.
A
It's
and
actually
that's
a
good
segue
into
what
spiffy
isn't,
because
this
is
often
misunderstood.
Spiffy
is
about
identity.
You
could
argue
spiffiest
to
a
certain
extent
about
authentication
what
it
is
not
is
about
authorization.
Spiffy
will
tell
you
who
you're
talking
to
it,
won't
tell
you
if
you
should
that's
authorization
and
that's
a
policy
decision
that
you
can
implement
separately.
The
good
news
is,
there's
a
bunch
of
very
interesting
projects
that
are
starting
to
tackle
that
in
a
meaningful
way
and
there's
plenty
of
different
protocols
for
mediating
authorization
are
several
different
proxies.
A
As
you
know,
and
then
there
are
a
number
of
different
policy
engines
that
are
starting
to
provide
a
way
of
of
taking
the
configuration
for
these
things
and
rolling
them
up
in
a
useful
way.
So
there's
a
lot
of
good
work
happening
there.
We
see
spiffy
airs
very
much
a
fundamental
pillar
upon
which
systems
can
be
built.
The
other
thing
it's
not
it's,
not
transport
level
security
spiffy
will
give
you
IDs
it'll,
give
you
documents
to
prove
those
IDs,
but
it
doesn't
actually
mitigate
a
connection
for
you.
A
It
doesn't
reason
about
the
IP
address
that
a
remote
workload
is
running
on.
It
doesn't
reason
about
how
to
negotiate
a
connection
to
that.
That
is
left
to
the
protocols
themselves.
Again.
Good
news
is
there's
plenty
of
prior
out
there
that
we
can
lean
on
already,
so
you
can
use
x.509
certificates
generated
by
spiffy
to
mimic
to
establish
a
TLS
connection.
You
can
use
them
to
sign
a
jot
token,
and
you
know
we
hope
to
see
again
more
and
more
projects
aligned
around
that,
but
fundamentally
spiffy
is
about
identity.
A
A
We
haven't
talked
about
that
much
yet
there's
a
number
of
interesting
design
patterns
coming
out.
We
had
a
talk
earlier
today
about
a
design
pattern
whereby
spiffy
can
be
used
with
vault
or
for
that
matter,
any
robust
secret
store
to
be
able
to
act
as
an
identity,
translation
layer
for
projects
that
aren't
necessarily
sniffing
away
yet,
like
a
database
for
example,
and
provide
you
know
richer.
Echoing
policies,
you
know
service
meshes.
Obviously,
I'm
gonna
call
it
a
design
pattern.
A
Another
piece
that
we
will
totally
talk
about
later
at
some
point
is
Federation
again
this
ability
to
be
able
to
take
multiple
spiffy
compliant
pieces
of
infrastructure
and
have
them
peer
with
each
other
and
establish
mutual
trust.
Even
though
the
identity
providers
are
logically
distinct
pieces
of
infrastructure-
and
we
did
talk
about
the
security
order
this
time,
but
there'll
be
more
details
coming
later.
So
we'll
take
some
questions
in
a
second
but
I'll
close
out
on
saying.
A
We've
got
as
well
as
the
deep
dive
tomorrow
and
as
well
as
several
panels
going
on
throughout
the
week.
We
also
have.
We
also
have
a
great
community
online,
so
I'd
encourage
folks
who
are
interested
in
this
problem,
space
to
jump
on
slack,
get
involved
in
the
community
and,
of
course,
find
the
code
on
github
and
get
involved
there
as
well,
and
thank
you
good
that
all.
A
B
A
A
A
Yeah,
certainly
so
the
question
was:
how
does
this
apply
to
service
and
we're
still
working
through
some
design
patterns
there?
To
be
honest,
one
of
them
is,
you
have
very
fat
client
libraries
that
do
a
lot
of
the
work
of
the
spire
agent,
which
is
a
model
that
works,
but
it's
not
a
great
model.
Another
one
is
that
you
have.
You
know
an
ambassador
proxy
that
you're
able
to
establish
trust
from
the
service
component
to
there's
a
project
called
glue,
I.
Think
Glu,
you
that's
starting
to
do
that.
The
other
model,
the
ideal.
A
D
E
D
A
Exactly
right,
we
so
that
the
example
we
gave
you
is
for
a
workload
running
on
Amazon,
but
it
is.
There
are
multiple
ways
to
do
it
and
it
is
extremely
extensible.
So
if
you're
running
in
Google
Cloud,
for
example,
you
could
use
the
the
GCE
instance
metadata
API,
which
provides
a
an
equivalent
but
different
document.
Another
model
is,
if
you
have
say,
TPMS
or
HSMs
you
can.
You
can
have
a
you,
can
lean
into
the
TPM
and
sign
a
nonce
and
use
that
to
establish
trust.
A
If
you
have
Kerberos
that
you've
already
used
to
establish
trust.
If
you
have
met
these,
you
can
lean
on
a
Kerberos
ticket.
If
you
like,
and
then
you
can,
you
can
use
manual
join
tokens
if
you
really
want
to
as
well
so.
But
the
general
idea
here
is
that
the
this
attestation
framework
is
pluggable.
So
if
you
already
have
some
way
of
establishing
trust
of
the
node,
you
can
write
a
plug-in
for
spire
and
make
it
work.
E
A
It's
a
good
question:
it's
a
use
case.
That's
come
up
a
few
times
the.
If
you
can
the
way
I
would
frame,
it
is
to
say
if
you
can,
if
you
have
a
way
of
establishing
trust
to
the
device,
if
you
have
some
say,
embedded
credential
inside
the
device
itself,
then
you
can
use,
you
can
write
a
you
could
write
an
attest
earth
that
could
lean
into
that
and
then
use
that
to
establish
50
IDs
to
your
software.
That's
running
on
the
device.
So
yes,
there's.
Definitely
a
model
question.
A
So
the
spiffy
in
the
model
we
showed
the
spiffy
agent,
is
actually
leaning
on
the
colonel
to
provide
trust.
So
in
this
case
the
the
workload
calls
the
spiffy
API
with
via
a
UNIX
domain
socket
the
the
agent
will
then
use
the
metadata
it
gets
from
that
call
to
go
back
to
the
kernel
and
say
well.
Ok,
tell
me
tell
me
who
this
is
give
me
it
spit
you
ID
and
so
forth.
I
can
then
it
can
nearly
lean
into
other
things
like
couplets
if
it
needs
to
what.
A
A
See
so
well,
yes
to
an
extent
right,
it's
a
it's
a
in
this
case
a
proper,
but
that
said,
it's
the
we
assume
at
this
point,
it's
the
responsibility
of
the
infrastructure
provider
to
maintain
that
so
it's
the
responsibility
of
the
spiffy
implementer.
Basically
so,
hopefully
the
credentials
you
get
from
this
fake
system
aren't
actually
usable
in
any
meaningful
way.
Yeah.
H
A
C
So
when
you
install
the
agent
it'll
come
with
a
bundle
from
the
server,
so
you
don't
man-in-the-middle
it,
so
it
just
doesn't
take
it
by
default.
So
you
all
have
that
trust,
and
then
that
gets
rotated
also,
so
those
sorts
can
get
rotated.
And
the
big
thing
is
that
up
and
down
the
whole
scheme
just
from
intermediate
up
to
and
the
sign
insert,
which
will
be
upstream,
that
could
all
be
all
rotated
also
deployed.
B
So,
regarding
the
the
authentication
between
agent
and
the
server
using
the
AWS
metadata,
if
you
have
a
workload
on
that
instance,
which
is
configured
in
such
a
way
that
it
has
unrestricted
network
access.
What's
to
prevent
the
workload
from
fetching
the
instance
metadata
and
pretending
to
be
a
spiffy
aspire
agent
to
the
spire
server,
not.
A
A
lot
but
then
again
the
only
thing
it
would
be
able
to
have
access
to
is
to
workload
metadata
locally
metadata
from
that
node.
So
really,
if
you,
if
you're
saying
what's
50,
doesn't
provide,
is
any
isolation
guarantees
between
processes
running
on
that
node.
So
if
you
have
a
mechanism
for
providing
that
isolation,
spiffy
can
work
with
it
in
order
to
issue
identities,
but
it
doesn't
guarantee
that
isolation
in
any
way.