►
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
Intro: SPIFFE - Emiliano Bernbaum & Scott Emmons, Scytale
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 heterogeneous environments. We'll walk through the design goals for SPIFFE (a specification) and SPIRE (a multi-cloud implementation of SPIFFE). We will go over all the developments and progress in SPIRE over the last few months. We will present an overview of how it can be used in conjunction with Kubernetes to build secure and scalable microservice architectures. We will also share our current roadmap with the community.
https://sched.co/MPib
A
A
So
here
we
go,
so
we
have
a
bunch
of
talks
at
@q
con.
So
there's.
Obviously
this
one
tomorrow,
evan,
gilman
and
shawn
Crampton
are
doing
a
zero
trust
service
mesh
with
calico,
so
that's
happening
at
11:05
and
then
we're
also
doing
a
deep
dive
into
spiffy
at
1450
tomorrow
and
what
we're
gonna
do.
There
is
really
get
into
spire
running
on
kubernetes,
so
one
of
the
main
things
that
we've
been
doing
since
the
last
coop
con
is
really
fix.
A
Updating
spire
to
be
able
to
run
cleanly
on
on
kubernetes
and
we're
gonna
do
a
whole
demo
and
talk
about
that.
Then
we
have
a
secure
multi-cloud
with
cross
clusters
and
that's
being
presented
by
Evan
just
here
right
give
up
to
seven
and
then
to
wrap
it
up.
We
have
a
talk
with
uber
security
and
how
to
build
our
workload
identic
platform
and
that's
going
to
be
Tyler,
Julian
and
Dan
Feldman.
So,
there's
a
lot
of
stuff
that
we're
presenting
so
what's
spiffy.
So
what
really?
A
And
the
way
we
really
do,
this
is
by
defining
a
standard
provable
way
to
provide
an
identity
to
a
workload
and
also
a
standard
way
of
obtaining
that
workload
and
validating
it,
and
spiffy
is
really
it's
made
up
of
four
different
specs
and
we'll
talk
about
each
of
those
and
the
first.
You
know
we.
What
we
do
is
the
spiffy
ID,
which
is
how
we
identify
the
workload
there's
actually
document
that
we
served
that
to
that
workload,
and
we
expose
this
through
a
workload
API
to
deliver
that
document.
A
And
then
the
last
thing
that
we've
been
working
on
is
a
Federation
API.
So
this
is
what
a
spiffy
ID
looks
like
it's
really
modeled
as
URI.
It's
just
basically
just
a
structured
string.
We
don't
really
prescribe
how
you
should
you
should
what
data
you
should
put
in
there
and
if
we
break
it
down,
the
trust
domain
is
the
domain
for
that
for
that
URI,
which
really
describes
the
the
root
of
trust
for
where
those
workloads
live.
A
Now.
The
next
thing
is
that
verify
will
document
the
yes
fade.
Currently,
we
support
two
different
types
of
best
fades.
We
have
an
x.509
s,
vid
and
a
jot
s
fade
and
we
started
with
x.509
certificates
as
the
underlying
doctype
and
it
made
the
most
sense
because
it
was
widely
deployed
and
understood
and.
A
And
what
we
really
did
and
in
the
spec
is
described
what
goes
in
that
certificate
in
the
beginning,
what
we
really
were
doing
was
describing
and
figuring
out
what
actual
expo
nines
extensions
we'd
want
to
use
where
we
would
actually
store
the
this.
The
spiffy
ID
in
the
document
which
we
put
in
the
San
URI,
and
then
we
also
described
how
to
validate
that
cert
and
the
spiffy
ID
within
it.
The
other.
A
A
The
third
part
of
the
of
what
we're
doing
of
what
we
support
is
the
workload
API
so
that
the
workload
API
is
a
standardized
local
interface,
where
you
a
workload,
could
contact
that
API
and
the
API
will
return
the
identity
to
that
caller.
It
really
answers
a
question:
Who
am
I,
so
when
the
workload
comes
up,
it
talks
that
API
and
the
after
it
goes
through
a
process
that
we
call
attestation
and
I'll
talk
more
about
that
in
spire.
A
So
what
we,
because
it's
agnostic-
and
we
this
would
this
also
works
on
kubernetes
or
TCP
or
other
platforms
that
you
have
or
bare-metal
and
then
the
next
thing.
What
we've
really
been
working
on
recently
is
Federation
and
we've
just
wrapped
up
all
the
spec
work
in
Federation
and
we're
actually
in
the
process
of
implementing
that
inside
of
spire.
So
with
with
Federation.
A
So
if,
if
it's
not
spiffy
but
something
else
that
implements
the
Federation,
API
we'd
be
able
to
peer
with
that
and
have
the
workloads
in
the
two
different
environments
talk
to
each
other
and
even
if
they
don't
support
the
workload
API
we'd
be
able
to
to
communicate
with
it
if
they
deliver
a
certificate.
A
different
way,
such
as
sto,
with
the
way
it
delivers
shirts.
And
the
other
thing
is
that
the
Federation
API
is
compliant
with
JW
KS
spec.
A
So
what
we're
also
doing
is
that
it's
we
could
support
Oh
IDC
Federation,
where
we
could
fire
a
twith
Oh,
a
DC
compliant
system,
so
that
that
really
makes
up
what
what
spiffy
is
those
those
four
different
documents
now?
The
next
thing
we
have
is
spire
spire
would
actually
what
spire
is.
Is
the
code
base
that
we've
written
with
with
the
community
to
support
the
spec
to
supply
and
implement
the
workload
API
and
the
Federation
API?
A
So
you
know
first
I
want
to
kind
of
it's
it's
kind
of
crazy
as
we've
kind
of
started,
the
community
that
there
was
a
recent
meetup
in
Japan,
led
by
a
team
at
Z,
lab
and
Tomoya
who
saw
me
and
they
had
a
great
presentation,
great
slides
and
I.
Actually,
they
inspired
me
and
I
copied
a
little
bit
of
them,
but
I
just
want
to
make
sure
I
give
him
credit,
because
it
was
really
really
good
stuff
out
there.
A
But
what
we're
showing
here
is
that
you
know,
as
you
have
two
different
trust,
domains
and
different
applications
in
those
domains.
You
could
assign
spiffy
IDs
to
the
different
items,
the
different
workloads
in
that
system,
and
then
you
know
we
allow
them
to
talk
to
each
other
right,
that's
basically
the
crux
of
Federation
and
and
what
we
supply
with
which
spire.
A
So
looking
at
spire,
it's
really
made
up
of
two
different
elements:
there's
a
spire
server
and
inspire
agent
that
you
have
to
install
in
each
node
that
you
want
to
to
to
run
inside
of
your
of
your
fleet
and
what
the
spire
server
does.
It
supplies
this
identity
mapping
node
attestation,
which
is
how
do
we
identify
the
node?
That's
in
your
in
your
fleet.
It
actually
also
signs
your
s,
feeds
and
issues
them,
and
it
also
supports
the
Federation
API.
A
The
agent
will
expose
this
workload
API,
and
it
also
does
the
workload
attestation,
which
is
how
it
figures
out,
what
the
who
the
workload
is.
So
we'll
just
do
a
walk-through,
and
the
first
thing
is
I'd
like
to
thank
Evan
Gilman
and
his
artisinal
arrows
again
inspired
by
his
slides
and
explaining
how
this
this
stuff
works.
A
We
also
have
the
ability
to
use
an
upstream
PGI
system,
so
we
have
a
plug-in
model
where
you
could
actually
plug
it
into
another
another
piece,
another
PKI
system
that
you
have
so
you
could
chain
these
together.
If
you
don't
want
to
just
use
the
self-signed
cert
inside
of
the
inside
of
the
plain,
vanilla,
spire
server
and
then
the
last
thing
we
do
is
that
we
expose
this
registration
API.
This
is
this
is
how
you
define
what
a
workload
looks
like.
A
So
what
we
do
is
we
have
properties
for
a
workload
that
we
call
selectors
and
those
selectors
will
dictate
how
we
how
we
identify
that
that
workload
running
in
your
fleet.
So
as
an
example,
you
know
here
we
have
an
example:
registration,
where
we
were
basically
saying
that
whoever's
running
in
the
main
space
payments
and
with
the
service
account
staging,
and
it
has
this
docker
image,
we're
going
to
identify
that
as
the
payment
web
workload
and
deliver
that
that
estimate
to
that
workload.
A
In
that
that's
managed
through
that
registration
API.
So
we'll
just
do
look
at
a
spire
server
coming
up,
so
we're
running
this
on
a
plant
and
as
as
soon
as
we
come
up,
the
that
server
could
attest
any
any
agent
running
on
the
on
its
that
in
its
environment.
So
when
the
the
agent
comes
up,
the
the
the
note
comes
up,
the
agent
wakes
up
and
it's
whole
thing
is
proving
it
is
who
it
is
right.
A
A
On
that
on
that
node
will
gather
proof
right,
it'll
gather
whatever,
whatever
data
it
needs
to
send
back
to
the
spire
server
to
prove
it
is
who
it
says
it
is
in
AWS
this
would
be
an
iid
and
in
in
kubernetes
we
just
we've
just
created
a
sat
and
piece
at
a
tester
to
use
the
account
token
at
testers
to
prove
who
that
workload
is.
But
this
whole
system
is
pluggable
where
we
could
have.
A
We
could
use
at
x.509
certificates
on
a
box
or
or
tokens,
and
you
could
generate
beforehand
to
to
attest
that
that
node
is
who
it
is.
So
once
that
happens,
the
spire
agent
will
present
that
that
proof
back
to
the
spire
server
and
then
the
spire
server
will
we'll
go
back
and
talk
to
the
platform
with
whatever
API
it
exposes.
And
then
again
we
do
this
through
plugins.
So
we
have
a
node
attest
to
plug-in
that
we
could
expand
and
use
different
ones
for
different
platforms.
A
So
for
for
kubernetes
we
could
use
piece
at
or
sat
a
testers
to
verify
that
the
the
node
is
who
it
says
it
is
and
then,
after
that
process
is
done,
we
will
deliver
the
s
feedback
to
that
agent
for
distribution
so
on,
but
that
so
that
that
agent
now
has
that
that's
the
identity
of
the
of
the
node
so
now
going
forward
when
it
goes
back
and
talks
to
spire
server.
It's
going
to
use
that
certificate
to
salish
M
TLS
between
the
spire
age
and
inspire
service.
A
Well,
we've
really
done
here
is
we've
identified
the
the
node
that
the
agents
running
on
so
the
next
part
is
how
do
we
identify
the
workload
that
is
running
on
that
system?
So
the
way
a
spire
does
this?
Is
that
the
spire
agents
running
on
that
box
and
we
are
we're
exposing
this
local
socket
that
exposes
the
API.
So
the
interesting
thing
here
is
that
this
is
an
unauthenticated
API
call
right.
So
any
the
work
look
could
come
up
and
talk
to
the
socket.
A
We
don't
have
to
inject
a
credential
or
a
secret
for
that
communication.
What
we
rely
on
is
the
process
that
we
call
attestation
where
we
could
introspect
that
workload
see
who
it
is
see
if
it
matches
the
pattern
that
we've
registered
beforehand
and
then
identify
the
workload
as
as
the
as
the
identified
as
the
set
of
selectors
that
we
previously
registered.
So
when
the
workload
comes
up,
it'll
it'll
try
to
talk
to
that.
To
that
API
socket
and
again,
the
way
we
do
our
testers
their
pluggable.
So
we
could
run
this.
A
We
could
attest
through
a
Linux
kernel
or
we
have
a
kubernetes
tester
and
you
could
write
different
ones.
We
could
look
at
docker,
docker
images
or
Linux
primitives
that
we
could
also
use
to
attest
that
piece
of
code
and
in
order
to
validate
the
attestation.
So
once
the
work
look
comes
up,
he
talks
to
the
he
talks
to
the
API
socket
and
we
basically
kick
off
attestation.
A
So
that's
that's
just
that
process
and
if
it
does
match
we,
we
deliver
a
certificate,
the
s
vid
to
that
workload.
So
now
it
could
use
that
and
we've
identified
that
that
unique
piece
of
code
ran
through
those
so
that
that's
you
know
an
explanation
of
what
spire
is
and
spiffy.
So
what
I'm
gonna
do
now
is
I'm
gonna
hand
it
off
to
to
Scott
to
talk
about
the
latest
updates
on
the
actual
project.
So
you
want
to
yeah
sure.
B
All
right,
so
a
lot
has
happened
since
Q
Khan
in
December
in
Seattle,
so
we've
merged
over
a
hundred
and
twenty
pull
requests.
We
have
three
releases
that
have
been
published.
There's
been
18
different
contributors
to
the
project,
we've
introduced,
13
major
features
and
then
also
published
some
getting
started
guys
in
sample
configurations
that
make
it
pretty
easy
to
to
get
started
and
give
spire
a
try.
B
There's
a
few
specific
contributors.
We
kind
of
want
to
call
out
for
putting
in
some
some
pretty
big
features,
so
Matthew
and
Matt
from
square
contributed.
My
sequel,
datastore
Tyler
from
uber,
contributed
no
data
station
using
SSH
certificates.
Michael
from
Square
contributed
support
so
that
the
AWS
secrets
manager
can
be
used.
B
There's
a
cig,
spec
group
and
there's
been
a
couple
of
updates
to
that
as
well.
Since,
since
the
last
cube
con
spec
for
for
jot
s,
vids
has
been
completed
and
the
spire
implementation
for
that
is
available,
and
then
a
draft
for
Federation
has
been
stabilized
and
that
draught
really
covers
specifications
for
the
spiffy
trust
domain
and
the
bundle
format
for
federating
last
night,
spire
0.8
was
released
from
here
in
Barcelona.
Some
of
the
things
that
went
into
spire
0.8
is
a
I
mentioned
the
secret
manager
using
AWS
secret
manager
in
the
upstream
CA.
B
We
have
introduced
telemetry
so
that
metrics
from
spire
can
be
pushed
into
your
favorite
metric
system.
We've
introduced
some
plugin
and
host
services
and
and
what
those
services
are
is.
If
you
are
writing
a
plug-in
for
spire
with
plugin
services,
you
can
provide
a
set
of
kind
of
standardized
callbacks
that
spire
will
use
to
provide
or
inform
spire
of
information
around
your
plugin.
You
might
want
to
use
that
for
health
checks
or
liveness
probes,
for
example.
B
So
it
makes
it
a
little
bit
easier
to
use
the
self-signed
certificate
and
spire
server
just
manages
rotation
of
that
all
all
automatically
and
then
finally,
a
nested
spire,
so
nested
spire.
Although
this
this
seems
like
it's
a
lot
like
Federation,
it's
it's
very
different.
It
allows
a
topology
of
multiple
spire
servers
within
a
single
trust
domain,
so
at
the
top
that
might
be
a
master
spire
server
running
in
a
secure
environment.
Maybe
on
the
left
is
kubernetes
and
maybe
on
the
is
your
on-prem
datacenter
or
some
other
cloud.
B
So
this
allows
all
of
these
environments
to
work
together
in
a
single
trust
domain,
but
your
workloads
don't
have
to
communicate
back
to
that
master
server.
Instead,
those
calls
are
dispatched
through
a
local
spire
server,
so
it
allows
you
to
sort
of
wall
in
a
little
bit
each
environment
and
keep
that
master.
Spire
server
more
secure,
I'm
gonna
go
through
no
I'm,
not
gonna
go
through
each
of
these
one
by
one.
This
is
our
change
list
for
spire
0.8,
but
we
really
want
to
call
out
the
things
in
red.
B
These
were
all
contributed
by
people
out
in
the
community
by
others.
Then
then
Scytale,
which
is
really
great
and
actually
we're
we're
near
the
end.
So
if
you
want
to
try
it
out
on
github
you'll
find
the
see
the
spiffy
specs
specification
at
the
first
link,
the
spire
reckless
reference
implementation
at
the
second
link
and
then
we're
on
slack
at
at
that
location,
yep.
C
Yeah
I
have
one
question
that
I
would
like
to
protect
my
workload
with
spiffy
and
it's
kind
of
a
certificate
or
jobs.
Okay,
but
I
wonder
how
can,
with
my
workload
to
attest
it
that
certificate
wherever
it
comes
from
or
did
the
spiffy
token?
That's
the
connecting
service
shows
me
it's
white
because
you
mentioned
that
it's
a
MPLS
and
that's
for
sure
than
when
I
stopped
using
MPLS.
C
It
also
proved
that
the
other
party
who
connects
to
my
upload
process,
the
secret
key
with
jot
there
I
need
whenever
you
find
it,
that's
what
it
service
connecting
to
me.
I
need
to
get
the
public
key
from
somewhere
to
what
they
did,
but
also
this
token,
when
it
comes,
can
be
stolen.
So
how
can
I,
when
I
writing
a
service
verifying
that
the
beefy
identity,
which
is
given
to
me
when
it's
connecting
it's
legitimate.
D
C
D
C
C
D
So
spire
agent
exposes
that
workload
API
socket
that
you
saw
on
the
diagram
out
of
that
socket
comes
the
authentication
material,
so
that
is
the
certificates
and
jot
tokens
and
also
comes
the
public
use
for
verifying.
So
there's
two
AP
is
supported
on
that
workload
API.
The
first
is
called
spiffy
workload
API,
which
is
a
specification
standard.
The
second
supports
envoy,
SDS
API,
which
is
how
on
voice
such
as
certificates,
so
some
people
will
put
a
proxy
in
front
of
their
workload
and
use
the
proxy
to
terminate
mt
LS
and
to
do
JWT
verification.
D
E
A
So
we
don't
we,
we
just
do
authentication
so
there's
other,
so
OPA
just
put
out
a
blog
post,
showing
how
they
could
do
authorization
with
a
spiffy
ID
and
the
project
is
really
considered.
The
main
focus
of
the
project
is
how
to
identify
a
workload
in
any
environment
and
deliver
all
the
identities
to
that
workload.
Through
this
API,
we
felt
that
doing
authorization
was
way
too
big
for
us
and
just
wanted
to
be
really
laser
focused
on
authentication
and
identifying
the
workloads.
But
Mars
talked
yes.
There's
a
talk
tomorrow.
F
Have
a
couple
of
questions,
one
is
when
you
talk
about
invoice
and
spiffy,
basically
you're
giving
an
identity
to
the
sidecar
right,
not
to
the
service.
Yes,
so
any
service
that,
for
example,
if
I'm
managing
to
impersonate
the
service.
Speaking
with
the
sidecar,
you
don't
that's
out
of
that
domain,
that's
kind
of
like
a
yes
or
no
question.
I
just
wanna
understand
that,
and
the
second
thing
is
that
I'm
thinking
about
is
what's
preventing
me
as
a
as
an
attacker
as
a
hacker
to
impersonate
services
using
speedy
certificates.
So
what
kind
of
validation
is
done?
F
A
So
for
the
Faurot,
so
the
way
you
could
talk
to
the
API
is
through
envoy,
right
or
through
libraries
that
we
support
right.
So
we
have
libraries
in
go,
see
and
and
in
Java
right,
so
you
could
do
TLS,
determination,
in-process.
So
you
don't
have
that
Eric
between
the
your
workload
and
that
and
that
an
envoy
or
whatever
proxy
are
using
so
yeah.
You
are
verifying
the
you
are
verifying
the
the
proxy,
not
the
actual
workload.
So
it
really.
A
You
know
that
is
up
to
you
how
you
deploy
it
and
obviously,
when
you
have
that
flexibility,
it
comes.
It
comes
at
a
price
and
you
have
an
air
gap
between
that.
But
that's
why
we
also
supply
those
those
those
libraries
for
you
to
use,
and
the
second
question
was
about
how
do
I
know
that
I'm
not
being
spoofed
by
by
different
system
or
hacker
and
really
that's
you
know
we.
What
we're
doing
is
that
we're
defining
these
fingerprints
for
that
code
right.
A
So
if
you
hook
it
up
to
your
your
build
pipeline
and
you
want
to
register
those
through
that
and
there's
that
signature
that
use
that.
That's
all
that
we
could
verify
right,
we
don't
do
we
don't
quarantine
the
code
or
anything
right,
we're
just
trying
to
match
that
fingerprint
that
we
know
about.
So,
if
somebody
spoofs
and
goes
into
your
system,
it
starts
registering
their
own
things
and
obviously
you
have
problems
there,
but
we
don't
we
don't.
The
only
thing
we
could
do
is
just
say
that
look.
A
This
is
the
pattern
that
we're
looking
for
and
that's
what
we
could
apply
right.
So
obviously
the
the
tight
of
the
pattern
is
and
the
more
control
you
have
over
it,
the
the
better
right,
but
we've
done
a
you
know.
We
have
a
whole
talk
and
analysis
that
we
did
with
the
CNC
F,
showing
all
the
all
the
security.
D
Wanna
yeah,
yes,
very
much
so
so
you
know
Emiliano
mentioned
that.
Spire
is
very
pluggable.
There's
a
lot
of
really
important
aspects
of
operation
of
this
kind
of
system
which
are
kind
of
offloaded
to
plug-in.
So
you
can
make
implementations
which
have
different
backings.
One
of
those
plugins
is
called
key
manager.
D
Plugin
is
used
for
key
storage,
so
on
the
server
we
have
a
interface
that
looks
very
much
like
pkcs
11
that
you
can
use
for
HS,
empty
storage
and
on
the
agent
we
have
an
interface
available
which
is
similar,
which
will
which
you
can
use
to
wrap
keys
with
TPMS
and
things
like
this.
We
don't
have
a
TPM
key
manager,
plug-in
implementation
in
the
open-source
project
just
yet,
but
you
can
certainly
write
your
own
and
bring
it
in
and
we
would
love
a
contribution
if
you're
interested
in
doing
something
like
that.
Yeah
yeah.