►
From YouTube: Service Identity - The Key to Zero Trust with Service Mesh - Matthew Bates & Joshua Van Leeuwen
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
Service Identity - The Key to Zero Trust with Service Mesh - Matthew Bates & Joshua Van Leeuwen, Jetstack
Service mesh provides first class support for service identity, foundational to identity-based, Zero Trust security that is now of growing interest and importance in the enterprise. In this talk, Matt and Josh will explain the concepts of service identity, such as SPIFFE, and illustrate through example how the various mesh technologies are architected, as well as how they implement the principles of service identity to provide seamless mTLS between workloads. The talk will help Platform and Security teams as they think about identity for workloads, how it's used within the mesh and beyond, and importantly, how this may can interoperate with enterprise PKI infrastructure.
A
Hi
everybody
thanks
for
joining
our
talk
today
this
year.
It's
of
course
it's
virtual,
so
we
don't
get
to
see
all
of
you
in
person,
but
we're
hoping
this
time
next
year
there
will
be
an
eu
cube
con
when
it's
safe
to
travel
and
look
forward
to
seeing
everyone.
Then,
today
we're
going
to
be
talking
about
service
identity
and
how
pretty
much
it's
it's
fundamental
to
achieving
zero
trust
in
a
cloud
native
environment.
I'm
matt,
I'm
from
jet
stack
just
like
josh
he's
joining
me
today.
A
A
We've
worked
with
many
companies
who
have
adopted
cloud
native
from
you
know,
some
from
startups
to
some
of
the
largest
enterprises
and
along
the
way,
we've
contributed
to
open
source
upstream
and
we've
also
open-sourced
a
number
of
projects
and
we're
probably
best
known
for
the
the
cert
manager
project,
which
we
originally
created
and
now
work
on
with
lots
of
contributors
in
the
community.
It's
and,
of
course,
it's
now
a
cncf
project
as
well
josh
I'm
joined.
B
B
A
Thanks
josh,
so
today
we're
going
to
be,
as
I
said,
looking
at
xero
trust.
Of
course.
Zero
trust
is
it's
quite
a
buzzword,
but
we're
going
to
look
at
it
specifically
in
the
context
of
cloud
native
and
what
it
means
for
kubernetes
and
also
what
it
means
in
a
service
mesh
how
you
can
use
how
you
can
achieve
xero
trust
using
the
identity
management.
A
The
service
mesh
provides
we're
gonna,
be
also
looking
at
how
you
can
plug
in
set
manager,
we're
behind
the
project
and
we've
been
working,
she'll,
say:
wait.
Yeah
josh
has
been
working
on
some
of
the
integrations
that
tap
into
managing
certificates
and
providing
those
to
to
the
mesh,
and
we've
got
a
number
of
demos
as
well.
So,
let's
get
going
so
briefly
to
start
we're
going
to
introduce
the
concepts
of
xero
trust
in
the
context
of
cloud
native,
so
in
traditional
network
security.
A
It's
all
very
much
about
having
you
know,
layers
of
security
yeah,
a
defense
in
depth,
if
you
like,
in
order
to
protect
really
the
most
sensitive
services
and
the
model
is
really
based
around
protecting
protecting
networks
from
external
attackers
and
yeah.
Often
this
gets
described
as
the
castle
remote
approach
in
which
everything
inside
is
trusted.
You
know
everything
once
you
once
you're
in
the
castle
effectively
you're
trusted,
but
this
really
overlooks
really
the
threat
of
insider
attack,
and
you
know
there
have
been
a
number
of
high-profile
cases
where,
where
breaches
have
occurred,.
A
It's
let's
say
that
the
traditional
model
of
securing
application
networking
is
really
very
much
based
on
infrastructure
that
that
changes
very
infrequently
it's
static.
We
rely
on
fixed
ip
addresses,
ports,
access
control,
lists
firewalls
and
in
a
world
of
cloud
native
this
this
becomes
highly
challenging.
And
why?
Because
you
know,
we've
got
clusters
in
different
clouds
on
different
networks
and
virtual
networks.
A
Even
and
the
workloads
that
run
in
those
clouds
and
clusters
are
really
highlight
highly
dynamic
and
ephemeral,
and
some
are
very
short-lived,
some
much
more
longer-lived
and
it's
not
just
kubernetes
right.
You
know:
we've
got
functions
here:
serverless
standard
virtual
machines
and,
of
course,
infrastructure
on-premise
that
we
also
need
to
integrate.
So
it's
clear
that
the
sort
of
perimeter-based
approach
really
just
doesn't
fit
and
it
doesn't
scale
and
it's
incompatible
with
really
how
we're
building
and
and
deploying
software
today.
A
So
instead,
what
we're
going
to
move
to?
Where
we,
where,
where,
of
course
the
industry
is
moving
to,
is
a
model
where
effectively
the
network
is
completely
untrusted
and
there
is
no
implicit
trust,
you
know
you
cannot
trust
another
service
yeah
that
doesn't
mean
giving
up
on
the
defenses,
of
course,
at
the
perimeter
right,
but
now
we're
assuming
that
the
attackers
could
well
be
in
our
network.
They
are
in
our
networks,
and
that
means
making
sure
that
all
communications,
the
service
to
service
calls
are
secure.
A
I
mean
encrypted
on
the
wire,
but
also
that
the
services
are
able
to
authenticate
to
each
other
and
that's
each
and
every
service,
each
and
every
time.
So
how
do
we
do
this?
Well,
it
means
each
of
this
has
to
be
able
to
identify
itself
and
we're
talking
here.
You
know
a
cryptographically,
verifiable,
unique
identity
and
that
it
can
attest
and
with
identity
we
can
authenticate
between
services.
A
You
know
once
we've
got
that
we
can
also
begin
to
make
authorization
requests.
You
know
we
understand
the
service
who
it
is
and
we
can
make
a
decision
about
what
that
service
is
requesting.
You
know,
for
instance,
can
this
type
of
request
be
made
by
this
service
yeah
accessing
a
some
particular
resource,
for
instance,
and
we've.
A
But
this
is
the
service
measures
are
incredibly
incredibly
convenient.
They
they
take
away
a
lot
of
what
a
developer
would
typically
do
and
they
do
yeah,
and
we
know
we're
developing
developing
things
like
this.
It's
quite
easy
and
to
get
security
wrong
and
so
service
mesh
is
really
convenient
because
they
take
away
a
lot
of
this
difficult,
complex
implementation
and
put
it
into
if
you
like,
the
network
layer
and
enable
it
to
be
programmable.
B
So
what
this
means
in
terms
of
connections
is
say,
service,
a
wants
to
talk
to
service
b
or
service.
A
will
open
up
that
connection
that
will
get
intercepted
by
the
proxy.
That
proxy
will
then
connect
to
service
b's
proxy
and
then
assuming
that
connection
is
okay.
That
traffic
will
then
get
forwarded
on
to
to
service
b.
B
So
if
you
talk
about
or
if
we
think
about
what
network
flow
would
look
like,
so
when
these
services
boot
up,
they
request
these
crypto
bundles
from
the
control
plane
of
the
of
the
mesh
they're
running
in
so
inside.
These
crypto
bundles
and
can
contain
the
root
of
trust
of
the
mesh,
along
with
a
sign
certificate
which
will
contain
their
machine
identity
inside.
B
B
B
The
client
will
then
verify
the
contents
of
that
certificate.
So
it's
going
to
verify
that
it's
been
signed
by
the
root
of
trust
that
it's
expecting
and
also
that
the
identity
matches
that
which
it
which
is
expecting
and
also
make
networking
decisions
here,
and
it
can
also
make
you
know
authorization
to
decisions
here
based
on
the
identity
it
receives.
B
So
it's
also
going
to
challenge
the
kind
of
contents
of
that
certificate.
So
it's
going
to
make
sure
that
the
server
speed
proxy
also
owns
that
certificate
it's
presenting,
so
it
also
holds
the
private
key,
and
if
it's
happy,
it's
also
going
to
send
the
server
the
its
own
client
certificate
and
that
process
is
is
going
to
repeat
so
what
you
get
here
is
you
know.
In
the
normal
case
of
the
case
of
normal
tls,
the
client
is
going
to
verify
that
the
server
certificate
matches
what
it's
expecting.
B
B
So
if
you
take
a
bird's-eye
view
of
how
this
looks
like
you
see
that
the
control
plane
component,
which
I
was
mentioning
earlier,
is
responsible
for
delivering
these
bundles
to
the
workloads
on
boot
and
on
renewal.
So
if
we
take
istio's
case,
which
we
have
here,
it's
the
cisterdale
component,
which
is
responsible
facilitating
sending
these
crypto
bundles.
So
it's
the
citadel.
It's
going
to
be
signing
these.
B
These
certificates,
which
contain
the
identity
of
each
service,
the
kind
of
identity
of
each
service
you
know
in
the
kubernetes
world
is
typically
done
by
the
service
account.
So
on
boot,
the
kind
of
service
a
for
example,
will
send
a
request
using
the
service,
a
service
account
at
cisadell.
It's
going
to
you
know
verify
that
service
account
is
signed
by
the
api
server
and
then
it's
going
to
assign
a
a
certificate
to
send
back
to
the
server
state
proxy.
B
The
way
the
identity
is
encoded
in
the
x5
x509
certificate
is
either
done.
You
know
by
dns.
Let's
say,
or
in
the
istio's
case,
through
spiffy
through
through
uri,
especially,
is
a
framework
for
for
effectively
encoding
identities
into
kind
of
identity
documents.
So
in
the
case
of
x509,
this
is
actually
just
a
string
in
the
in
the
uri
sans
part
of
the
certificate,
and
it's
encoded
like
you
see
here,
so
you
have
the
trust
domain.
B
So
in
this
case
it's
cluster
local,
but
that
could
be.
You
know
europe
west,
one
europe
west,
two
mesh,
two.
What
have
you
and
then
followed
by
you
know
whatever
makes
sense
in
the
context
of
the
kind
of
trust
domain
that
is
that
it's
operating
in
so
again
in
the
kubernetes
world.
This
is
the
service
account,
so
it'll
be
followed
by
the
you
know.
A
We're
now
going
to
look
at
how
service
identity
works
with
a
number
of
different
service,
mesh
implementations
and
we've
got
three
and
we're
going
to
look
at
them
briefly
and
we're
going
to
show
you
a
bit
of
a
demo
so
just
to
to
start
with
we're
going
to
look
at
istio.
So
this
is
the
architecture
of
istio,
specifically
focusing
in
on
sort
of
the
components
that
are
used
here
for
security
controls
and
to
to
point
out
here.
Eco
in
its
control.
A
Plane
has
something
called
a
component
called
the
citadel
it's
now
part
of
stod,
and
that
is
effectively
responsible
for
providing
the
the
x509
the
tls
certificates
to
the
proxies
the
in
this
case,
the
envoy
based
proxies
and
now
out
of
the
box,
it's
self-signed,
and
so
it
has
a
self-signed
ca
and
you
know.
Actually,
you
know
you
can
really
just
sold
it
up
and
use
it,
as
is.
A
B
Thanks
matt,
so
what
I
have
here,
I
have
two
certificates
already
installed
inside
the
cluster,
so
I
have
a
root
ca,
which
is
the
root
of
my
pki.
This
typically
would
live
offline
from
the
cluster,
but
I
have
it
installed
here,
and
I've
also
minted
an
intermediate
difficult
authority
which
is
going
to
be
used
as
the
root
of
trust
for
my
istio
mesh
that
I'm
about
to
install
so
the
first
step
for
using
this
intermediate
kind
of
custom,
with
the
with
istio
that
I
need
to
extract.
B
B
So
when
I
install
istio
here
since
that
secret
is
already
available,
sdod
is
going
to
read
those
files
from
disk
because
it's
mounted
from
the
secret
and
then
it's
going
to
use
those
you
know
keys
and
certificate
and
ca
et
cetera
as
the
kind
of
signing
kind
of
ca.
So,
what's
going
to
happen,
then,
is
all
workloads
in
the
mesh
when
they
request
their
crypto
bundles
from
the
control
plane.
They're
going
to
be
signed
from
that
intermediate
that
we've
minted
here.
B
A
Thanks
josh,
that
was
great
to
see
we're
now
going
to
move
on
to
linkedin.
Linkedin,
of
course,
is
a
service
mesh.
That's
in
the
cncf
very
similar
architecture
here,
or
certainly
has
a
control
plane.
Has
a
data
plane
somewhat
different,
of
course,
in
the
the
proxy
is
not
envoy.
It's
a
rust
based
envoy,
the
linkedin
proxy,
but
it
also
has
a
component
in
its
control
plane,
much
like
seo.
A
B
All
right
so
next,
I'm
gonna
be
installing
the
link
d
mesh
with
a
custom
root
ca.
So
again,
I
I
have
the
root
of
my
pki
living
inside
the
cluster.
Again,
this
would
normally
live
offline
somewhere.
I've
also
minted
an
intermediate
ca
from
that
route,
which
I'm
going
to
be
using
as
the
root
of
trust
for
my
linkedin
mesh.
B
All
right
so,
once
again
just
what
we
did
with
this
j,
I
want
to
verify
that
the
identities
that
are
provided
to
the
services
running
in
my
linkedin
mesh
those
were
expecting
and
and
signed
by
the
ca
intermediate
that
we
minted
earlier.
So
again,
I'm
deploying
the
kind
of
dummy
services
and
this
time
I'm
going
to
do
the
trick
and
the
other
way
around
so
from
the
htm
proxy.
B
I'm
going
to
open
the
dls
connection
onto
the
sleep
pod
and
if
we
grab
out
this
the
certificate
which
was
returned.
I
can
see
here
that
the
certificate
was
indeed
signed
by
the
intermediate
that
we're
expecting
there
from
the
issuer
and
the
certificate
itself
can
contain
the
dns
in
the
form
that
we're
expecting
of
the
kind
of
pod
identity
that
we're
connected
to.
So
in
this
case,
it's
dns
and
indeed
it's
the
sleep
service
account
which
was
determined
as
the
identity.
A
A
It's
in
the
sandbox,
just
like
cert
manager-
and
this
is
a
project
from
microsoft-
also
uses
envoy
as
its
as
its
data
plane
in
its
data
plane,
and
it
actually
has
a
component
built
into
it
so
from
the
get-go
it
had
support
for
certificate
management
and
that
we
were
responsible
for
kind
of
generating
those
dev
kits
and
also
distributing
it
across
the
across
the
mesh,
and
we
actually
worked
quite
early
on
with
the
project
to
integrate
it
directly
with
cert
manager.
So
you
can,
you
can
use,
I
believe,
actually
called
volts.
A
B
So
I
actually
have
an
issuer
installed
in
the
cluster
which
is
backed
by
that
intermediate
ca,
and
what
this
means
is
that
the
control
plane
well,
not
only
the
control
plane
of
open
service
mesh,
but
also
the
workloads
running
in
the
open
service
mesh
or
request
the
certificates
via
stiffer
request
resources
which
are
certain
manager,
resources
and
so
the
issuer
that
they
reference
will
go
ahead
and
sign
those
resources.
And
what's
the
nice
thing
about
this,
is
that
the
cert
manager
issuer,
which
is
which
is
referenced
by
open
service
mesh?
B
B
So,
lastly,
once
again,
I
want
to
verify
that
the
services
that
I
deployed
to
my
overso
open
service
mesh
cluster,
their
identities,
are
indeed
signed
by
the
intermediate
ca
that
we
minted
earlier
and
as
well.
The
identities
are
matching
what
we're
expecting
them
to
be
so
again,
I've
deployed
these
dummy
services
and
I'm
going
to
be
using
the
open
service
mesh
cli
to
dump
out
the
proxy
configuration
of
our
sleep
pod
here
and
we
check
the.
B
If
we
grab
out
the
kind
of
certificate
which
was
dumped
out,
we
can
see
again
that
the
certificate
was
signed
issued
by
the
intermediate
that
we
mentioned
earlier,
and
the
identity
which
is
contained
within
that
sleep
certificate
is
the
identity
of
the
sleep
service
account.
So
in
the
open
service
mesh
case
is
represented
in
dns,
and
you
can
see
here
that
it's
the
sleep
service
account
and
the
default
name
space
in
the
cluster,
local
trust.
A
It's
really
really
neat.
We
should
probably
are
thinking
about
this.
We
should
probably
open
source
those
demos,
josh
yeah,
let's
try
and
let's
try
and
make
that
happen
in
time
for
the
event
yeah.
Of
course,
it's
worth
pointing
out
that
there
are
other
meshes,
so
many
many
meshes
out
there
and
we
had
limited
time
today.
A
So
what
we've
shown
of
three
and
those
you
know
for
the
most
part
they
you
know,
of
course,
support
spiffy
identity
and
the
spiffy
identity
that
josh
spoke
about,
but
there
are,
there
are
others,
and
you
know
there
are
a
number
of
them
here
that
many
of
you
will
be
possibly
familiar
with
already
and
just
worth
pointing
out.
There
are
also
some
sort
of
mesh
like
implementations
out
there,
and
specifically
here
we've
got
one
called.
A
A
Else
really
with
mesh.
You
know
the
mesh
provides
the
means
to
be
able
to
automate
those
short-lived
certificates
more
often
than
not
with
spiffy
and
distribute
those
the
proxies
in
order
for
that
mutual
tls.
That
josh
spoke
about
to
be
established
between
services
and
in
most
cases
this
is
this
is
transparent
to
the
application
developer.
You
know
it's
completely
built
into
the
platform,
it's
not
something
they
need
to
do
themselves.
A
You
know
a
number
of
the
meshes
provide
the
ability
to
to
be
extended,
so
you
can
actually
start
sort
of
plugging
in
intermediates,
as
we
demonstrated,
meaning
that
you
can
actually
integrate
this
into
an
existing
enterprise
chain
of
trust
and
there's
certainly
more
to
do
in
this
space,
and
you
know
we're
involved
in
some
of
that
with
the
various
projects,
but
it's
certainly
great
to
see
where
we
are.
We
already
are
and
what's
possible,
so
we
look
forward
to
the
live
q,
a
thanks.
Everyone
for
joining
us
today.