►
From YouTube: Securing Communication Between Meshes and Beyond with SPIFFE Federation - Evan Gilman & Oliver Liu
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Securing Communication Between Meshes and Beyond with SPIFFE Federation - Evan Gilman, Scytale & Oliver Liu, Google
One of the hottest features that Istio brings to the table is transparent, mutually-authenticated TLS between all workloads running on it. Under the covers, it relies on SPIFFE to provide the cryptographic identity that is used to perform this mutual authentication. SPIFFE relies on an authority to issue identity. In an Istio mesh, Istio Citadel (CA) issues certificates to workloads by default... but, what happens when you have more than one Istio mesh, and hence more than one Citadel? Or Istio workloads talking to external services? Enter SPIFFE federation. It allows SPIFFE identity issuers to peer with each other, enabling workloads in disparate domains to securely authenticate and communicate with each other. In this talk, we will describe the challenges involved here and how SPIFFE addresses them, as well as demonstrate SPIFFE federation between Istio mesh and SPIRE.
https://sched.co/Uacx
A
Can
you
all
hear
me,
okay
in
the
back
awesome
yeah?
So
thank
you
for
joining
us
today,
we'll
be
talking
about
securing
communication
between
meshes
and
beyond
the
spiffy
Federation
I'm
having
Gilman
I
work
for
a
site.
Alice
mentioned
I'm
a
maintainer
of
spiffy
and
spire
project
I'm
here
with
Oliver
hi.
A
So
today,
we'll
talk
about
first
kind
of
kick
off
with
the
role
of
identity
in
a
service.
What
is
a
service
mesh?
Why
is
identity
important
in
one
I'll
toss
it
to
Oliver
he'll
talk
a
little
bit
about
some
of
the
challenges
that
are
presented
when
you
have
more
than
one
mesh
or
when
you
have
hybrid
workloads,
where
you
have
some
stuff,
that
is
on
a
security
mission,
some
stuff
that
is
not
on
security
mesh.
A
Then
we're
going
to
talk
a
little
bit
about
making
Federation
how
it
addresses
how
to
address
these
problems
and,
finally,
a
demo
which
I
hope
works,
which
will
show
us
pitting
Federation
in
action
between
estion
and
inspire,
so
I
thought
it
would
be
appropriate
to
start
the
talk
with
the
question
like
what
is
a
service
mesh
I
thought
about
it
for
a
while,
like
what?
What
if
I
would
make
up
a
definition?
A
A
A
So
this
is
the
context
that
that
we'll
use
for
this
talk-
and
you
know
the
question
that
at
least
in
my
mind
this
the
statement
elicits.
Is
you
know?
How
do
you
accomplish
this?
How
do
you?
How
do
you
provide
these
kinds
of
services
as
feature
of
the
infrastructure
and
remove
those
concerns
from
application?
A
This
proxy
provides
like
really
convenient
control
point
for
traffic
coming
in,
and
out
of
that
happen,
provides
that
that
point
of
control
for
all
the
services
to
be
kind
of
exposed
and
we'll
talk
a
little
bit
about
what
those
services
might
be
there's
a
whole
bevy
of
features
that
these
proxies
can
bring.
This
is
just
a
few
of
them.
These
are
some
of
the
bigger
capabilities,
I
think
folks
associated
with
service
mesh.
A
There
are
others,
of
course,
or
many
others,
but
these
are
just
the
ones
that
that
I
find
that
are
like
most
motivating
the
most
common
reasons
that
folks
will
come
and
ask
about
service
matters.
For
these
and
you'll.
Note
that
there's
no
shortage
of
security
related
features
here,
among
them,
strong
authentication,
authorization
and
mutual
TLS
or
some
of
the
more
popular
security
features.
Folks
look
for
when
deploying
service
mesh,
but.
A
On
those
things
are
some
prerequisites,
of
course,
you
think
about
authentication
authorization,
that's
all
about.
Like
can
I
talk
to
B
and
how
does
B
know
that
it's
really
a
those
requesting
this
thing,
so
it
becomes
clear
that,
in
order
to
answer
that
question,
you
need
like
a
clear
definition
of
what
a
is
and
what
B
is.
So
you
need
identity.
We
call
that
service
or
workload
identity.
That's
where
spiffy
comes
in
spiffy
is
a
identity
framework
for
production
workloads.
A
Actually,
it
stands
for
secure
production,
identity
framework
for
everyone,
and
it
provides
a
standardized
notion
of
identity
and
provides
these
well-defined
methods
for
proving
that
identity.
It
all
actually
also
provides
all
defined
methods
for
obtaining
that
identity,
but
those
bits
are
out
of
scope
for
this
talk
today.
A
This
is
what
a
smithy
ID
looks
like
it's:
a
structured
string,
essentially
models
URI,
which
represents
a
workloads,
identity
and
one
way
to
think
about
it.
It's
like
a
username
for
workloads
right
and
there's
two
components
of
this
thing.
The
first
is
the
trust
domain,
which
is
the
one
on
the
left
here
that
one
of
the
blue
underlined
and
then
the
second
one
is
the
path
with
a
green
underline
and
a
trusted
main
represents
a
the
security
domain
that
the
workload
is
residing
him.
A
So
one
example
might
be
staging
her
production
and
then
the
path
represents
the
name
of
the
workload
and
and
the
spivey
spec
we're
not
very
prescriptive
about
the
formation
of
this.
You
can
form
the
path.
However,
you
want
you
to
form
the
trust
I
mean.
However,
you
want
we're
only
specific
about
the
meaning
of
those
of
those
things.
A
So
next
up
we
have
what
we
call
an
identity
document.
It's
called
an
S
Vettes,
they
feed
verifiable
identity
document,
and
this
is
how
we
define
that
the
how
you
prove
the
identity
to
someone
else
right,
and
there
are
two
flavors
of
this
two
ways
to
do
it-
one
which
is
based
on
x.509
certificates,
one
which
is
based
on
JWT.
A
Now
to
create
these
s
fibs
and
manage
the
identities
associated
with
them,
you
need
some
sort
of
authority
and
a
service
mesh.
Usually
you
have
this
centralized
authority
is
the
most
common
way
to
do
it
and
this
responsible
not
just
for
creating
and
managing,
but
also
distributing
these
identities
throughout
the
mesh,
and
this
Authority
is
common
to
all
the
applications
and
all
the
proxies
that
live
inside,
that
everyone
kind
of
mutually
trust
it
and
trust
the
identities
that
it
creates
by
default.
A
But
this
raises
the
question:
what
happens
when
you
have
more
than
one
right
or
what
happens
when
you
have?
You
know
some
things
that
are
inside
of
some
things
that
are
outside
and
maybe
they
after
two
different
authorities,
so
that
the
Smithee
provides
these
things
clearly
needed
to
talk
to
each
other.
A
Rice
Biffy
provides
this
lingua
franca
over
which
they
can
communicate,
but
you
still
need
to
manage
these
authorities
right
and
what
are
the
right
ways
to
think
about
the
authorities
when
you
have
multiple
measures
or
you
have
this
kind
of
hybrid
deployment,
so
I'm
gonna
toss
this
to
Oliver
he's
going
to
talk
a
little
bit
more
about
the
challenges
that
pop
up
in
these
multi
mesh
configurations.
Awesome.
B
Thank
You
Evan,
okay,
when
talking
about
hybrid
and
multi
mash
examples.
What
are
the
use
cases
right?
We
can
think
about
a
lot,
but
there
are
three
typical
things
that
we
want
to
mention
here.
Suppose
I'm
running
an
operation
and
Alvin
is
running
another
we've
got
a
deal
and
we
want
to
feather
in
our
services.
How
do
we
do
that?
That's
a
first
use
case.
Second,
one
is
I'm
a
service
provider
and
I
want
to
expose
my
service
to
my
tenants.
B
I
get
a
bunch
of
different
tenants
on
to
secure
the
connection
with
them
and
allow
them
to
call
my
service
security.
The
third
one
would
be
I'm
say
running
a
big
company
that
is
using
pretty
old
infrastructure.
I,
don't
want
to
adopt
the
new
fancy
service
match
framework
I.
Do
that
gradually,
so
that
I
want
their
sources
running
in
the
mesh
in
the
new
mesh
to
be
able
to
still
work
with
their
services
in
the
old
infrastructure,
then
we
come
to
their
basic
rules.
B
You
need
to
consider
in
terms
of
the
security,
so
we
list
the
four
of
them
here.
So,
first
all
the
identities
and
must
be
derived
from
a
trusted
root
right.
You
don't
want
any
untrusted
PKI
the
usual
identity.
Is
that
pretending
to
be
some
identity
or
federated
Network?
The
second
way
is
trusting
me
associated
with
their
parties.
B
The
third
one
is,
of
course,
we
want
their
transport
plus
authentication
compatibility
compatibility
to
be
able
to
establish
their
authentication
between
the
message.
Fourth,
one
of
course
security
policies:
we
don't
want
any
unauthorized
services
coming
from
external
to
be
able
to
call
my
service
successfully.
B
Okay.
In
this
presentation,
we
are
going
to
focus
on
their
first
two
items
which
are
about
identities.
When
we're
talking
about
identity,
Federation's
may
be
their
simplest
idea,
camera
or
taste.
This
picture
you
share
the
common
route
right.
This
is
well.
This
is
common
in
big
organizations.
If
you
have
like
multiple
transformants
and
they
are
running
in
their
different
departments,
they
could
share
their
common
route
and
you
have
intermediaries
that
had
derived
from
the
common
route,
the
issue
certificates
for
the
workloads
in
the
corresponding
meshes
okay.
B
Well,
that
is
true
in
many
cases,
and
there
are
limitations
in
industry
in
depart.
Independent
parties
are
not
likely
to
share
the
common
with
you
right
and
the
second
one
is,
if
you
are
going
to
share
the
common
Lussier
you're,
still
facing
a
problem
that
your
mesh
Authority
are
different
from
the
rest
of
the
authorities
for
the
mesh
eternally.
B
Second
approach:
we
come
to
the
multipole
independent
authorities,
so
each
mesh
runs
a
single
read
stand-alone
Lussier
and
we
favorite
them
right.
This
solved
the
problem
of
the
common
rule
CA,
but
there
are
also
challenges
so,
first
of
all,
how
does
their
measure
is
securely
exchange
the
root
of
trust,
the
second
one
in
this
picture,
how
to
prevent
the
Lussier
2
from
issuing
the
identities
for
their
mash
rat
and
the
buzzer
vice
versa.
Right,
then,
the
solution
is
what
CB
fee
very.
A
Yeah,
so
this
cross-domain
communication,
where
different
authorities
are
involved
as
exactly
what
spiffy
Federation
is
designed
to
solve,
specifically
how
to
identify,
how
to
validate
identities
and
other
trust
domains.
And
to
do
this,
we
define
a
fairly
simple
API
and
I
quote
API,
because
in
the
end
of
the
day,
is
really
just
a
simple
HTTP
GET,
there's
not
anything
complicated.
A
Every
a
spiffy
trust
domain
exposes
an
endpoint
that
serves
this,
this
HTTP
request
and
we
call
that
the
spiffy
bundle
endpoint
and
when
you
call
that
endpoint
there's
a
document,
that's
returned
which
contains
the
authorities
public
keys.
This
provides
the
mechanism
for
exchanging
the
authority
information
between
each
other
once
these
keys
are
obtained
identities
from
that
trust,
I
mean
from
which
you
obtain
them
can
be
validated
using
those
keys.
A
So
spiffy
bundle
itself
is
just
a
shade
of
eks
document.
If
you've
ever
used,
o
ADC
before
it's
might
sound
familiar.
This
is
an
example
of
what
a
spiffy
bundle
looks
like,
and
this
is
what
is
returned
by
a
spiffy
bundle.
End
point-
and
you
know
see
in
this
example
that
both
estimate
types
are
represented.
I
have
alluded
before
that
both
tradable
ETN
x509
er
are
supported
by
spiffy,
but
obviously,
for
this
talk,
we're
talking
only
x.509
and
the
x5
c,
the
x5
seek.
You
can
see.
A
C
D
A
We
think
what
does
a
full
picture?
Look
like
it's
something
like
this,
so
we
can
see
that
there
are
two
authorities,
red
authority
and
green
Authority,
and
each
Authority
provides
identities
for
applications
and
proxies
of
those
in
their
respective
trust,
image
or
service
meshes,
but
they
also
exchange
information
with
each
other
via
fifteen
Federation
and.
C
A
Information,
the
public
keys
of
the
authority
are
also
propagated
down
to
the
applications
and
the
proxies,
and
this
allows
them
to
authenticate
identities
of
workloads
which
are
it
not
other
domains.
So
you
know
when
the
workload
and
the
read
domain
encounters
a
workload
that
has
an
identity
from
the
green
domain.
It
has
the
keys
necessary
to
validate
that
identity.
A
So
this
is
how
smoothly
Federation
works
kind
of.
In
a
nutshell.
Today
we
will
show
you
how
spiffy
Federation
works
in
action
between
an
STI
deployment
and
respire
deployment.
On
the
case,
you
have
not
familiar
with
either
these
projects.
This
do
is
a
full-blown
service
mesh
that
provides
all
those
fancy
bells
and
whistles
that
we
showed
earlier,
but
under
the
hood
at
use
is
also
spiffy
for
identity.
A
A
C
A
Is
the
one
which
exposes
the
bundle,
endpoint
server
and
also
a
bundle
endpoint
client
to
fetch
bundles
from
other
trust,
commands
now
the
right
hand
side?
We
have
spire
deployment,
and
this
is
just
spires
deployed
just
on
regular
VMs,
there's
no
kubernetes
or
mesh,
or
anything
like
that.
There
is
a
proxy,
but
it
is
not
there's
not
as
far
far
from
managed
the
same
way
that
the
work
was
in
this
dealer
and
on
the
spire
side
to
aspire
server,
which
is
at
the
top
there.
A
Built-In
has
spiffy
bundle,
endpoint,
server
and
client
spire
and
the
right
hand
side
acts
as
the
identity
issuer
for
the
spire
deployment
and,
on
the
left,
hand,
side.
There's
component,
and
this
do
calls
to
the
dough
which
acts
as
the
issuer
authority.
For
this
do
so,
some
keen-eyed
folks
in
the
audience
might
be
wondering
exactly
how
this
particular
connection
in
the
middle
is
managed
and
authenticated.
I
mentioned
earlier
that
this
connection
uses
this
regular
HTTP,
which
means
that
we
can
use
certificates
from
a
public
CA
to
secure
just
secure
that
connection.
A
There's
no
client
authentication
or
anything
like
that,
but
sometimes
it's
not
practical,
or
it's
not
desirable,
to
use
public
CA
for
this.
Instead,
in
this
demo
we're
using
spiffy
authentication,
which
is
nice
because
it
doesn't
rely
on
an
external
authority
to
issue
those
certs,
but
the
downside
is
that
it
does
require
an
operator
to
supply
the
CA
certificates
in
order
to
bootstrap.
This
connection
now
I'll
note
that
while
an
operator
has
to
apply
the
CA
certificates
to
be
strap
this
connection,
it
only
happens
once
it's.
A
D
B
All
right,
oh
good,
so
first,
let's
introduce
the
setup.
We
do
have
two
VMs
that
are
set
up
for
running
the
spire
server
and
the
spire
agents,
plus
the
workload
right
on
the
right
side.
We
do
have
a
terminal
that
is
controlling
their
kubernetes.
Sorry,
the
e
steel.
So
if
I
do
get
part,
II
still
system,
you
can
see,
I
have
pre-installed
there,
you
still
can't
open
in
there
and
beyond
that.
I
do
have
ifs
right.
This
is
a
new
thing.
Okay,
so,
first
of
all,
let's
start
this
by
a
server
on
their
left
side.
B
Evan
has
putas
put
up
all
those
nice
scripts
for
me
so
that
I
can
run
them.
Okay,
ignore
the
error
message
here:
I,
don't
think
that
matters,
and
then,
let's
run
the
spire.
Sorry
sprite
it
okay.
So
now
both
the
server
and
the
agent
are
running
server.
Is
there
just
double
check
agent?
Is
there
let
me
bring
up
their
workload
as
the
next
step:
zero
three
start
workload:
okay,
the
workload
it
started
listening
under
8
for
force
really
hard
on
this
VM.
B
So
now
what
I'm
gonna
do
is
I'm
going
to
deploy
a
sleep
pod
in
there
sto
side,
which
is
cluster
1
and
use
it
to
call
to
the
VM.
So
I
do
have
this.
Let
me
see
and
foo.
Ok,
it's
it's
going
up.
Ok,
no,
it's
not
and
I
do.
I
did
also
configure
the
service
entry
you
still
to
route
the
traffic
to
the
external
IP
address.
This
is
the
external
part,
and
this
is
the
service
name.
I'm
calling
match
internal
means.
B
B
B
B
B
No!
It's
good
I
have
copied
that
into
this
spire
and
then
next,
what
I'm
gonna
do
is
to
copy
out
their
certificate
out
of
spire
all
right.
This
one
gives
me
their
certificate
and
configure
that
into
my
easter
cluster.
So
what
I'm
gonna
do
is
now
I'm
going
to
write
this
into
a
file.
Okay,
this
is
the
new
one
and
then
I
put
this
file
into
the
system.
Using
configure
terrific
map
deploy
can
take
a
map.
B
B
B
B
B
Food
is
color
here
we
do
have
some
workarounds
there,
because
this
is
just
a
prototype.
What
we
are
doing
here,
I
want
to
mention,
is
not
the
final
ultimate
solution.
We
are
working
on
the
final
solutions,
but
it
will
be
greatly
be
nicer
and
their
user
experience
really
will
be
much
better.
Ok,
so,
but
I
want
to
briefly
talk
about
what
we
did
so.
B
First
of
all,
we
define
the
service
entry
on
a
pilot
right
to
define
the
service
name
service,
name,
microservice
thought
cluster
2,
dot
global
and
with
their
eastern
IP
Pilar
takes
that
and
extracts
the
cluster
2
in
the
middle
and
then
put
that
as
a
validation
contest.
As
the
ass
name
on
the
right
side,
there
is
T
of
Federation
service
takes
this.
B
Consumes
this
config
map
the
config
map,
it's
I
can
figure
that
using
their
trust,
the
root
key
of
their
aspire
server
and
configure
that
to
IFS,
so
that
is
s
is
able
to
authenticate
their
spire
server
right
what
ifs
retrieves
the
new
transponder.
It's
also
updates
this
config
map
so
that
this
config
map
is
always
reflecting
the
route
of
trust
for
cluster
to
this
wide
consumed.
Also
by
the
node
agent
know
the
agent
which
sees
this
config
map.
B
This
proxy
is
using
its
own
certificate,
which
is
signed
by
sailrite
to
get
authenticated
by
the
other
end.
This
is
muted.
Your
s.
Ok,
one
candidate
here
is:
we
are
able
to
make
a
call
from
castor
what
across
or
to
now,
and
we
are
working
on
implementation
to
enable
the
other
the
other
way
from
closer
to
across
the
way.
It's
what
will
progress?
Ok,
I
think
that's
that's.
A
Links
up
here
feel
are
interested
in
learning
more
about
what
we've
done
or
how
this
works
on
the
left
at
the
top
is
the
sto
resources.
If
you
look
to
join
this,
do
community
or
checkout
github
on
the
top
right
is
the
spire
resources
for
a
spiffy
spire
community.
Please
feel
free
to
join
us
Lanka.
Everyone
is
welcome
to
join
we'd
love
to
have
you
there
and
then
on.
A
B
E
Maybe
I
missed
it,
but
you
mentioned
that
the
certificate
minted
by
the
red
or
green
I
forgot,
one
could
not
be
used
or
one
CA
in
green
could
not
mean
certificate
as
if
it
was
coming
from
red.
So
this
mutual
deal
has
at
least
in
demo,
I
couldn't
figure
out
where
it
actually
checked
that
the
certificate
was
signed
by
the
other
party.
Yes,
you.
B
So
for
this
demo,
specifically,
we
are
using
it
CVS
to
control
which
cluster,
which
endpoint
is
using,
which
trust
bundle
right.
Remember
the
CDA
is
pointing
to
cluster
to
cluster,
to
only
has
the
transponder
for
cluster
to
which
is
VM,
so
that
you
want
to
use
like
your
any
other
like
transponder,
to
authenticate
cluster
to
and
for
the
listener
side
we
are
still
implementing
that.
We
need
to
do
a
mapping
check
to
check
their
identity
to
trust
potency,
but
trust
domain
specifically
in
your
identity,
actually
matches
their
transponder
that
we
use
to
authenticate.
A
Say
in
another
way,
the
the
left
side
is
deicide
matches
on
a
host
header
and
from
the
host
header.
Lookup
knows
this
is
something
and
trusts
domain
to
or
trust,
remain,
read
or
whatever,
and
then
picks
up
the
bundle
to
use
for
that
outbound
connection
for
server
validation
on
the
right
side.
We
use
ghost
tunnel
proxy
which
understands
how
to
introspect
client
certificate
to
pull
the
trust
domain
out.
A
B
D
Hi,
so
this
was
some
really
good,
walkthrough
fruit
through
the
mutual
TLS
side
of
this
I'm,
just
wondering
how
does
like,
if
you
have
an
authentication
policy
and
you're
in
your
cluster
and
you're,
trying
to
do
like
authorization
right
within
your
services?
How
might
this
work
with
authorization
policies
if
you
want
to
allow
an
identity
from
one
cluster
into
the
other
cluster
through
those
policies?
Is
that.
B
You
are
talking
about
authorization
policies
specifically
easier
right,
so
we
are
working
on
that
to
support
internal
right
and
it
is
basically
we
are
for
the
authorization
policies
you
encode
their
identities
as
the
streams
for
you
to
check
those
streams
can
be
including,
including
everything
it's
includes
their
trusted
me
as
well.
So
now
it's
already
supported
I
think
you
just
put
your
trust
them
in
there.
As
long
as
it
passes
through
their
authentication
part,
it
gets
their
external
identity.
You
can
define
whatever
authorization
policy.
Is
there,
so
there's
no
problem.
B
C
A
Server
the
proxy
on
this
on
the
spire
side
is
approximate
cause
tunnel,
which
is
an
I
probably
should
have
linked
to
here.
It's
on
this,
where
organization
on
github
square
slash
ghost
tunnel.
It
is
a
very,
very
simple,
MPLS
proxy
that
operates
at
layer
3
for
who
does
not
layer
7.
That
proxy
knows
how
to
speak
directly
to
so.
If
you
work
with
API
and
also
knows
how
to
do
the
federated
validation,
that
spiffy
requires
four
different,
different
bundles,
but
dot.