►
Description
Istio: Sailing to a Secure Services Mesh [I] - Spike Curtis, Tigera & Dan Berg, IBM
Istio is an open platform that provides a uniform way to connect, manage, and secure microservices. In this presentation we describe the security features of the Istio service mesh: how it helps you secure service-to-service communication across clouds without application code changes, provide robust identity and strong authentication, and enforce powerful authorization policies for your applications. We discuss the current project status and look ahead to the roadmap for security features.
About Dan Berg
As a Distinguished Engineer within the IBM Cloud unit, Daniel is responsible for the technical strategy, and implementation of the containers and microservices platform available in IBM Cloud. Within this role, Daniel has deep knowledge of container technologies including Docker and Kubernetes and has extensive experience building and operating highly available cloud-native services. Daniel is also a core contributor to the Istio service mesh project.
About Spike Curtis
Spike Curtis is a lead developer on Istio working for Tigera. He was also a core developer for Calico and worked on the initial integrations with Docker, Kubernetes and Mesos. Spike earned his PhD from the University of Oxford where he worked on quantum computing with ion traps. He has also worked for Silicon Valley start-ups Palantir Technologies and Rigetti Computing.
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
So
what's
the
problem
that
we're
all
trying
to
solve
right,
we're
we're
moving
towards
highly
distributed
systems
and
those
systems,
especially
moving
into
the
cloud,
are
complex
right,
they're
complex
to
monitor
they're
complex,
to
manage
they're
complex
to
secure.
Why
is
that?
Well
we're
dealing
with
all
kinds
of
problems
in
our
code
we're
dealing
with
network
problems
dealing
with
lapses
in
the
network
itself.
How
do
we
deal
with
that
we're
building
in
retries?
In
our
logic,
we're
dealing?
A
What
we're
building
in
retries
fault
injections,
directly
into
our
code,
we're
dealing
with
authentication
issues,
authentication
authorization
so,
but
we're
as
developers
we're
building
that
into
each
of
our
services
we're
building
that
into
our
code,
so
every
single
one
has
their
own
mechanism
their
own
complexities.
For
dealing
with
that.
How
do
you
even
observe?
What's
going
on
in
these
highly
distributed
systems,
so
even
understanding
the
services
how
they
communicate?
What
are
the
lapses
in
the
security
in
the
network?
A
It's
very
difficult,
it's
very
complicated,
so
fault
tolerance
as
well
is
another
issue
that
dealing
with
a
highly
distributed
system.
You
have
to
assume
that
every
single
one
of
the
components
in
your
system-
it's
gonna,
fail.
It
will
fail
eventually.
So
how
do
you
build
in
that
fault,
tolerance
again
as
developers
you're
building
that
into
your
code,
you're
building
that
into
the
logic
and
it's
very
inconsistent
and
at
the
end
of
the
day
you
got
to
deliver
these
changes.
A
Your
operations,
you
have
to
deliver
into
these
highly
distributed
environments
into
multiple
different
clusters,
multiple
different
clouds.
You
need
to
reduce
the
risk
as
you're
delivering
that
end
and
it's
very
complicated
to
do
that.
So
how
do
we
do
this?
What
is
the
service
mesh
that
we
do
this
within
it?
What
we
use,
what
we
work
on
is
sto
and
unless
you've
been
in
a
vacuum
during
this
conference,
or
you
just
arrived
this
morning,
this
may
be
the
first
time
you've
heard
of
this
do,
but
hopefully
this
is
probably
the
hundredth
time.
A
A
Ultimately,
it's
to
deal
with
the
problems
that
we
just
discussed
here,
but
in
the
end,
it's
about
resiliency,
resiliency
and
efficiency.
Dealing
with
how
do
you
ensure
that
each
of
your
services
can
communicate
and
can
communicate
well
and
deal
with
failures
in
your
environment?
How
do
you
manage
because
it's
so
distributed?
You've
got
a
lot
of
micro
services.
You've
got
a
lot
of
services
in
your
environment.
How
do
you
manage
the
operations
around
them
and
we
want
to
move
instead
of
individual
configurations
of
each
of
your
services?
A
You
need
the
visibility
in
your
environment,
so
sto
provides
that
fleet
wide
visibility
into
all
the
services
that
are
available
in
your
environment
and
the
policies
for
managing
those,
and
definitely
you
have
to
have
security
by
default,
and
you
need
that
security
distributed
down
to
the
endpoints.
So
we
want
to
ensure
that
with
this
do
all
of
your
services
are
always
secure
from
day.
A
One,
and
a
lot
of
this
is
moving
moving
the
complexity
that
we
talked
about
earlier
from
your
code
and
moving
that
out
of
the
code
and
distributing
that
down
to
the
to
the
mesh
down
to
the
endpoints.
So
let's
take
a
look
at
this:
do
what
it?
What
is
the
architecture
of
this
do?
Most
of
you
probably
you've
seen
this
so
we'll
go
through
this
very
quickly.
Sto
is
distributed
into
two
main
sections:
there's
a
control
plane
and
there's
a
data
plane
and
the
control
plane
is
the
api's
of
the
management
of
that
of
sto.
A
It
has
three
main
components:
pilot
which
is
used
for
managing
the
routing
of
your
environment.
Routing
between
your
services,
mixer
mixer,
is
responsible
for
collecting
the
telemetry,
the
metrics.
It's
also
responsible
for
managing
the
policy,
the
fleet,
wide
policy,
enforcement's
and
definitions.
An
sto
auth
is
responsible
for
providing
the
security,
the
Identity
Management
and
the
security
of
your
services,
the
mutual
TLS,
and
that
is
all
used
to
control
and
manage
the
the
functionality
and
the
data
plane.
A
The
data
plane
is
where
your
applications
actually
run,
where
your
containers,
where
your
pods
actually
run
in
your
environment
and
the
way
sto
works,
is
we
inject
a
sidecar
which
is
built
and
built
using
the
Envoy
technology,
and
it
provides
that
control
point
that
we
use
for
communicating
from
one
service
to
another
service
and
it's
all
programmed
using
the
control
plane
the
components
in
the
SCO
control
plane.
So
that's
the
general
architecture.
We
don't
want
to
go
to
much
more
detail
in
it.
A
B
So
the
sort
of
my
favorite,
the
big
mainline
feature
that
we've
gotten
into
is
do
around
security.
Is
the
ability
to
set
up
mutually
authenticated,
TLS
connections
for
all
of
the
workloads
in
the
service
mesh?
What
that
means
is
that
you
can
turn
this
on
and
without
making
any
changes
to
your
application
code.
You
can
encrypt
the
data
and
authenticate
both
ends
of
the
connection.
We
do
this
in
a
really
standard
way,
its
standard
TLS
and
we're
doing
indication
not
only
of
the
server
side
but
also
the
client
side.
B
B
So
we
do
that
with
a
component
called
sto
CA
and
it
is
compliant
with
the
spiffy
protocol,
which
is
a
set
of
standards
that
we
are
currently
developing
along
with
the
rest
of
this
50
community.
Basically,
this
is
a
way
to
standardize
the
way
we
identify
workloads
in
our
environment,
so
each
workload
gets
a
spiffy
ID.
B
We
mint
a
certificate
and
then
put
that
into
the
workload
now
in
kubernetes
today,
we're
using
cooper-cooper
any
secrets
to
mount
those
certificates
and,
in
other
workloads
like
VMs,
we'll
have
a
node
agent
that
will
securely
deliver
the
certificates
to
the
workload
once
we
actually
have
those
certificates,
then
envoy
is
responsible
for
bringing
up
the
encrypted
connection
and
authenticating
both
ends,
and
we
also
do
a
secure
naming
check.
So
when
you
make
a
connection
to
another
pod
in
in
the
mesh,
we
know
what
what
the
service
is,
that
you're
trying
to
connect
to.
B
We
examine
the
kubernetes
api
to
know
what
service
accounts
are
actually
running
that
service
and
make
sure
that
the
pod
that
we're
connecting
to
is
actually
one
of
the
ones
that
that
is
running
your
service.
So
we're
doing
a
secure
naming
check
is
what
we
call
it
to
make
sure
that
you're
talking
to
a
legitimate
authority
for
the
service
that
you're
trying
to
reach.
B
B
So
the
mutual
TLS
gives
you
the
encryption
piece
and
the
authentication
piece
which
is
figuring
out
who
you're
talking
to
in
order
to
build
a
secure
system.
You
also
need
an
authorization
component,
so
not
just
knowing
who
you're
talking
to
but
being
able
to
answer.
The
question
you
know
should
I
be
allowing
that
request,
and
so
in
the
sto
architecture.
We
use
mixer
for
this.
B
If
it's
okay,
then
it
passes
that
request
on
to
the
back
end,
which,
on
to
your
service,
which
serves
up
the
response,
if
not,
then
it
returns
a
403,
and
we
do
a
lot
of
caching
here.
So
it's
not
like
this
is
happening
on
every
single
request.
There's
a
cache
that
your
local
envoy
is
keeping
and
then
mixer
will
return
back
an
answer
and
another
request
comes
in.
That
has
the
attributes
that
were
used
to
render
that
decision.
The
same
then
it'll
just
make
the
same
decision
and
not
pass
it
on
to
mixer.
B
Mixer
is
also
used
for
telemetry
and
the
reason
that
I'm
bringing
telemetry
up
in
a
security
talk,
in
addition
to
like
the
operational
concerns
that
you
have
adjust
to
being
able
to
debug
your
application.
Observability
is
super
important
from
a
security
perspective.
You
have
to
be
able
to
know
what's
going
on
in
your
cluster
and
you
have
to
be
able
to
see
into
it
to
have
any
chance
of
detecting
bad
actors
if
they
are
able
to
slip
in
so
mixer
supports
stackdriver
and
just
outputting
to
the
standard.
B
We
also
want
to
talk
about
egress
policy
now
egress,
in
this
case
we're
talking
about
egress
from
the
service
mesh
itself,
so
for
for
connections
in
the
service
mesh.
We
have
that
mechanism
of
mutual
TLS
and
authentication
to
know
who
you're
talking
to,
but
you
will
often
have
services
that
want
to
make
external
API
calls
to
take
advantage
of
other
services.
So,
if
you're
running
in
IBM,
maybe
you
want
to
make
calls
to
the
watson
services
if
you're
running
in
an
gke.
B
Maybe
by
corrupting
your
build
system,
or
maybe
by
corrupting
some
public
images
that
you
use
in
your
system
or
maybe
even
by
fishing.
You
know
your
system
they've
been
or
something
like
that,
and
these
things
when
they
come
up,
they
often
try
and
make
a
connection
out
to
some
command
and
control
server
or
exfiltrate
your
data.
You
can
shut
that
down
by
using
egress
policy.
B
So
I've
got
my
application
running
in
the
cluster
and
has
very
simple
architecture.
It
is
a
micro
service,
so
I've
got
a
front-end
pod,
which
is
called
the
customer
UI.
So
that's
where
people,
actually
my
customers,
actually
connect
to
and
sort
of
see
on
the
web
and
that
connects
to
a
single
micro
service
in
the
backend,
which
summarizes
that
person's
accounts
and
then
I
have
a
database
which
is
actually
persisting
all
the
account
information
and
then
I'm
not
showing
in
the
demo.
B
But
you
know:
there's
a
teller
UI
that
the
teller
uses
when
I
go
to
the
bank
and
either
withdraw
or
deposit
money,
and
that
creates
transactions
which
are
processed
in
a
micro
service
and
that
actually
updates
the
database.
So
it's
called
y
AO
Bank,
yet
another
online
bank
and
it's
very
simple
and
as
I
said
it
just
shows
me
my
account
summary,
which
is
my
current
balance.
B
B
When
I
get
back
is
handshake
failure
and
that's
because
the
HTTP
listener
that
is
in
front
of
that
database
is
expecting
an
HTTP
connection
and
it's
expecting
it
to
present
a
certificate
that
proves
that
I'm
part
of
the
service
mesh,
my
laptop,
doesn't
have
one
of
those,
so
I
get
handshake
failure
and
that
gets
shut
down.
So
we're
already
doing
pretty
well
here
we're
able
to
encrypt
the
data
and
also
prevent
people
from
outside
the
cluster,
from
making
contact
to
any
of
the
micro
services
that
are
running
inside
the
mesh.
B
But
there
are
still
some
vulnerabilities
that
we
want
to
be
able
to
deal
with
that.
Just
mutual
TLS
is
not
going
to
help
you
with.
So
one
of
the
problems
is
that
we're
not
doing
any
authorization
only
do
not
end
ocation
we're.
Basically
asking
is
the
person
that
I'm
talking
to
a
member
of
the
cluster
and
if
they
are
I'm,
gonna
allow
the
connection.
B
So
that
means
that
if
an
attacker
is
able
to
take
over
one
of
my
pods
by
exploiting
some
vulnerability
in
the
pod,
they'll
be
able
to
make
connections
anywhere
else
in
my
cluster
and
be
able
to
use
that
as
a
base
of
operations
to
start
launching
additional
attacks
and
I.
Don't
want
that.
So,
instead
of
actually
exploiting
a
vulnerability
in
my
cluster
since
I'm,
not
a
hacker
I'm
going
to
cheat
and
use
cue
cuddle
exec
to
show
what
what
it
would
look
like
if
I
was
able
to
exploit
a
vulnerability.
B
So
I'm
gonna
keep
cuddle
exactly
into
the
customer
pod.
And
basically
you
know,
even
though
I
didn't
exploit
a
vulnerability
from
here
on
out.
This
is
basically
what
when
it
would
have
been
like
in
from
what
we
know
of
the
equifax
attack.
So
the
attackers
there
exploited
a
vulnerability
in
an
Apache
struts
and
then
use
that
to
install
a
web
console
and
then
use
that
web
console
to
launch
attacks
and
the
rest
of
equifax
its
network.
B
B
B
B
I'll,
do
a
cursive
equals
true
and
pipe
that
through
pythons
json
tool,
so
that
you
can
see
what
information
I
get
back
and
so
just
from
being
able
to
exploit
one
one
part
I'm
able
to
connect
to
the
database
and
I
can
get
names.
I
can
get
account.
Numbers
I
can
get
balances,
I've
basically
owned.
This
database
from
one
exploit,
so
that's
definitely
been.
B
So
I
wrote
a
little
program
that
just
goes
to
the
kubernetes
api
and
gets
a
set
of
secrets
for
a
service
account
and
I'm
gonna
grab
the
secrets
for
the
summary
service
account.
So
when
I
do
that,
I
get
both
the
key
and
the
certificate
chain
as
if
I
had
stolen
it.
And
now,
if
I
repeat
that
connection
attempt
and
provide
the
key
and
the
certificate,
then
I'm
able
to
now
connect
to
the
database
and
I
can
do
something
sort
of
even
more
transgressive.
So
since
I
already
know
account
names
and
numbers.
B
Mistyped
my
account
number
there
we
go
there.
We
go
so
now
when
I
run
that
and
go
back
to
my
bank
account
you'll,
see
that
you
know
I
they
able
to
yeah.
Okay,
just
modify
my
balance
at
the
bank.
So
again
we
don't
want
that.
So
the
way
we're
gonna
deal
with
both
of
these
attacks
is
in
the
same
way
it's
by
applying
authorization
policy.
B
What's
the
customer
micro
service,
no
matter
who
it
is
from
for
the
summary
micro
service
since
that's
not
exposed
to
the
world
I,
don't
want
anybody,
except
for
things
inside
my
cluster
to
talk
to
it
and
in
particular,
I
only
want
the
customer
UI
Micra
service
to
talk
to
it,
because
I
know
that
that's
the
only
person
using
that
in
my
cluster
so
I'm
going
to
allow
connections
only
from
the
customer
microservice
my
service
account
and
then
for
the
database.
I
know
that
the
summary
micro
service
is
the
one
talking
to
it.
B
B
Formatting,
because
I
don't
actually
get
a
json
response
back
I
get
403
forbidden,
so
Sto
does
the
check
with
the
service
account.
That's
provided
and
the
customer
microcircuit
is
not
allowed
to
talk
to
the
database,
so
I
get
403
forbidden
now.
I'm
also
going
to
repeat
this
attack
where
I
stolen
a
certificate
and
when
I
do
that,
it
also
fails.
Now
you
might
wonder:
well
how
do
it?
How
do
I
do
that?
B
Because
I
actually
did
steal
this
cryptographic
identity
well
in
calico,
I'm
able
to
enforce
at
multiple
layers,
so
not
just
looking
at
the
cryptographic
identity,
but
Calico
is
monitoring
the
kubernetes
api
and
it
knows
what
pods
are
being
run
by
what
service
accounts
and
what
IP
addresses
those
pods
have.
So
it's
able
to
verify
against
the
network
layer
as
well,
because
I'm
trying
to
make
a
request
from
a
place
that
is
not
valid
for
that
service
account
I
can
shut
it
down.
B
One
of
these
is
it's
not
only
that
authorization
is
really
important,
but
also
the
way
that
we've
built
security
policy
into
sto
is
based
on
kubernetes
ideas,
so
we're
using
service
accounts
for
identities.
All
of
the
sto
configuration
is
stored
as
custom
resources,
so
you
can
look
at
them
with
Q
cuttle.
You
can
use
all
your
favorite
kubernetes
api
tools
to
look
at
what
that
configures.
B
A
Mike,
so
that
was
pretty
amazing
right
I
mean
all
of
that
was
done,
keep
in
mind,
spike
didn't
have
to
write
or
change
any
of
his
code
right.
All
those
security
features
again
were
made
available
in
the
mesh,
and
it
provides
a
way
to
program
the
mesh
and
have
it
apply
to
all
the
endpoint,
making
the
developers
much
more
productive,
there's
already
a
lot
available
today
in
sto
around
securing
your
services.
It's
pretty
rich
out-of-the-box
already
available
today,
but
there's
a
lot
a
lot
more
work
that
we
want
to
do,
there's
more
features.
A
We
want
to
add
to
this
again.
We
want
that
secure
by
default.
We
want
services
highly
secure
by
default,
so
some
of
the
things
that
we're
working
on
in
the
near
future.
So
this
first
slide
is
all
about
what
we're
doing
in
4q
we're
already
in
4q.
You
saw
the
snow
yesterday
so
clearly
we're
in
for
Q,
so
around
mutual
TLS,
one
of
the
things
with
the
mutual
TLS
right
now.
One
of
the
problems
is
when
you're
in
the
mesh
you're
in
the
mesh.
A
That
means
you're
communicating
mutual
TLS
between
your
services,
but
the
problem
is
what,
if
you
have
to
call
a
service,
that's
not
in
the
mesh,
it's
not
participating
in
the
mesh
itself.
Therefore,
it
doesn't
have
the
capabilities
to
do
the
mutual
TLS.
Today,
those
will
fail.
What's
what
we're
working
on
and
what
we're
going
to
be
delivering
very
soon
is
the
ability
to
enable
or
disable
individual
services.
So
you
can
have
a
service
in
the
mesh,
be
able
to
call
a
service
not
in
the
mesh,
and
it
will
disable
that
invocation
from
mutual
TLS.
A
So
you
can
allow
those
external
services
to
be
communicated.
The
other
aspect
is
as
well
one
of
the
key
things
with
SEO
is
that
we
want,
and
we
allow
for
you
to
incrementally
adopt
portions
of
the
mesh
and
the
capabilities
along
the
way.
So,
as
you
grow
and
you
mature-
and
you
start
adopting
more
of
this,
do
you
can
turn
those
features?
Well,
one
of
those
might
be
mutual
TLS,
so
you
might
have
a
cluster,
in
which
case
you
don't
have.
Sto
authentication
turned
on
you're,
just
using
sto
with
no
authentication.
A
We
want
to
provide
the
ability
that
there's
zero
down
time
to
turn
it
on,
which
is
pretty
impressive.
If
you
think
about
it,
I
mean
you've
got
all
your
services
out
there
they're
running
with
no
authentication
we're
gonna
enable
the
ability
to
just
turn
it
on
with
zero
downtime
and
mutual
TLS
will
be
turned
on
across
the
matter.
A
huge
one
for
us
right
now
is
also
sni
for
the
ingress
spike
was
commenting
on
this
earlier.
This
gives
us
the
ability
to
define
ingress
rules
into
the
mesh
and
use
multiple
different
host
names.
A
A
So
right
now
we
have
basically
service
accounts,
but
we
want
to
move
towards
role
based
access,
so
our
back
as
a
way
to
authentic
authorize
your
services
within
the
mesh
itself
and
in
spite
on
that,
a
little
bit
moving
towards
the
ISTE
Oh,
our
back
or
the
way
to
define
service
roles
and
service
role
bindings
using
our
back
OPA
is
another
another
technology
that
we're
looking
at
the
open
policy
agent,
as
well
as
the
Calico
unified
policy.
Two
other
ways
of
doing
authorization.
When,
in
your
mesh
on
the.
B
A
Lastly,
on
this
slide,
basically
drinking
our
own
champagne
sto,
on
sto,
using
sto
to
manage
the
control
plane
for
is
do
so
managing
pilot
mixer
and
the
CA
components
now
moving
forward.
Looking
into
next
year,
one
quarter
out
we're
looking
at
some
other
capabilities
as
well,
so
around
mutual
TLS.
The
ability
mentioned
it
a
little
bit
but
more
work
around
interoperating
with
non
mesh
services,
so
services
that
are
not
in
the
mesh,
but
a
key
one
is
to
allow
you
to
work
with
clusters
and
services
that
are
not
just
contained
within
a
single
cluster.
A
So
you
have
multi
cluster
services
running
outside
the
cluster.
We
want
to
enable
the
ability
to
authenticate
with
a
common
identity
across
multiple
cluster
cluster
boundaries,
so
that
work
is
ongoing
and
user
authentication.
So
right
now,
in
our
examples
that
we
were
showing
here,
you're
authenticating
and
using
the
identity
of
your
services,
so
using
service
accounts
and
and
some
of
the
other
capabilities
that
I
mentioned
on
the
other
slide
with
Auerbach
and
others.
A
That's
still
the
service
account
so
we're
authenticating
and
using
the
identity
of
the
services,
but
we
want
to
enable
the
ability
for
you,
as
a
customer
of
this
teo,
to
use
your
users
identity
for
defining
and
defining
the
policies
and
authenticating
within
the
mesh
itself.
So
it's
your
users
identity,
that's
going
to
be
coming
using
JWT,
in
this
case,
going
even
further
with
doing
authentication
and
using
different
tools
around
that.
We
want
to
leave
leverage
the
various
identity
management
systems
for
from
the
cloud
providers.
So
almost
every
cloud
provider
has
an
identity
management
system.
A
We
want
to
be
able
to
integrate
that
into
the
service
mesh
and
be
able
to
use
those
identities
as
well
and
then,
lastly,
leveraging
external
certificate
authorities
very
much
like
the
kubernetes
and
community
is
doing
with
secrets.
We
want
to
enable
external
authorities
as
well
to
manage
the
certificates.
So
that's
basically
our
roadmap.
If
there's
other
things
that
you're
interested
in
or
you
would
like
to
see,
please
give
get
in
contact
with
us.
There's
multiple
ways
to
contact
the
folks
working
on
Sto.
We
have
SEO
users
groups
we
have.
A
We
have
a
Twitter
account.
Definitely
tweet
us
if
there's
more
that
you
would
like
to
see
in
the
cert
security
of
the
mesh.
Definitely
reach
out
get
involved,
go
out
to
the
sto
da.
Do
site
start
using
it
check
out
all
the
cool
features
showing
how
you
can
secure
your
services,
but
definitely
get
involved.
Give
us
some
feedback.
Thank
you.
Everyone.