►
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
Istio service mesh has a control plane that is responsible for configuring the proxies, enforcing policies, and observing communication through telemetry collection. According to Istio security best practices, securing the control plane should be as important as securing what’s in the mesh.
In this webinar, we will explore security and segmentation strategies and practices for operating applications and services using Istio, with an emphasis on sensitive data processing apps.
A
Alright
looks
like
our
numbers
are
stabilized,
so
let's
go
ahead
and
get
started
thanks.
Everyone
who
is
joining
us
today
welcome
to
today's
CMC
s,
webinar
on
sto
security
of
the
mesh
and
security
in
the
mesh,
I'm,
Kaitlin,
Barnard
marketing
manager
at
CMC,
F
and
then
I'll
be
helping
to
moderate
today's
webinar
I'd
like
to
welcome
today's
presenters.
Gotta,
know
who's
the
CTO
and
co-founder
at
all
feet.
So
I
just
want
to
go
over
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
speak
as
an
attendee.
A
So
if
you
have
a
question
there
is
a
Q&A
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
them
in
there
and
then
we're
going
to
save
those
to
the
end
and
get
to
as
many
as
we
can.
The
session
is
also
being
recorded
and
that
will
be
sent
out
to
you
all
afterwards,
along
with
the
link
to
the
presentation.
So
with
that
I'll
hand
it
over
to
Gotti
to
kick
off
today's
presentations.
Thank.
B
You
very
much
Caitlin
and
thank
you
for
the
ciencia
for
hosting
me
for
this
webinar.
So
a
little
bit
briefly
about
myself.
My
name
is
Gary
now
or
I'm.
The
CTO
of
alcide
I'm,
based
out
of
Tel
Aviv
Israel
I
try
to
enjoy
skateboarding,
as
this
picture
kind
of
hints
and
I
do
try
to
stay
alive
and
hopefully
do
that
until
I
cannot
walk.
My
background
basically
goes
back
to
the
traditional
security.
B
Wendell
has
spent
many
years
a
checkpoint
building,
IPs
and
firewalls,
and
then
move
to
a
startup
that
basically
build
distributed
firewalls
for
the
hypervisor
and
spend
few
more
years
at
juniper
networks
around
Sdn.
In
today's
webinar,
we
are
going
to
talk
about
security
in
the
mesh
and
security
of
the
mesh
and
kind
of
walk
through
the
different
challenges
around
the
security
aspects
and
the
operational
aspects
of
the
service
mesh
and
challenges
around
what
makes
sense
from
a
security
standpoint.
B
Incorporating
functions
or
function
as
a
service
on
top
of
the
service
mesh
is
something
that
brings
in
beyond
just
the
operational
model.
A
programming
model
that
is
strongly
rely
on
the
basic
constructs
that
steel
basically
brings
into
the
mix
and
when
it
comes
to
kind
of
the
separation
of
concerns
and
duties
around
those
that
technology
stack,
we
are
looking
at
kubernetes
as
kind
of
the
primitives
for
deploying
and
managing
container
workload
at
scale,
with
the
ability
to
kind
of
scale
in
scale
out
and
concepts
around
stateful
applications
and
deploying
them
across
multiple
clusters.
B
This
is
basically
brings
in
a
platform
as-a-service
abstractions,
that
baked
on
top
of
East
EO
and
brings
in
a
lot
of
developer
productivity
into
the
table
and
the
ability
to
kind
of
operate,
an
infrastructure
that
is
very
zen
bling
to
the
lambda
and
service.
As
we
know
it
today,
when
we
talk
about
what's
in
the
platform
and
what
is
the
promised
land
that
east
EO
basically
brings
into
the
the
mix?
The
first
one
is
the
ability
around
to
connect
multiple
services
that
can
spend
regions
even
clouds,
whether
they
are
on
Prem
or
on
public
cloud.
B
It
brings
in
layer
seven
path
based
routing
capabilities
that
are
very
flexible.
It
kind
of
helps
you
shape,
based
on
availability
and
and
and
and
routing
rules,
the
ability
to
kind
of
connect
services.
It
also
brings
into
ability
to
employer
use
cases
that
are
relatively
harder
to
implement
around
load.
Balancing
cannery
upgrades
a
be
testing
and
everything
that
relies
around
a
continuous
deployment
culture
that
normal
cloud
native
application
teams
that
basically
drive
those
applications
would
like
to
employ
from
a
management
perspective.
B
I
mean
anyone
that
is
running
kubernetes
in
production
with
a
significant
scale,
or
even
that
not
that
significant
skill,
but
with
number
of
micro-services
it
becomes
an
extremely
difficult
for
the
actual
team
used
to
get
a
handle
of
what
is
going
on
with
the
systems
without
having
to
properly
bake,
monitoring
and
telemetry
into
the
systems
and
the
value
around
the
security
aspects
of
still
fall.
Is
it
falls
into
three
main
buckets?
B
The
first
one
is
the
ability
to
inject
service
to
service
encryption,
meaning
that
we
can
basically
encrypt
the
transport
between
different
services
so
think
about
it
as
the
ability
to
kind
of
eject,
even
across
multiple
clouds.
The
TLS
doing
that
by
hands
comes
again
into
actually
modifying
code
and
involves
a
lot
of
challenges.
B
This
is
something
that
means
in
a
lot
of
control
and
reduce
the
challenges
or
the
overhead
of
actually
implementing
that's
into
the
running
services
is
a
naturally
identity
based
service
access
control
is
one
of
the
main
values
for
that
subsystem.
So
that's
going
to
try
to
kind
of
understand
the
challenges
when
it
comes
to
micro
services
and
this
diagram.
B
Basically,
capture
is
a
pretty
standard
kind
of
practice
of
micro
services,
not
too
many
of
them,
but
at
the
end
of
the
day,
when
we
try
to
see
about
it
from
a
security
standpoint,
logically,
we
think
about
services
as
a
logical
unit
or
virtual
services
or
services
that
interact
with
each
other.
If
you'd
focus
on
a
single
service,
you
will
notice
that
the
interaction
or
the
kind
of
graph
of
interactions
for
a
single
service
is
not
very
complex.
B
These
are
the
basic
kind
of
challenges
that
we
have
today,
with
kubernetes
and
and
easter,
in
that
sense,
suffer
or
or
at
least
experience
a
very
similar
kind
of
challenge
from
a
security
standpoint
think
about
it
from
compliance
or
a
security
standpoint
where
you
have
a
workload
that
is
not
fully
trusted,
or,
even
god
forbid,
running
your
customer
code
for
some
use
cases.
For
you
know,
companies
that
are
building
build
systems,
for
example,
and
then
right
next
to
them.
B
You
have
either
other
tenant
workload,
so
you
basically
want
to
have
kind
of
a
handle
at
a
very
fine
grain
of
what
is
happening
on
the
actual
kind
of
servers
and
he
still
tries
to
balance
between
building
that
in
a
scalable
way.
But
on
the
other
hand,
there
are
still
challenges
that
involves
into
where
exactly
those
workloads
are
running
from
kind
of
the
architecture
of
eesti.
B
Oh,
we
look
into
the
main
components
that
basically
kind
of
help
us
to
operate
the
cluster,
the
mesh
and
the
first
one
is
kind
of
think
about
it,
as
just
like
kubernetes
has
the
kubernetes
control
plane.
He
still
has
its
own
control
plane.
That
is
basically
comprised
out
of
three
main
components:
pilot
Citadel
and
mixer.
B
Are
the
entry
points
and
exit
points
from
the
service
mesh
itself
and
if
we
try
to
kind
of
think
about
it
from
a
networking
standpoint
think
about
the
sidecar
and
the
entire
grid
that
spans
the
mesh
as
a
layer
7
network
that
is
completely
completely
abstracted
from
the
underlying
network
and
infrastructure
and
compute.
It
runs
that
and
at
the
end
we
have
the
ingress
proxy
that
basically
provides
us.
B
The
ability
to
expose
services
that
are
implemented
inside
East
EO
to
the
outside
world
and,
at
the
far
edge
of
the
egress
proxy,
basically
says
in,
and
police
which
services
can
leave.
The
cluster
itself,
and
even
though
we
like
to
think
about
Easter,
is
kind
of
an
incarnation
of
project
that
happened
within
Google
and
and
our
web
scale
companies
internally
at
Google.
There
is
a
link
here
in
the
slide
that
actually
captures
how
East
EO
in
quotes
is
implemented
inside
Google.
B
It's
a
very
interesting,
read
and
I
highly
recommend
kind
of
getting
a
snapshot
of
that
paper,
and
when
we
try
to
kind
of
zoom
in
into
the
controlling
the
Android
data
plane,
which
is
basically
what
drives
the
traffic
between
all
the
different
services
within
the
service
mesh.
Then
we
look
into
Android
and
the
mixture
as
two
components
that
interact
with
each
other
in
the
context
of
getting
logs
out
of
the
backing
data
plane
of
Sto,
getting
quota
limitations
and
enforcing
quota
limitations
on
the
mesh,
so
think
about
limiting
the
number
of
connections
per.
B
Second,
you
want
to
impose
on
certain
services.
From
many
reasons,
you
can
find
yourself
kind
of
trying
to
limit
certain
services
to
protect
other
services,
authorization
which
is
directly
related
to
security
and
how
you
basically
authorize
service
a
interacting
with
another
service
or
policy.
The
mixer
is
directly
responsible
for
that
and
all
the
telemetry
is
basically
being
it
flashed
into
the
control
plane,
which
basically
enables
us
to
actually
visualize
and
understand
the
health
of
the
mesh
and
what
is
exactly
is
running
inside
the
mesh
and
zooming
in
a
little
bit
further.
B
We
can
see
here
that
envoy,
which
is
very
kind
of
popular
projects
beyond
the
scope
of
Easter
and
just
as
a
background
and
ROI
itself
started
as
a
project
within
lists
to
solve
operational
challenges
that
lift
head
internally.
So
it
predates
East
EO
as
a
platform,
and
one
of
the
kind
of
interesting
points
to
see
that
he
still
actually
implements
what
we
call
star
star,
RDS
api's,
which
mainly
revolves
around
cluster
discovery.
B
Api
is
an
endpoint
discovery,
api's
and
listener
discovery
and
api's,
which
basically
enables
Easter
to
program
and
ROI
as
the
data
plane
and
feed
basically
envoy,
with
the
data
to
operate
the
mesh.
One
thing
to
note-
and
this
is
where
kind
of
the
trickier
parts
from
a
security
standpoint
comes
in-
is
that
the
auto
injection
mechanism
and
I'm,
referring
here
specifically
to
kubernetes,
is
basically
implemented
using
a
mutating
admission.
B
Controlling
meaning
that
when
you
are
deploying
at
all
or
a
replica
set
or
any
resource
to
kubernetes
that
eventually
spins
up
a
pod,
then
under
certain
configuration
the
admission
controller,
which
is
implemented
part
of
the
easter
control
plane
will
basically
add
a
sidecar
to
the
pod
and
the
sidecar
basically
takes,
or
the
injection
basically
is
being
done
in
two
phases.
The
first
one
is
actually
rewiring
the
underlying
iptables
to
kind
of
do
a
very
nice
trick
that
basically
helps
us
to
deploy
is
still
transparently
without
changing
code.
B
The
first
one
is
actually
understanding
that
a
service
is
exposing
a
certain
port
into
the
world,
and
then
it
basically
programs,
IP
tables
with
the
exact
same
port
and
the
sidecar
and
the
IP
table
rules
are
basically
doing
a
redirection
inside
the
network
name
space
of
the
application
itself
for
the
pod
itself.
In
order
to
route
the
traffic
through
the
Envoy
sidecar.
B
There
are
many,
let's
say,
value
in
in
the
fact
that
envoy
basically
see
the
traffic
and
and
is
able
to
basically
upgrade
protocols
from
HTTP
1.1
to
http,
dot,
HTTP
2
or
handle
gr
c
or
even
have
observability
into
database
protocols
such
as
DB
and
dynamo
DB
on
one
hand,
but
on
the
other
hand,
with
the
observer
ability
come.
It
comes
with
a
price
and
I
often
like
to
kind
of
refer
to
the
faculty.
B
We
want
to
use
the
right
tool
for
the
right
task
and
just
like
not
every
workload
is
suitable
for
server,
less
or
lambda
like
deployments.
It
does
necessarily
mean
that
not
every
workload
is
actually
a
perfect
fit
for
Android,
and
the
tax
mainly
revolves
around
the
network.
Latency.
That
is
coming
from
the
fact
that
we
are
routing
the
traffic
in
the
packets
twice
through
the
network,
stack
so
think
about
two
services
running
in
ports
on
the
same
server.
They
will
traverse
the
network
in
the
kernel
in
several
times
and
naturally
it
brings
it
adds
latency.
B
So
you
need
to
think
about
the
usage
of
certain
services
inside
the
mesh,
whether
they
are
latency
sensitive.
Some
examples
to
that,
if
you
have
a
batch
processing
that
runs
nightly
or
periodically,
and
it
operates
some
sort
of
an
ETL
kind
of
workload,
then
it
perfectly
fine
if
it
runs
inside
the
mesh,
and
it
here,
for
example,
database
that
our
latency
kind
of
sensitive
and
you
want
to
make
sure
that
they
run
in
an
optimized
manner.
Then
maybe
envoy
is
not
a
solution
or
running
that
inside
the
mesh.
B
The
clustering
inside
the
mesh
doesn't
really
make
sense,
and
of
course-
and
this
is
something
that
you
know
as
a
security
vendor-
we
often
being
asked
about
what
is
the
overhead
of
memory
and
CPU
your
product
have
think
about
eesti.
Oh,
we
are
basically
not
doubling,
but
adding
a
lot
of
CPU
and
memory
pressure
on
the
underlying
infrastructure,
so
there
is
direct
cost
associated
with
the
infrastructure,
but
then
again
trying
to
be
to
look
on
the
positive
and
the
bright
side.
B
B
B
More
is
in
service
of
service
access
control,
but
when
it
comes
to
the
underlying
infrastructure,
if
you're
running
your
pod
as
root,
which
is
not
the
recommended
practice,
but
it's
the
default
behavior
of
kubernetes,
for
example,
you
get
the
ability
to
add
users
in
a
specific
user
ID
that
envoy
use
and
the
moment
that
you
spin
up
a
shell
under
the
same
user
ID,
nothing.
It
really
goes
through
the
Envoy
proxy
and
it
is
not
subjected
to
the
cluster
or
to
their
service
mesh
policies.
B
So
when
it
comes
to
environments
that
are
regulated
or
are
sensitive
around
specific
challenges
around
isolation,
then
clearly
you
need
to
think
about
securing
your
service
mesh
as
kind
of
securing
the
mesh
itself,
but
also
taking
care
of.
What's
the
underlying
infrastructure
that
it's
running
on
and
taking
care
of
that
as
well,
and
we
see
it,
we
see
this
trend
for
quite
a
while
that
the
application
and
the
underlying
infrastructure
converge
and
functions
are
kind
of
the
ultimate
converter
conversion
or
convergence
of
this
kind
of
trend.
B
But
you
need
to
make
sure
that
you
have
kind
of
security,
layering
and
isolation,
stacked
from
the
application
to
the
workload
to
the
underlying
node,
and
sometimes,
if
it's
running
on
public
cloud,
and
you
also
need
to
take
care
of
the
security
groups
in
your
public
cloud,
and
we
will
a
specific
example
on
on
that.
Exactly
other
kind
of
escape
methods
think
about
ipv6
pods
can
interact
on
a
very
low-level
kind
of
protocols
on
east-west
communications,
neither
IP
tables
nor
kubernetes
and
specifically
envoy
as
well,
are
not
even
looking
at
those
protocols.
B
So
from
an
attacker
standpoint.
These
are
quite
legitimate
communication
channels
that
attackers
can
actually
interact
inside
your
operations
in
order
to
take
care
of
the
challenges
around.
Are
we
running
with
our
pods
configured
correctly?
Port
security
policies
are
coming
to
the
rescue
and
can
actually
enable
you
to
run,
or
at
least
get
a
handle
of
not
loading
pods
with
root
permissions,
so
meaning
that
you're
running
your
pods
rootless
and
then
this
escape
method
is
is
not
really
exploitable,
but
then
again
it
sometimes.
We
require
some
dev
efforts
to
get
this
right.
B
So
when
it
comes
to
performance
and
and
the
service
mesh
I
took
hear
a
slight
example
of
Cassandra
so
think
about.
Cassandra
is
just
another
service
that
should
run
in
your
service
mesh,
and
here
specifically,
we
have
a
data
center
where
Cassandra
deployment,
which
basically
spends
two
different
data
center.
One
is
running
on
your
favorite
cloud
provider
and
then
the
other
one
is
running
god
forbid.
On
Prem
and
the
data
center
application
that
Cassandra
basically
takes
care
of
is
something
that
may
run
inside
the
service
mesh.
B
When
it
comes
to
the
cluster
that
basically
drives
what's
inside
a
specific
region,
it
may
very
well
not
make
sense
employ
the
service
match
between
the
Cassandra
nodes
themselves.
So
again,
in
the
spirit
of
use
the
right
tool
for
the
right
task.
Sometimes
it
makes
sense
to
actually
have
a
hybrid
deployment
and
when
it
comes
to
operating
workloads
that
are
not
part
of
the
mesh,
it
simply
mandates
that
you
think
about.
B
So
a
little
bit
about
the
notion
of
zero
trust
and
it's
an
often
used
term
in
many
contexts,
but
at
the
heart
of
it
is
bringing
security
into
the
network
and
into
the
application
mesh.
So
traditionally
we
kind
of
try
to
think
about
our
deployments
as
let's
kind
of
hedge,
the
perimeter,
whether
using
firewalls
or
whether
we
considered
our
load
balancers.
It's
kind
of
the
edge
that
separates
our
internal
deployments
and
an
infrastructure
from
the
rest
of
the
world.
B
But
then
again
when
it
comes
to
these
highly
distributed
environments
and
the
fact
that
sometimes
the
software
supply
chain
is
the
one
that
basically
brings
in
vulnerabilities
into
a
real
threads
into
deployments.
Then
we
need
to
try
to
think
about
the
threat
model
differently
in
the
sense
that
what's
your
endgame,
if
you
already
have
someone
inside
your
environment,
will
you
be
able
to
detect
that?
Will
you
be
able
to
prevent
that
and
when
we
try
to
think
about
growing
the
application
segmentation
or
implementing
it
fully
kind
of
zero
trust
deployment?
B
It
makes
sense,
sometimes
to
kind
of
do
that
in
a
gradual
manner,
meaning
that
you
start
with
creating
boundaries
around
some
of
the
more
sensitive
tears
or
microservices,
or
think
about
like
data
services
that
running
inside
the
service
mesh.
So
try
to
think
about
segmenting
those
and
building
a
zero
trust
notion
around
those
and
by
zero
trust.
I
mean
zero
trust
at
the
API
level,
zero
trust
at
the
network
and
infrastructure
level
that
runs
those
workloads
and
the
ability
to
kind
of
implement
those
segmentation
and
zero
trust.
B
Concepts
enables
us
to
limit,
from
an
attacker
standpoint
the
ability
to
do
lateral
movement
and
the
ability
to
actually
identify
lateral
movement,
and
it's
quite
important
to
note
here
that
identification
of
such
in
the
presence
of
such
an
attacker
can
come
from
signals
that
are
being
surfaced
from
the
running
infrastructure.
So
if,
for
example,
you
are
using
network
policies,
whether
sto
or
kubernetes,
and
some
traffic
is
being
dropped
and
you
are
not
monitoring
those
logs,
then
you
are
basically
missing
part
of
the
picture
that
is
in
front
of
you.
B
So
try
to
balance
between
employing
security
tools
and
actually
monitoring
them
and
not
just
relying
that
they
are
there
and
things
are
I'm,
nice
and
clear.
But
having
said
that,
zero
Trust
is
a
great
start.
It's
a
good
start,
but
it's
not
enough
when
we
think
about
the
full
application
deployment
lifecycle.
B
There
are
many,
let's
say:
hygiene
checks
and
security
checks
and
security
testing
that
we
can
employ
early
on
in
the
development
phase.
So
even
even
in
tests,
miss
configuration
and
even
security,
configuration
drifts
or
even
bad
package
from
an
NPM
repository
being
hacked
by
someone
is
something
that
we
can
detect
early
only
the
deployment
and
deployment
pipeline.
So
essentially
we
don't
really
want
to
meet
problems
at
the
production
side,
but
rather
try
to
kind
of
get
in
the
early
on
in
the
game.
B
But
for
that
you
need
to
basically
think
about
security
and
employing
security
products
or
subsystems
early
on
in
your
kind
of
journey
into
east.
Your
journey
into
kubernetes,
or
even
both
and
the
other
part
which
will
look
into
later,
is
what
your
endgame
as
far
as
threat
protection
exfiltration
data
through
the
application
that
are
running
inside
the
mesh.
What
do
you
think
about
scanning
spoofing?
B
B
So
going
a
little
bit
deeper
on
the
zero
trust
and
the
application
segmentation,
we
want
to
try
to
think
about
policy
mixture
as
the
one
that
decides
on
whether
service
a
can
interact
on
service
be
based
on
configuration,
which
is
a
pretty
powerful
capabilities
in
respect
to
what
kubernetes
has
to
offer,
which
is
a
label
based
approach.
We
can
inject
TLS
and
to
end
across
the
different
services
and
easter
basically
takes
care
of
all
the
lifecycle,
management
of
secrets
and
certificates,
which
essentially
it's
relatively
heavy
lifting
when
you
try
to
build
it
on
your
own.
B
So
the
platform
out-of-the-box
brings
in
a
lot
of
goods,
know-how
and
modeled
into
API
as
a
configuration
that
gets
you
to
run
with
that
when
it
comes
to
kind
of
and
here
kind
of
dive
into
how
we
configure
ingress
and
egress
policy.
So
in
East
EO,
the
Gateway
resource
basically
represents
the
ability
to
expose
services
to
the
outside
world,
and
essentially
they
once
they
are
in
the
mesh.
Then
the
mesh
routing
takes
care
of
who's,
picking
up
the
API
holes
and
how
they
traverse
the
different
services
east-west.
B
On
the
left
hand,
side
that
represents
routing
rule
and
the
ability
to
kind
of
say
that
if
you
try
to
access
Google
comm
on
www.google.com
on
HTTP,
then
all
the
wiring
within
East
EO
is
taken
care
of.
And
it's
a
pretty
straightforward
in
respect
to
previous
API
versions
within
East
EO,
which
were
slightly
more
complex.
Do
note
that,
despite
the
fact
that
it
looks
kind
of
straightforward,
we
are
looking
at
the
networking.
Api
is
a
v1
alpha
3.
So
it's
still
early
stage
on
the
kind
of
API
maturity
level.
B
But
despite
that,
it
looks
like
this
part
of
the
api's
has
a
very
solid
kind
of
concepts
and
and
revision
compared
to
the
previous
api
and
when
it
comes
to
kind
of
the
superpowers
of
East
EO
and
we
think
about
building
role
based
access
control
systems
into
our
own
kind
of
applications.
It's
extremely
complex
to
get
it
right
and
II
still
in
a
very
similar
way.
For
those
of
you
who
know
kubernetes
auerbach
resources.
B
So
it's
still
pretty
much
gives
you
the
ability
to
associate
our
bug,
definitions,
which
basically
captures
the
notion
of
who
is
allowed
to
do
what,
under
which
conditions.
And
in
this
specific
example,
we
can
see
that
we
enable
our
bug
on
a
specific
namespace
and
within
that
namespace
we
can
see
on
the
upper
upper
resource,
the
service
role.
We
can
basically
say
on
the
condition
of
v1
and
v2
of
the
product
service.
B
B
They
basically
did
a
direct
call
to
the
metadata
services
of
the
underlying
cloud
provider.
Those
are
weird
addresses
that
started:
169,
dot,
254,
etc,
and
in
gke,
specifically,
the
bootstrapping
of
the
cluster
is
actually
happening
using
the
metadata
API
and
the
embedding
of
secrets
within
those
api's,
the
attacker
was
basically
able
to
retrieve
the
private
key
and
the
certificates
of
the
node.
He
manually
edited
the
cube
config
on
his
machine
and
he
basically
had
a
complete
access
to
the
cluster
so
think
about
Easter
or
kubernetes.
B
Maybe
the
reality
is
that
from
a
segmentation
standpoint,
you
can
think
about
it,
as
you
can
use
kubernetes
network
policies
in
combination
with
East
your
network
policies.
You
can
maybe
manipulate
the
kubernetes
scheduler
to
actually
separate
physically
some
services
from
other
services
using
taints
and
toleration,
which
essentially
can
give
you
physical
isolation
at
the
node
level,
but
sometimes
it
makes
sense
to
employ
multiple
clusters
to
create
a
stronger
isolation.
B
In
this
example,
we
can
see
that
in
a
commerce
application
that
is
PCI,
DSS
compliance
is
required
in
in
such
case,
it
makes
sense
to
deploy
two
kubernetes
clusters,
run
the
East
EO
control,
plane
on
a
separate
environment
and
have
the
East
EO
kind
of
in
cluster
components
available
for
the
provisioning
and
the
interaction
with
the
control
plane.
But
at
the
end
of
the
day,
we
want
to
kind
of
deploy
the
cardholder
information
or
the
workload
at
hand.
B
The
cardholder
information
on
one
cluster
and
physically
segment,
that
using
cloud
policies
or
security
groups
or
or
firewall
policies,
and
then
the
rest
of
the
workloads
can
be
run
on
the
other
cluster.
And
if
you
need
to
run
it
on
multiple
regions,
then
you
can
basically
replicate
that
pattern
across
more
regions
and
you
can
be,
and
you
can
essentially
get
an
isolation
that
is
compliant.
B
One
of
the
challenges
with
Easter
is
that
if
you
do
not
have
a
control
over
the
underlying
infrastructure,
then
it
makes
you
kind
of
it
makes
challenging
for
you
to
identify
where
the
data
is
and
where
the
data
and
whether
the
access
to
the
data
is
fully
controlled.
If
you
assume
you're
kind
of
monitoring
and
an
audit
trail
based
on
just
what's
happening
in
the
mesh,
naturally,
there
are
challenges
of
operating
clusters
separately.
In
such
ways
there
are
compute
resource
over
the
sociated.
B
It
starts
with
reconnaissance.
You
collect
information
on
how
you
can
get
into
the
system
once
you
are
inside
the
system
and
think
about
it
as
either
an
open
source
component,
but
end
up
in
a
container
that
is
being
deployed
using
your
pipeline
and
is
introduced
into
the
environment
or
something
that
hits
your
service
just
like.
B
We
saw
before
with
the
Shopify
example
and
at
the
end
of
the
day,
once
an
attacker
is
in,
it
is
possible
even
using
all
the
policies
that
we
saw
so
far,
the
ability
to
escape
the
mesh
and
even
the
kubernetes
cluster.
So
this
specific
attack
is
actually
leveraging.
Some
weaknesses
inherit
weaknesses,
the
DNS
has
a
protocol
and
it
basically
creates
the
ability
to
for
an
attacker
to
create
an
infiltration
point
that
interacts
with
a
remote
location
and
can
drive
data
outside
the
cluster
and
every
cluster
basically
have
the
DNS.
B
Discovery
is
kind
of
the
backbone
of
the
service
discovery,
so
tunneling,
essentially
leveraged
DNS
by
embedding
messages,
or,
let's
say
ssh,
protocol
or
whatever,
and
leveraging
the
dns
transport
and
message
exchange
as
the
underlying
mechanism
for
delivery
messages
of
deep
ssh
protocol.
For
that
matter,
and
then,
from
a
security
standpoint,
we
simply
bypass
security
boundaries
that
we
think
we
have
using
something
that
is
inherent
into
the
system.
B
Protection
against
this
type
of
an
attack
is
an
extremely
challenging
in
the
sense
that
we
have
a
lot
of
moving
parts
running
in
the
system.
So
one
of
the
challenges
or
the
challenges
around
that
mainly
revolves
around
the
ability
to
have
high
resolution,
monitoring
and
deep
packet
kind
of
application.
Aware
it's
section
of
what
is
interacting
with
who,
within
the
workload
level
and
then
try
to
kind
of
build,
a
bigger
picture
that
understands
the
context
of
micro
service.
B
And
when
it
comes
to
higher
level
protocols
that
these
two
network
policies
provide
think
about
application
level
attacks
and
ask
yourself
whether
east
your
networking
policies
and
role
based
access
controls
are
something
that
is
sufficient
enough
to
detect
API
exploitation
and
even
though,
even
though
Easter
itself
do
provide
zero
trust,
API
access
level
control
in
a
very
fine
fine,
grained
manner,
it
is
challenging
to
manage
that
it
provides
a
very
good
isolation.
But
at
the
end
of
the
day,
this
is
not
enough
to
just
kind
of
drive
that.
So
we
got
in
mind.
B
I,
think
that,
to
summarize
complexity
essentially
is
the
worst
enemy
for
security
and
both
kubernetes
any
steal
are
an
extremely
powerful
systems
to
get
them
right
requires
oftentimes,
deep
understanding
of
what
those
systems
are
doing
internally
and
the
fact
that
we
have
multiple
stakeholders
that
are
driving
this,
the
ability
to
kind
of
have
and
recall
its
mashups
mitigating
those
challenges.
It's
a
collective
effort,
it's
not
just
a
security
team
effort.
B
Devops
are
definitely
the
glue
layer
between
Devon
security
and
looking
at
the
kind
of
fool
threat,
landscape
and
understanding
the
challenges
and-
and
it
is
okay
to
kind
of
say
prioritize.
What
do
you
want
to
tackle
first
and
then
start
with
the
big
rocks,
but
keep,
though
doing
those
and
a
continuous
kind
of
approach
start
as
early
as
possible
and
make
sure
you
know,
hygiene
wise,
both
kubernetes,
the
underlying
backbone
of
East,
EO
and
East
to
itself
are
well
configured
and
then
take
care
of
the
anomaly
detection
and
third
protection
using
deep
security
controls.
A
B
Sure
so,
when
we
think
about
services
we
normally
associate
with
a
service
a
domain
endpoint
and
by
referring
to
the
identity,
is
the
ability
to
provision
an
identity,
a
domain
name
to
that
service
and
within
the
pistil
mesh
Citadel
is
the
one
that
is
required
or
provisions
that
and
once
you
have,
that
we
can
provision
the
certificate
for
the
access
control
and
the
TLS
of
authentication
between
two
services.
So
essentially
it's
mainly
around
getting
your
fqdn
and
provisioning
a
certificate
for
that.
A
B
The
injection
so
android
self
doesn't
change
the
e
IP
tables
itself,
the
provisioning
process
or
the
injection
of
envoy
rewires,
using
injection
of
IP
tables
rules,
and
by
doing
that,
it
takes
care
of
the
traffic
that
the
application
basically
pass
through.
The
Envoy
itself,
so
envoy
itself
make
certain
assumptions
and
based
on
those
assumptions,
it
takes
care
of
the
fact
that
traffic
passed
through
it
and
it
understands
what's
behind
it
and
what's
the
upstream
and
what's
the
downstream
and
takes
care
of
the
routing
based
on
the
API,
is
in
the
discovery.
B
So
assuming
I
understand
the
the
question
so
envoy
itself,
and
it
truly
goes
through
a
rigorous
kind
of
security,
testing
and
fuzzing,
but
at
the
end
of
the
day
envoy,
it's
just
any
other
application
component
that
potentially
can
have
vulnerabilities,
but
inside
envoy
itself
it
relies
on
filtering
mechanisms
and
there
is
an
internal
implementation
that
follows:
security,
best
practices
and
security,
best
practices
from
a
testing
perspective.
So
assuming
I
understood
the
question.
That's
kind
of
the
perspective
on
that.
B
So
that's
a
that's
a
really
tough
one,
because
at
least
from
our
perspective,
once
you
start
to
employ
both
east
your
policies
and
kubernetes
policies,
you
end
up
having
you
know
gigantic
size
or
number
of
VM
O's
that
tries
to
capture
policies
and
over
time
you
know,
we
add
more
micro
services
and
we
like
this
kind
of
the
velocity
that
it
gives
so
I
think
this
is
something
that
oftentimes
we
run
into
customers
that
actually
asked
for
help
with
managing
the
complexity
and
I.
Think
a
good
start
would
be
I'm
getting
at
least
for
kubernetes.
B
A
very
solid
labeling
strategy.
Try
to
kind
of
not
over
do
implementation
of
the
policies
and
start
by
building
some
tears
and
building
policies
around
that
same
goes
with
East
EO
see
that
you
do
not
go
to
further
south
in
the
complexity,
and
then
you
know,
visualization
is
something
that
always
helps,
especially
around
policies.
A
B
So
I
think
right
now,
as
far
as
maybe
there's
something
that
changed
recently,
it's
not
being
handled
and
the
fact
that
it's
not
being
so
the
user
identity
is
not
propagated
all
the
way
into
the
internal
services.
This
is
something
that
actually
creates
kind
of
challenges
where
you
lose.
The
original
context
from
each
service
call
was
made
so
I
think
that's
one
of
the
changes,
if
they,
if
those
were
not
already
done,
would
actually
be
able
to
kind
of
propagate
user
identity
all
the
way.
B
B
But
Easter
by
itself,
visualization
of
the
mesh
itself,
so
you
know
trying
to
kind
of
zoom
in
on
a
certain
service
and
then
understanding
the
ingress
edges
and
the
egress
edges
gives
you
a
good
sense
of
what
the
policy
should
look
like
challenges.
How
do
you
maintain
that
over
time
as
developers
add
more
services,
service
interactions
and-
and
that's
that's
challenge.
B
B
So
there
is
the
ability
to
add
external
authorization
into
the
mixer.
You
basically
can
add
a
plug-in
to
mixer
and
based
on
that,
you
can
implement
external
authentication
and
authorization
machinery,
so
in
that
sense,
I
think
that
is
to
control
plane.
We
are
going
to
and
and
and
a
lot
of
it
is
already
there.
It
is
extendable
in
the
sense
that
you
can
customize
it
and
and
kind
of
tailor
made
it
to
your
needs
and
I
think
a
lot
of
the
good
work
that
had
been
done
with
kubernetes
and
still
being
done.
A
B
I,
don't
know
specifically
about
key
cloak
as
your
kind
of
identity,
provisioning,
I
I
will
guess
that
there
should
be,
or
that
might
be
a
plugin.
It
actually
enables
you
to
kind
of
connects
the
identity,
provisioning
part
with
key
cloak,
but
then
again
as
far
as
the
our
bug
goes,
I'm
not
sure
this
is
something
that
is
actually
can
be
connected,
but
I
will
say
that
specifically
it's
it's
really
hard
for
me
to
give
like
a
precise
answer
here,.