►
From YouTube: Enterprise Security Day 1 with Service Mesh
Description
SoloCon 2022:
Enterprise Security Day 1 with Service Mesh
Speaker:
Daniel Wessels
Field Engineer-APAC, Solo.io
Session Abstract:
Cloud native has reached enterprise maturity for platform solutions and application architectures, but often without the required security. Transport encryption, zero trust application networks and resilience policies are all necessary and should be part of our application architectures out of the box. Service mesh goes further and decouples the application developer from coding these concerns into the application. Also platform operator productivity increases, since policies are declaratively driven. This talk will discuss cloud native security in the service mesh context and also help organisations with choosing a service mesh.
Track:
Service Mesh and Application Networking
A
A
A
Roughly
the
structure
of
the
talk
will
be.
Do
we
need
service
mesh
we'll
look
at
that?
First,
we'll
use
trusted
security
advisors
and
get
their
recommendations
around
service
mesh.
We'll
also
look
at
industry
reports
and
industry,
business
end
users
and
what
they
tell
us
about
service
mesh
and
once
we've
looked
at,
why
service
mesh
will
look
at
how
to
select
a
service
mesh
and
then
throughout.
There's,
really
a
lot
of
links
and
further
reading
topics
and
some
practical
tips
in
terms
of
adoption.
A
So
in
the
last
40
years,
or
so
in
the
industry,
architectures
and
security
have
progressed
on
the
compute
side,
things
started
out
as
physical
and
went
into
virtual
and
cloud
and
container
orchestration
on
the
software
architecture
side
we
had
mvc
and
service
oriented,
architectures
and
microservices,
and
now
serverless
is
making
inroads.
And
of
course,
this
progress
will
continue
going
into
the
future
and
the
next
new
technology
will
make
itself
known.
A
So
do
we
need
service
mesh
and
the
answer
is
yes,
the
answer
is
yes.
If
these
are
your
requirements,
this
is
not
the
exhaustive
list
of
requirements,
but
they
really
distill
most
enterprise
and
organizations
when
they
look
at
new
technology
and
how
to
evaluate
it.
They'll
be
looking
across
these
five
criteria
and
proven
comes
down
to
has
this
technology
been
in
production
and
proven
and
hardened?
A
A
A
A
All
organizations
typically
have
legacy
applications,
multiple
different
infrastructure,
architectures,
and
these
have
to
work
together.
Your
application
architecture
needs
to
work
together
across
all
the
infrastructure
and
in
productivity
that
is
looking
at
the
day
two
side
of
things.
Looking
at
operational
productivity,
developer
productivity,
adoption
of
new
technology,
how
is
it
going
to
influence
the
operational
productivity
and
then
we're
looking
for?
A
Well,
organizations
are
looking
at
standardization
because
standardization
allows
for
a
high
degree
of
automation
to
increase
productivity
across
operational
procedures,
but
also
developers
should
be
decoupled
from
platform
considerations
and
they
can
focus
on
the
business
logic.
They
need
to
be
coding
for
so
we'll
use
these
as
we
go
through
the
next
few
slides
and
see
how
trusted
advisors
recommend
across
these
criteria.
A
Another
thing
to
look
at
for
service
niche
is,
of
course,
the
business
value
when
you
are
looking
at.
Do
we
need
service?
Why
service
niche
and,
as
we
said,
the
key
business
value
is
that
it
brings
enterprise
security
day
one
and
then
probably
the
other
key
criteria
in
terms
of
business
value
is
that
it
increases
the
developer
and
operational
productivity
service.
A
A
First,
one
is
the
nist
and
their
publication
on
application
security
in
service
mesh
architectures,
and
here
we
see
they
call
out
the
ephemeral
and
dynamic
nature
of
cluster
containers
and
the
security
that
service
mesh
brings
to
that
service
discovery.
It
also
calls
out
the
resilience
capabilities
that
come
with
service
mesh,
like
load,
balancing
circuit,
breaking,
throttling
and
monitoring,
and
it
says
that
service
mesh
is
the
best
known
approach
for
abstracting
developers
from
these
concerns
and
they
can
focus
on
the
code
in
the
microservice.
A
A
A
A
little
bit
closer
and
further
down
in
the
talk
here,
we
are
looking
at
the
end
users,
businesses
that
have
implemented
cloud
native
technologies
and
gardener
reporting.
Adoption
is
up
the
cloud
native
compute
foundation
report
speaking
to
end
users
of
cloud
native
technologies
in
production,
and
they
have
said
service
mesh
in
production
has
increased
50
percent
year
on
year,
and
we
can
see
that
the
technologies
like
containers
in
production
and
kubernetes
in
production
have
also
increased
significantly
here
on
here
and
those
are
all
the
technologies
that
are
driving
service.
Mesh
adoption
as
well.
A
So
it's
not
unusual
anymore
for
all
your
security
policies
to
be
written
into
a
manifest
and
that
manifests
being
checked
into
your
source
control
and
then
your
cicde
pipeline
updating
those
policies
into
your
environments
in
a
securely
and
safe
way.
These
aren't
concepts
anymore.
Maturity
for
this
type
of
security
management
is
well
established
and
I'll
call
out.
The
further
reading
have
a
look
at
the
u.s
air
force
platform,
one
dipstick
ops
platform.
They
have
lots
of
information
on
their
implementation
and
there's
nothing
like
a
white
house
executive
order
for
zero
trust.
A
A
A
Service
measures
really
at
a
very
high
level,
is
concerned
about
your
traffic
between
your
applications
and
workloads
and
then
the
service
mesh
controls,
how
the
configuration
of
those
communications
between
the
services
and
the
service
mesh
at
that
application.
Networking
level
need
to
solve
these
problems,
and
this
is
problems
in
terms
of
service
discovery
and
load
balancing.
A
A
Of
course,
all
of
the
traffic
will
need
metrics
that
we
know
our
service
mesh
is
performance
and
we
have
all
the
observability
considerations
to
to
manage
and
operate
the
service
mesh.
The
service
mesh
needs
to
deliver
resilience
and
be
resilient
and
be
proven
in
production,
and
then,
lastly,
it
also
needs
to
be
programmable.
A
A
Again,
we
have
options
when
we
look
at
decisions
that
we
make
between
having
self-managed
and
hosted
solutions
in
terms
of
service
measures.
On
the
self-managed
side,
we
can
think
of
solutions
like
10,
zoo
and
ibm's
open
shift,
and
there
are
many
options
in
both
camps
on
the
hosted
side.
Again,
we
can
look
at
cloud
providers
and
their
options
in
terms
of
managed
services,
and
this
largely
plays
into
life
cycle
management
of
your
service,
mesh
and
de-risking
that
aspect
of
service,
niche
management,
but
key
things
to
keep
in
mind.
A
A
So
another
key
consideration
is
your
underlying
technology
of
your
service
niche,
and
here
we
can
see
that
we
have
onboard
proxy
and
onward
proxy
is
the
foundation
for
a
large
group
of
service
meshes?
The
reason
for
that
is
that
envoy
has
been
engineered
from
day
one
for
distributed
and
dynamic
environments.
A
It
understands
the
ephemeral
nature
of
containers
and
so
has
been
used
in
production
for
many
years
and
proven
as
well
to
be
stable,
so
it
has
been
adopted
as
the
foundation
for
quite
a
few
of
these
service.
Mesh
solutions
again
coming
into
this
consideration
would
be
things
like.
Is
the
technology
going
to
be
too
niche?
Is
there
any
vendor
lock-in
and
again
the
penalties
associated
with
long-term
skills
and
operational
considerations?
A
A
A
A
A
Kubernetes
has
allowed
for
a
lot
of
standardization
across
container
and
cloud
native
technologies,
and
it
has
brought
a
lot
of
the
decoupling
business
value
that
we
find
out
of
service
niche
as
well.
So
it
is
key
that
your
service
mesh
integrates
in
a
seamless
way
and
the
kubernetes
native
to
to
use
and
understand
that
kubernetes,
and
this
will
extend
that
skill
set
more
globally.
So
kubernetes
these
days
have
a
lot
of
people
that
understand
it.
A
A
A
A
Here
we're
looking
at
some
industry
reports,
so
gigaom
has
done
extensive
market
research
reaching
out
to
service
mesh
users
evaluating
their
feedback
based
on
the
key
decision
criteria.
We've
been
talking
about
so
far
and
evaluating
the
different
service
mesh
offerings
against
those
criteria
and
the
optimal
score
on
this
report
would
be
hitting
the
center
the
bullseye,
and
we
can
see
here
that
the
feedback
from
the
end
users
and
the
analysis
by
gigaom
show
that
istio
is
definitely
hitting
a
leader
in
terms
of
open
source
service
mesh
and
also
heading
towards
that
ideal.
Center
score.
A
Another
report
from
the
cloud
native
compute
foundation,
where
they
speak
to
their
end
user
members,
so
these
are
vendor
neutral
organizations
that
have
cloud
native
technologies
in
production.
Today
this
is
a
user
group
of
around
140
different
organizations
that
are
sharing
their
cloud-native
architectures
that
they
have
in
production
and
again
they
look
at
istio
as
a
key
service
mesh
capability
to
recommend
that
to
the
rest
of
the
people
in
the
market
that
are
looking
at
cloud
native
technologies
and
service
measures.
A
While
it's
not
necessarily
the
answer
for
you.
Probably
the
best
way
to
look
at
this
recommendation
is
to
think
about
it.
If
you
don't
have
a
service
mesh
certainly
start
with
istio,
and
if
you
do
have
service
mesh
already
and
it's
not
sdo,
it's
probably
time
to
re-evaluate
or
include
it
in
your
life
cycle
service.
National
life
cycle
management
for
review.
When
that
comes
up
for
your
organization,.
A
So,
let's
take
a
deep
look
at
istio
since
that's
a
recommendation.
We
have
come
to
you
and
I
think
this
diagram
really
sums
up
why
easter
has
surfaced
as
becoming
the
de
facto
service
niche
it's
open
source,
but
it
also
understands
enterprise
environments.
It
understands
that
enterprises
will
have
separate
network
zones
and
considerations.
A
So
your
services
living
in
the
data
plane
as
they
are
provisioned
into
your
cluster
and
the
service
mesh
istio,
will
automatically
inject
these
certificate
identities
into
your
service.
So
developers
do
not
need
to
consider
any
of
this.
They
are
building
code
and
coding,
microservices
and
purely
deploying
their
microservices
into
the
mesh,
and
then
istio
will
automatically
inject
the
identities
to
that
service.
So
this
is
all
decoupled
from
the
developer.
A
So,
as
istio
injects,
these
certificates
we
are
able
to
encrypt
the
traffic
between
these
services,
and
also
each
service
has
an
identity
based
on
the
certificate,
and
with
that
identity
and
authentication,
we
are
able
to
start
building
authorization
policies
as
well.
So
these
are
the
key
concepts
around
security
frameworks,
the
identity
and
authentication
and
then
being
able
to
authorize
what
that
identity
can
do
within
your
architecture,
and
this
slide
shows
that
a
little
bit
more
in
a
little
bit
more
detail
as
hto
are
issuing
these
certificates.
A
It
will
be
issuing
a
certificate
with
a
subject:
alternative
name
containing
the
services
service
account
and
that
service
account
becomes
the
identity
of
that
service.
And
then,
as
that
identity
is
in
place
and
authenticated,
we
can
use
authorization
policies
in
istio
to
tell
us
how
that
identity
is
allowed
to
operate
within
the
service
mesh.
Very
fine
grading
control
over
what
each
of
these
services
can
do
between
each
other
and
istio
is
built
to
implement
zero
trust
out
of
the
box.
So
essentially
enabling
this
day
one.
A
A
And
the
recommendations
really
is
obviously
to
look
at
your
use.
Cases
start
with
finding
use
cases.
What
are
the
business
problems
that
you
are
trying
to
solve
and
start
with
those,
and
this
is
a
list
of
the
classic
ones
that
we
see
a
lot
of
clients
start
with.
It
is
things
like
transport
encryption
via
tls?
A
It
is
zero
trust,
one
mutual
tls.
It
is
authorization
policies
between
those
services.
Those
are
the
classic
ones
to
start
with,
as
a
use
case
after
that,
developers
will
also
want
to
start
using
the
resilience
controls
like
timeouts
and
retries
and
circuit
breakers
and
and
all
the
resilience
policies
that
come
with
ucf
service
niche.
A
So
that's
another
classic
use
case,
maybe
you're
not
even
interested
in
the
security
policies
like
resilience,
controls
and
tls
encryption
and
authorization,
but
you
just
want
to
have
that
visualization
of
your
microservices
application
traffic
or
you
could
be
related
to
traffic
control
like
canary
release.
So
this
would
be
classic
use
cases
and
start
with
maybe
one
of
those
and
implement
that
and
really
over
time,
just
phase
in
and
layer
in
more
and
more
of
these
policies,
as
need
be,
obviously
the
ones
that
make
most
business
sense
to
you.
A
Adoption
that
we
see
in
the
market
typically
follows
these
sort
of
core
walk
and
run
and
fly
adoptions,
where
you
may
initially
start
at
the
edge
api
gateway
and
bring
security
in
that
way,
but
that
is
really
limited
to
edge
traffic
service
mesh
goes
into
the
walk
phase,
where
you
are
looking
at
architectures
that
are
inter
clustering
into
mesh,
and
you
want
to
bring
those
same
security
policies
into
your
service.
Mesh.
East-West
traffic
you'll
also
be
looking
at.
A
A
Allow
you
to
very
seamlessly
and
safely
own
that
development
experience
as
well.
So
all
our
products
have
built-in
support
for
web
assembly
extending
of
the
underlying
onboard
proxy
and
then
really
once
you
pass
those
sort
of
phases.
Eventually,
you
will
end
up
in
the
multi-cluster
and
multi-service
mesh
environments,
and
that
is
really
where
istio
starts
to
become
pretty
complex.