►
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
Deep Dive: SPIFFE - Emiliano Bernbaum & Andrew Harding, Scytale
SPIFFE (Secure Production Infrastructure for Everyone) and SPIRE are two of the newer projects to join the CNCF. These projects build on designs first championed at Google, Twitter and elsewhere to provide robust authentication and trust between disparate micro-services in heterogeneous operating environments. This talk will expand on concepts introduced during the SPIFFE 101 session to explore in detail how SPIRE performs attestation to workloads in diverse infrastructure and middleware settings, how it leans on different secrets storage backends and how PKI material is automatically delivered to a node and workload. The talk also will cover how these capabilities can be extended and customized through SPIRE’s plugin framework. In this session, we will demo two (2) things, specifically: 1) How SPIFFE can be used to secure communication between two workloads running on different Kubernetes clusters running on different clouds. For a twist, we'll demo this for both direct connections as well as those going through load balancers. 2) How to federate SPIRE deployments in different trust domains. This demo will also showcase how we federate JSON Web Tokens (JWT) to facilitate cross-cloud communication.
To learn more: https://sched.co/HtKa
A
A
So
today,
what
we
want
to
do
is
just
go
over.
Some
of
the
features
inspire
a
lot
of
the
work
that
we've
done
since
our
last
presentation
at
coop
con
and
today,
we're
going
to
cover
federation
jot
jot
support,
which
we
just
added
this
October,
and
then
we're
going
to
show
all
this
in
a
non-void
demo.
That
Andrew
will
walk
you
through
and
then
we'll
just
wrap
it
up
with
next
steps
and
questions
from
the
audience.
A
So
before
we
start,
if
anyone
has
any
feedback
or
anything,
they
want
to
tell
us
about
spiffy
inspire.
We
would
love
to
hear
about
it.
Jenny
Schaefer
is
our
information
architect.
If
you
could
write
to
her
and
just
pinger
we'd,
really
like
we'd
love
to
hear
from
you
and
and
just
get,
you
know
your
feedback
on
spiffy,
spire
and
kubernetes
support.
Also
so
just
to
start
off.
This
is
going
to
be
an
intermediate
talk.
The
assumption
here
is
that
everyone
has
heard
of
the
spiffy
inspire
and
there's
some
rudimentary
understanding
of
it.
A
If
not
Andrew,
Jessup
and
Dan
Feldman
did
a
talk
yesterday
covering
this.
You
could
you
could
just
go
here
or
when
the
video
is
loaded
you
could
you
could
review
it
there
and
they
really
step
through
what
what
spiffy
inspire
is
also
another
Matt
Moyer
who
works
at
a
VMware
now
and
Evan
Gillman.
They
gave
a
talk
yesterday
on
on
security.
A
A
So
first
thing
we'll
talk
about,
is
Federation
and
how
we
support
that
and
how
we
see
that,
just
today
we
actually
published
a
blog
post
on
Federation
that
the
Dan
wrote
you
could
check
it
out
at
our
at
our
blog,
and
it
just
goes
into
a
little
more
detail
about
what
we're
doing
so
right
now,
with
with
Federation
the
way.
What
we're
going
to
show.
A
Not
only
does
it
get
its
identity,
it
also
gets
all
the
federated
bundles,
just
the
bag
of
bundles
that
it's
supposed
to
get
and
actually
the
the
spiffy,
the
the
trust,
domains
that
it's
supposed
to
federate
with
and
then
it
could.
It
it'll
get
all
that
all
that
material
and
then,
after
that,
it
will
just
use
that
to
create
an
MPLS
connection
to
a
different
workload.
So
I'm
gonna
just
do
a
quick
step
through
on
what
this
looks
like.
A
So,
if
you
could,
you
know,
we
have
two
two
different
trust
domains
here
we
have
a
web
trust
Amane
and
an
echo
trust
domain,
and
what
we
basically
do
here
is
we
just
push
the
bundles
from
one
trust
domain
to
the
other,
and
now
we
we
have
the
the
to
the
two
trusts
domains
have
federated
with
each
other.
They
have
all
their
older,
older
material
and
then
the
next
step
here
is
that
we
want
to
register
those
those
workloads
and
again
Andrew
will
actually
show
work.
An
example
of
this,
and
what
you
do
is
you.
A
You
register
the
with
a
webserver
workload
with
the
spire
server
and
just
tell
it
that
it's
going
to
federate
with
the
with
the
other
trust
domain
and
vice
versa
for
the
other
trust
domain.
At
this
point,
the
registration
API
has
been
updated,
I'm,
sorry,
our
our
our
mappings
have
been
updated
and
the
the
workloads
will
go
through
attestation
after
they
go
through
attestation.
We
deliver
all
the
all
the
correct,
crypto
and
all
the
all
the
bundles
that
they
need,
and
at
this
point
the
two
workloads
could
communicate
via
MPLS.
A
So
that's
just
a
quick
explanation
of
how
we're
doing
this.
So
what
are
the
next
steps
right
so
right
now,
what
we're
actually
doing
is
in
our
six
spec
group
that
meets
once
a
week
and
colleague,
Evan
Gillman
runs
that
we're
working
through
the
Federation
API
right.
What
we
kind
of
saw
there
is
that
I
bootstrap
trust
between
those
two
trust
domains
and
what
we
really
want
to
do
is
have
an
API
that
lets.
A
You
have
some
form
of
discovery
and
also
rotation
across
these
these
domains,
and
this
is
actually
what
we're
actively
working
on
right
now
and
we're
trying
to
see
also
how
we're
gonna
boot
up
bootstrap
trust
between
two
different
domains
and
then
that
that
API
will
be
codified.
We'll
add
that
to
the
spec
and
then
we'll
have
the
workload
API
and
the
Federation
API.
A
A
So
the
next
thing
we
we
worked
on
is
jots,
and
that
has
been.
We
actually
added
that
as
our
second
identity
document
this
october,
and
you
know
we'd
really.
You
know
I
just
want
to
really
thank
evan,
gilman,
justin,
burke,
andrew
harding,
spike,
curtis
and
matt
Moyer,
who
worked
on
this
and,
and
you
know,
put
a
lot
of
time
and
effort
into
it,
plus
everyone
else
in
the
community
that
gave
us
feedback
and
and
commented
on
the
on
the
request.
A
So
that's
out
there
now
and
just
to
show
again
another
snippet
of
the
the
protobuf
definition.
But
I
really
just
want
to
highlight
this
section,
which
is
the
methods
that
we've
added
to
the
to
the
api,
where
a
workload
could
fetch
its
s
fade
via
attestation
to
the
the
workload
is
attested
and
we
give
it
the
job
that
it
needs,
and
on
the
other
side,
we
have
different
ways
of
validating
that.
A
If
the
workload
is,
if
it
understands
the
the
the
workload
API,
it
could
just
call
validate
job
where
it'll
just
hand
it
back
the
job
that
it
received,
and
then
the
spire
agent
will
validate
that
or
we
could
also
fetch
the
bundles.
And
if
you
have
a
side
process
or
library
that
does
validation,
we
could
just
get
those
JW
KS
documents
and
feed
it
into
that
process.
So
I'll
just
do
a
quick
walkthrough
on
what
that
looks
like
so
again,
we're
assuming
here
that
the
two
trusts
domains
have
federated
with
each
other.
A
The
workload
goes
out,
requests
a
jot
that
is
delivered
by
the
spire
agent
shots
delivered,
and
then
we
create
we.
We
have
a
HTTP
request
to
the
other
server
on
a
different
trust
domain
who,
when
it
receives
the
jot,
basically
will
use
the
the
workload
API
to
validate
it
and
just
get
a
yes
or
no,
and
and
that's
it
so
we'll
demo
that
too
so
we're
gonna
I'm
gonna
hand
it
off
now
to
to
Andrew
again
I
just
wanted
to
thank
two
of
my
colleagues
that
couldn't
be
here:
Marco's,
hydro
and
Marcos
Jacob.
A
B
Can
you
guys
hear
me,
okay
in
the
back?
Okay,
so
before
I
hop
into
a
terminal
and
get
going
on
the
demo?
I
just
want
to
take
a
quick
walk
through
the
architecture,
the
demo,
so
you
can
understand
the
flows
that
are
happening.
We're
gonna,
start
out
with
a
web
browser
and
that
web
browser
is
gonna,
be
making
a
request
to
a
web
server
and
that
web
server
sitting
inside
of
a
container
that's
inside
of
trust
domain
one.
So
everything
on
the
left
side
here
in
green,
that's
going
to
all
be
belonging
to
one
trust.
B
The
main
the
job
with
the
web
server
is
to
talk
to
an
echo
server
sitting
in
a
separate
container
within
trust.
The
main
now
these
two
trust
domains
for
the
demo
purposes
are
just
containers
running
on
my
laptop.
But
you
could
imagine
these
could
be
two
disparate
kubernetes
clusters.
One
could
be
a
sure.
One
could
be
a
AWS.
1
can
be
GCP.
1
could
be.
You
know
some
on-prem
deployment
anywhere
where
spire
can
run
and
where
you
can
get
TCP
communication
between
the
two.
You
can
do
this
spire
based
Federation
flow.
B
So,
in
order
to
facilitate
secure
communication
between
these
two
workloads,
we're
gonna
employ
a
set
of
envoy
proxies.
The
Envoy
proxy
co-located
with
the
webserver
is
going
to
be
set
up
as
a
forward
proxy.
That's
going
to
pipe
traffic
to
the
Envoy
proxy
co-located
with
the
echo
server,
which
is
going
to
be
a
you
know
in
the
reverse
proxy
configuration
the
Envoy
proxies
themselves
are
going
to
be
obtaining
their
secret
material
from
the
workload
api
running
on
the
spire
agent.
B
Now
today,
boy
doesn't
know
how
to
talk
to
the
workload
api
directly
so
in
between
the
two
we've
injected
a
spiffy
envoy
agent
process.
That's
the
glue
between
it
exposes
the
secret
discovery
service
API
in
the
external
off
API.
That
amelie
knows
how
to
talk
to
and
on
the
backend.
It's
going
to
be
servicing
those
requests
or
facilitating
servicing
those
requests.
B
By
talking
to
the
workload
API
running
on
the
spire
agent
and,
of
course,
the
spire
agent,
if
you're
familiar
with
the
attestation
flow
and
how
that
works,
these
two
spire
agents
are
going
to
be
coordinating
with
spire
servers
that
are
operating
out
of
separate
containers
within
the
same
trust
domains
and
as
in
Miele
I
know,
went
through
we're.
Gonna
have
a
step
of
Federation
between
these
two
trust
domains.
We're
gonna
have
a
transference
of
trust
bundle
information
so
that
workloads
in
one
trust
domain
can
verify
identities
that
originated
from
the
other
trust
Amin.
B
Okay,
so
in
the
first
connection,
flow
we're
gonna
do
web
browser
again
makes
a
request
to
the
web
server.
It's
going
to
talk
to
port
8000
won
on
this
forward
proxy
and
the
forward
proxy
has
been
configured
to
talk
to
the
STS
API
running
inside
this
bit,
the
ANBU
agent
and
it's
going
to
stream
out
secrets,
namely
it's
going
to
stream
out
a
TLS
certificate
to
use
in
the
client
role
of
the
TM
TLS
handshake.
B
It's
can
also
stream
out
a
set
of
trusted
root
certificates
that
they
can
use
to
validate
the
server
certificate
presented
during
M
TLS
as
soon
as
it
has
its
secrets,
when
the
request
comes
in
it's
going
to
make
that
M,
TLS
connection
to
port
8000,
one
on
the
reverse
proxy,
which
has
also
been
configured
to
talk
to
us
TS
to
pull
out
a
certificate
instead
of
trusted
roots
and
assuming
that
handshake
all
goes.
Okay,
the
Envoy
proxies
can
afford
the
request
on
to
the
echo
server
okay.
B
So
that's
that's
our
first
connection,
direct
M
TLS
connection
between
two
Envoy
proxies
our
second
scenario.
The
web
browser
is
again
going
to
talk
to
the
web
server.
This
time,
it's
going
to
talk
to
port
8000
T
running
on
the
Envoy
forward
proxy
and
which
has
been
configured
to
contact
the
external
off
API
and
the
implementation
for
the
external
off
API
is
going
to
request
the
jot
to
a
jot
from
the
workload
API
and
inject
it
in
the
HTTP
request.
B
So
after
that
job
has
been
injected,
a
TLS
connection
is
going
to
be
made
to
the
layer,
seven
proxy
and
that
request
is
gonna,
be
forwarded
on
through
and
they
ll
subband
proxy
is
going
to
turn
around
and
stablish
TLS
connection
to
port
8000
to
on
the
reverse
proxy,
which
of
course,
is
using
SDS
to
obtain
the
server
certificate
that
it
presents
during
the
handshake.
Once
the
TLS
handshake
is
completed,
the
HTTP
request
flows
all
the
way
through
to
the
Envoy
reverse
proxy.
B
It's
going
to
talk
the
external
off
API,
which
is
going
to
get
the
headers
for
the
request.
It's
going
to
strip
out
the
jot
token
from
the
authentication
header
and
it's
going
to
forward
along
to
the
spire
agent
for
validation
and
assuming
everything
validates
okay,
then
it'll
get
forwarded
on
to
the
echo
server.
Alright.
So
give
me
just
a
second
here
to
mess
around
with
displays
these
real,
quick.
B
All
right
is
that
font
big
enough
for
you
guys
in
the
back,
perfect,
okay,
so
first
things.
First,
let's
start
up
our
containers,
so
we've
got
again
a
container
for
each
of
the
spire
servers
running
in
these
trust
domains,
a
container
for
the
workload
along
with
the
co-located
Envoy,
proxy
and
spiffing
envoy
agent,
inspire
agent
and
then
a
container
for
the
layer,
seven
proxy.
So
now
that
our
containers
are
running,
let's
start
up
the
workloads,
so
we've
got
a
web
server
and
an
echo
server
and
before
we
go
any
farther
setting
up
our
infrastructure.
B
Let's
hop
over
to
the
browser
here
and
we
can
see
that
the
web
server
presents
us
with
three
choices
on
how
to
need
how
it
can
connect
with
the
backend
with
the
echo
server.
So
let's
just
do
a
direct
connection.
First
to
set
up
our
expectations,
you
can
see
that
the
were
shown
the
headers
that
were
sent
by
the
web
server
and
headers
that
were
received
by
the
echo
server.
And
since
this
is
a
direct
connection
between
the
two
we'd
expect
them
to
match.
And
they
do.
B
You
can
see
our
super-secret
password,
we're
passing
along
which
we
don't
want
to
be
in
the
clear
and
hence
we're
gonna
set
up
some
secure
communication
infrastructure
via
Envoy.
So
going
back
to
our
terminal
here,
we're
gonna
start
the
called
aspire
infrastructure.
This
is
the
spire
servers,
the
spire
agents
and
the
spiffy
envoy
agent
envoy
is
already
running
in
these
containers,
so
we
don't
need
to
start
it
up
and
then
we're
going
to
do
the
Federation
step
before
we
federated
just
show
you
if
I
can
type
today.
B
So
we're
gonna
run
this
dump
command
on
the
spiffy
gombo
age
of
binary
and
boy.
You
guys,
nuts,
you
dad
there
we
go
and
then
what
that
dump
command
is
going
to
do
it's
going
to
connect
to
the
currently
running,
spiffy
Envoy
agent
and
just
dump
all
the
resources
that
are
being
that
are
available
over
SDS.
Let
me
see:
oh,
we
have.
We
have
no
resources
actually
before
I.
Do
that
sorry,
we
were
talking
about
Federation.
What
I
actually
wanted
to
do
it's
this
step
here.
B
Okay,
so
you
really
can't
see
this
that
well,
but
I've
dumped
the
trust,
bundle
in
inside
of
trust
domain
1,
and
you
can
see
that
it's
a
JW
KS
document
and
it's
got
two
keys
within
it.
This
top
key
right
here
is
used
for
validating
x.509
identities,
so
x.509
s
vids.
You
can
see
the
embedded
certificate
inside
that
entry
and
then
down
here
you
see
a
public
key.
That's
for
validating
ja,
s
feds
that
have
originated
from
this
trust
domain.
Okay,
and
so,
like
Emiliana
mentioned,
we
don't
have
a
federation
api
that
will
facilitate
this.
B
Is
this
federation
step
fully
designed?
Yet
so
we're
gonna
cheat
a
little
bit
and
all
we're
gonna
do
is
dump
that
bundle
out
of
trust
domain
one
and
pipe
that
into
a
set
command
on
trust,
Amin.
Two
and
in
the
same
vein,
dump
the
bundle
on
trust,
Amin,
two
and
pipe
it
to
a
set
command
inside
trust,
Amin,
one
all
right.
So,
let's,
let's
federates.
B
Okay,
now
before
I
did
that
step,
I
dumped
the
resources
on
the
STS
API
running
inside
the
web
and
echo
containers,
and
you
can
see
that
no
resources
have
come
back
and
that's
because
we
haven't
defined
our
workloads
yet
inside
spire.
So
let's
do
that
if
you
can
read
that
what
we're
doing
is
inside
trust
domain,
one
for
any
process
connecting
to
the
spire
agent
running
as
the
spiffy
envoy,
agent
user
is
going
to
obtain
an
S
vid
with
the
webserver
spiffy
ID,
and
we've
declared
that
that
workload
should
federate
with
trust
domain.
B
Well
sure
what
that
means
in
a
second.
In
the
same
vein,
we've
got
trust
domain,
we're
creating
a
registration
entry
for
anyone
connecting
to
the
workload
API.
As
the
spiffy
envoy,
agent
user
is
going
to
obtain
an
S
fed
with
the
spiffy
idea
of
the
echo
server,
and
we've
declared
that
workload
should
federate
with
trust
Amin
one.
Yes,.
B
Yes,
we
kind
of
have
a
tooth
to
face
step,
so
the
first
step
is:
first,
you
have
to
educate
the
spire
servers
running
in
each
of
these
trust
domains
about
the
trust,
bundle
for
the
other
trust
domain,
and
this
the
second
leg
that
we're
showing
here
is
on
a
per
workload
basis.
You
can
say
that
this
workload
should
be
able
to
verify
identities
from
this
other
trust
domain,
and
so
it's
not
like
every
workload
inside
your
organization
gets
the
trust
bundle.
B
Okay,
let's
hold
that
off
to
the
queue.
Okay,
that's
a
great
question:
okay,
so
let's
let's
run
this
and
create
these
registration
entries
and
now
the
the
workloads,
the
spire
agents
running
again.
Next
to
these
workloads
should
have
identities
for
these
workloads
available
and
we'll
show
that
by
again
talking
to
the
SDS
API
running
next
to
the
workload
and
you
can
see
on
the
web
web
spiffy
ANBU
agent
has
exposed
a
TLS
certificate
with
the
URI
sand
for
the
web
server.
That's
the
spiffy
ID
right
there,
along
with
the
private
key.
B
We
can
do
the
same
thing
inside
the
echo
container
and
again
we
get
a
certificate
out
with
the
spiffy
ID,
for
the
echo
server,
with
its
private
key
and
again,
a
validation
context
with
a
trusted
roof
for
domain
1
and
domain
2.
Also,
and
so
speier
doesn't
have
spider
takes
care
of
your
authentication
piece
for
demo
purposes.
Envoy
supports
you
are
ice
and
validation
of
peer
certificates,
it
receives,
and
so
we've
you
can
see
this
list
down
here.
B
B
B
Okay.
So
what
happens
now
if
we
break
Federation
so
I'm,
going
to
do
a
step
here
which
is
going
to
update
these
registration
entries
for
the
workloads
and
it's
going
to
drop
that
federates
with
declaration,
so
the
to
trust
our
to
trust
domains
still
know
about
each
other's
bundles,
but
the
workloads
have
been
are
now
not
federating
with
that
trust,
Amin
explicitly,
and
so
what
that
means,
if
we
were
to
look
at
the
SDS
API
again,
if
you
look
at
the
validation
context,
we
now
get
back.
B
It
only
has
the
trusted
roofer
for
our
own
trust
Amin
and
on
the
web
side
and
again
on
the
echo
server.
It
only
has
the
trust
domain.
The
trusted
root
for
the
trust
domain,
two
of
the
D
echo
container,
runs
in
and
now,
if
we
try
our
connection
on
Buddha
envoy,
we
can
see
that
the
forward
envoy
proxy
co-located
with
the
webserver
has
returned
a
failure
to
establish
an
upstream
connection
with
the
reverse
Envoy
proxy
running
our
co-located
with
the
echo
server,
and
what
has
happened
is
during
the
TLS
handshake.
B
The
reverse,
Envoy
proxy
presents
the
certificate
for
the
webserver,
and
the
forward.
Envoy
proxy
rejects
that
because
it
no
longer
has
a
trusted
root
to
chain
it
back
to
okay.
So
let's,
let's
reef
iterate
put
things
back
to
normal,
so
we've
reef,
iterated
and
now,
when
we
run
this
eventually
as
soon
as
Envoy
wakes
up
to
the
change,
we've
got
got
a
connectivity
established
again.
Okay,
so
that's
that's
our
first
connection
scenario:
we've
done
MT
LS
between
two
Envoy
proxies.
Let's,
let's
do
our
second
connectivity
scenario.
B
B
So,
let's
see
what
happens
when
we
try
and
go
through
that
port
and
when
we
run
it,
we
get
a
failure
back.
So
the
request
is
flown
all
the
way
into
the
layer,
seven
proxy.
It
has
tried
to
establish
TLS
connection
with
the
reverse
Envoy
proxy,
but
it
doesn't
present
a
client
certificate
and
envoy
kills
the
handshake.
So
that's
expected.
Let's.
B
B
This
was
attached
by
the
forward
proxy
co-located
with
the
web
server
and
it
stuffed
in
the
jot
token
there
sorry
the
job
that
it
obtained
from
the
workload
API
running
on
the
spire
agent
and
if
we
take
that
shot
and
when
we
decode
it,
we
can
see
in
our
claim
set
a
subject
ID
with
the
spiffy
idea
of
the
web
server
and
an
audience
value
with
the
spiffy
ID
of
the
echo
server.
Okay.
B
Let
me
see
a
failure
here.
So
what
has
happened
is
the
layered.
The
jot
token
has
flowed
through
the
layer,
seven
proxy,
into
the
reverse
Envoy
proxy.
On
the
backend,
it's
been
passed
off
to
the
spiffy
envoy
agent,
who
has
called
the
workload
API
to
validate
that
job
token,
and,
as
you
can
see
from
the
error
message
here,
the
workload
API
a
has
returned
to
failure
to
validate,
because
it
can't
find
trust,
bundle.
Information
for
this
trust
domain
that
the
job
belongs
to.
So
it
has
failed.
B
B
Let's
go
to
the
configuration
for
the
spiffy
envoy
agent
running
a
co-located
with
the
echo
server
and
down
in
this
jot
section,
we've
gotten
a
loud
list
of
spiffy
IDs
that
we
expect
to
see
in
any
jots
that
are
handed
to
us
for
validation.
So
we
can
change
that
spiffy
ID
in
the
list
and
reload
the
spiffy
convoy
agent.
B
We
see
a
failure,
and
this
is
the
job
token,
is
fluid
all
the
way
through
it's
been
validated
by
the
spire
agent
and
then
the
spiffy
on
voyage
and
says:
okay
now,
let's
validate
to,
let
me
see
if
the
subject
claim
is
within
this
authorized
list
and
it
of
course
isn't,
and
so
it
fills
the
connection.
And
of
course,
if
we
restore
everything
back
to
two
working
order,.