►
From YouTube: Application Networking Day Session #12: Leverage Defense In Depth by Using Cilium and Istio Together
Description
Featuring Ram Vennam. Istio and Cilium both provide the ability to apply security policies directly to the network without any changes to the application code. This session will cover the differences and overlaps between the two and cover some best practices from the field for implementing both to work together and give you robust control over your entire network stack.
A
A
B
What
are
the
overlaps?
What
are
the
things
to
look
for?
Why
there's
two?
The
main
focus
of
this
talk
is
around
defense
in
depth.
Right,
if
you
read
the
the
security
overview
pages
of
istio
or
celium,
or
any
other
Cloud
native
software
that
sits
on
top
of
kubernetes,
they
talk
about
adopting
defensive
depth
in
order
to
protect
against
multiple
layers
of
of
a
security
attack
or
or
a
potential
security
attack.
B
The
to
simplify
it
down
it
pretty
much
boils
down
to
if
one
measure
of
layer
is
ineffective,
whether
it's
been
compromised
or
misconfigured
due
to
user
error
or
due
to
an
actual
attack,
there's
another
layer
behind
it
that
can
stop
that
attack.
So
it
doesn't
necessarily
mean
that
you
need
multiple
for
every
different
types
of
attack,
but
when
it
makes
sense
to
do
it
when
when,
if
it
is
in
the
in
the
in
the
right
space
and
you're
able
to
do
multiple
layers
of
of
Defense
measures,
you
should
adopt
that
pattern
right.
B
So
this
this
problem
of
adopting
defensive
depth
was
exacerbated
after
we
started.
Adopting
microservices
or
the
way
to
solve
that
problem
is,
is
tremendously
more
challenging
now
that
we
have
microservices
simply
because
you
don't
have
a
just
a
single
app
that
you
can
just
put
layers
of
Defense
around
it
and
call
it
a
day.
B
But
now
that
you
know
everything
is
a
pod
and
you
have
hundreds
and
thousands
of
PODS
across
different
zones
and
data,
centers
and
regions
and
Cloud
providers,
there's
not
a
single
solution
or
a
single
set
of
barriers
that
you
can
put
around
any
application.
Every
application
is
different.
Not
only
that
there's
some
security
measures
that
it
it
actually
makes
sense
to
share
that
boundary
between
a
set
of
of
PODS,
meaning
every
pod
is
not
going
to
have
this
full-blown
set
of
security
measures
around
it.
B
Some
of
them
some
of
the
pods,
maybe
pods
in
the
same
namespace,
have
one
security,
boundary
or
pods
in
the
kubernetes
cluster
have
a
different
set
of
boundaries,
Etc,
so
there's
multiple
layers
and
what
makes
the
child
the
problem
even
worse.
Is
that
there's
different
tools
that
guarantee
protection
for
multiple
layers
and
there's
overlap
between
these
tools,
meaning
it's
not
like.
You
can
break
down
the
defense,
in-depth
layers
or
the
the
OSI
stock
layers
and
say
well
this
layer
is
this
product.
This
layer
is
this
product.
It's
not
quite
so
simple
like
that.
B
Every
layer
is
protected
by
a
different
set
of
tools
and
a
single
tool
can
protect
multiple
layers.
So
that's
why
defense
and
depth
is
important
so
that
you
have
multiple
ways
of
protecting
against
a
potential
potential
attack,
so
first
we're
going
to
drill
down
istio
and
then
we're
going
to
talk
about
celium
and
talk
about
what
the
overlaps
are
and
how
they're
different
in
achieving
what
they
do
right.
B
So
this
this
diagram
is
straight
from
its
to
I
o
security,
Concepts
page
and,
and
it
talks
about
how
istio
provides
a
full
comprehensive
set
of
layers
around
your
kubernetes
spot
to
give
you
security,
there's
the
Outer
Perimeter
layer.
So
this
is
the
Ingress
Gateway
or
the
egress
Gateway.
This
is
where
you
attach
things
like
your
WAFF,
your
DLP,
your
user
authentication,
your
request,
authorization,
all
the
traffic,
that's
coming
into
your
network,
who's
able
even
able
to
come
into
the
network
and
what
are
the
authentication
and
authorization
rules?
B
You
want
to
apply
on
top
of
it
to
filter
that
traffic.
So
that's
one
layer,
the
next
layer
is
POD
to
pot
encryption
right.
So
this
is
to
prevent
against
men
in
the
middle
attacks.
You
don't
want
to
be
able
to
sniff
the
traffic
in
your
cluster
and
see
who's
talking
to
what
what
are
the
headers?
What
is
the
data
Etc,
so
you
cannot
trust
your
kubernetes
network.
B
Is
that
essentially
what
it
boils
down
to
and
then
istio
offers
you
encryption
from
pod
to
pod,
so
from
Ingress
gateway
to
your
first
front-end
pod,
there's
encryption
from
that
pod
to
another
pod,
there's
encryption
and
so
on.
So
that
is
encryption,
so
that
would
be,
like
you
know,
point
in
the
middle.
B
You
probably
can't
see
this
one,
so
I'll
just
kind
of
talk
about
it
and
then,
after
that,
there's
strong
identity
that
istio
Associates
with
each
individual
application,
and
that's
really
where
the
the
focus
of
this
talk
is
going
to
be
on
is
how
that
identity
is
established
as
a
quick
overview
again,
this
diagram
is
from
sgio.
The
way
identity
is
established
in
istio
is
whenever
there's
a
new
pod.
B
That
comes
up
in
your
in
your
in
your
cluster
that
pod
there's
a
knit
container
that
runs
in
that
pod
and
it
uses
the
kubernetes
service
account
token
and
talks
to
the
istio
control
plane,
where
it's,
the
The
Citadel
portion
of
the
istio
control
plane,
which
acts
as
a
as
a
CA
and
exchanges
it
for
for
an
identity
certificate.
So
it's
a
strong
Xbox
509
certificate
that
has
its
identity
information
directly
built
into
that
cert.
Every
single
pod
has
this
cert
that's
associated
with
it.
B
So
now,
when
one
pod
wants
to
talk
to
another
pod,
the
envoy,
the
sidecar
of
that
pod,
will
use
that
certificate
to
say
you
know.
This
is
who
I
am
and
they'll
talk
to
another
pod
and
the
envoy
on
that
on
that,
on
that
server
pod
will
will
also
have
a
certificate,
so
they'll
do
a
mutual
TLS,
handshake,
they'll
agree
on
who
each
other
is
and
then
establish
an
encryption,
and
then
they'll
start
talking
to
one
another.
B
This
is
also
how
authorization
policies
in
istio
are
built
on
upon
this
principle,
so
with
istio
authorization
policies
when
you
say
like
I,
want
an
authorization
policy
that
says
this
particular
service
account
is
allowed
to
talk
to
this
application
or
an
application
with
this
set
of
labels.
What
that
translates
to
is
Envoy
configuration,
that
is
a
filter
for
exactly
what
that
identity
is.
What
that
spiffy
idea
is
so
Envoy
in
every
single
pod
knows
what
identity
is
able
to.
B
Then
it
it's
able
to
talk
that
Envoy
in
every
pod
knows
which
identity
is
allowed
to
talk
to
it.
So
that's
how
it's
able
to
say
yep
you're
allowed
to
talk
to
me.
It
says
here
that
you
know
what
you
can
talk
on
Port
9080.
This
is
the
path
you
can
talk
on
et
cetera,
so
that's
how
it's
able
to
establish.
So
the
key
takeaways
from
that
side
is
that
the
the
enforcement
point
is
happening
on
the
envoy
on
this
on
the
server
level.
B
So,
if
userpod
wants
to
talk
to
the
prefer
preferences
pod,
the
the
enforcement
point
is
happening
at
the
envoy
on
the
preferences
pod.
So,
basically,
on
the
server
side
and
it's
using
the
strong
identity
to
to
to
build
this,
this
filter,
but
what
if
the
certs
are
compromised,
meaning
I
mean
this
doesn't
happen
I.
Hopefully
this
shouldn't
happen
often,
but
what?
If
that
that
that
certificate
information
is
compromised
for,
for
whatever
reason,
maybe
you're
you
you've
lost
track
of
you
know,
keeping
your
ca
secure
or
you
have
a
vulnerability
in
one
of
your
pods.
B
That's
that's
extracting
that
information
right.
So
you
need
to
prevent
against
things
like
this.
If,
if
a
particular
certificate
information
for
a
given
pot
is
lost,
that
means
another
pod
can
increase,
can
can
Can
can
act
like
the
same
pod
and
talk
to
whoever
that
pod
was
originally
intended
to?
Can
all
pods
talk
to
one
another?
Now,
no,
it's
only
that
one
certificate
information
for
that
one
identity
is
now
compromised.
B
The
another
big
reason
why
users
adopt
istio
is
that
they
want
to
be
able
to
enforce
Ingress
and
egress
policies.
So,
let's
focus
on
egress,
for
example.
If
you
want
to
say
that
you
don't
want
applications
talking
to
an
external
endpoint
without
explicit
Declaration
on
what
those
endpoints
are,
that
is
also
enforced
by
Envoy
in
that
particular
pod.
So
it's
also
enforced
by
that
proxy.
So
again,
what
happens
if
the
application
is
somehow
able
to
bypass
that
proxy
right?
We're
we're
we're
relying
on
these
iptables
rules
or
cni
to
redirect
all
traffic
to
the
proxy.
B
B
So
next,
so
that's
where
things
like
having
that
second
layer
really
come
into
play.
So
let's
talk
about
psyllium
for
a
second,
so
celium
is
a
cni
right,
so
you
know
at
the
core
of
it.
It
you
know,
watches
all
pods
that
are
coming
up
in
the
in
the
cluster.
It's
able
to
give
them
an
IP
address.
It's
able
to
keep
track
of.
You
know
who's
allowed
to
talk
to
who
and
it's
able
to
maintain
that
that
Network
overlay,
so
that
communication
between
one
another
is,
is
basically
being
declared
and
created
by
by
celium.
B
If
you
look
at
the
CLM
set
of
features
that
it
offers
it
kind
of
looks
very
similar
to
the
istio
set
of
features
that
it
offers
right.
It's
you
know,
identity,
aware,
security,
Advanced,
Network
policies,
multi-cluster
connectivity,
service
load,
balancing
Etc.
So
how
is
it
able
to
do
seemingly
something
similar
and
I?
B
Things
like
what
are
the
labels
that
the
Pod
has
on
it,
what
the
service
account
that
it
was
that
was
used
to
to
spin
up
the
Pod
and
then
what
is
what
is
its
IP
address
and
it
takes
this
information
and
gives
it
an
identity,
but
that
identity
is
it's
just
like
an
integer,
it's
just
a
number
that
it
gives
it
and
says:
okay.
This
is
this:
this
pod,
it's
not
it's
not
a
certificate.
It's
not
like
a
strong
cryptographic,
cryptographic,
identity!
There's
no
certificates
involved
right.
B
So
if
you,
it
is
possible
to
do
things
like
to
have
like
a
like
Network
spoofing,
where
another
pod
can
maybe
take
that
that
same
IP
address
that
was
previously
assigned
to
this
and
trick
this
system
or
if
there's
a
lot
of
churn
in
the
in
the
cluster
like
a
lot
of
PODS
coming
up
and
down,
it
is
possible
that
a
pod
goes
down.
Another
pod
comes
up
with
the
same
IP
address,
and
then
the
celium
agent
did
not
pick
up
this
change
fast
enough
and
and
push
its
identity
to
all
the
various
ceiling
agents.
B
The
way
to
keep
tracks
of
all
this
identity
is
that
on
every
single
node
there's
a
celium
agent
and
that
agent
is
what
is
keeping
track
of
all
the
new
pods
that
are
coming
up,
assigning
an
identity
to
it,
and
it
has
to
share
that
information
with
the
other
agents,
the
other
nodes,
the
agents
that
are
running
in
the
other
nodes
in
that
cluster.
So
there
is
this,
this
state
that
has
to
be
constructed
so
really
like.
B
So
the
way
you
would
enforce
a
celium
network
policy
at
a
layer,
three
layer,
four,
you
know
layer,
three
being
IP
layer,
four
being
port,
for
example,
is
you
can
say
you
can
use
those
those
those
match
labels
to
identify
which
pod
you
want
to
talk
from
which
part
you
want
to
talk
to,
and
then
you
can
say
that
that
communication
is
allowed.
So
if
you
create
just
a
layer,
3
layer,
4
policy,
then
the
enforcement
point
is
basically
that
that
CLM
evpf
layer
that
connects
the
two
pieces
together.
B
B
Celium
also
has
layer,
7
policy,
so
meaning
you
can
add
stuff
like
HTTP,
verbs
or
paths
or
things
like
regular
expression
stuff.
That's
in
the
request
metadata
that
that
you
want
this
policy
to
parse
and
then
enforce
it.
There's
no
way
to
do
that
with
ebpf
directly,
because
you
need
something
like
a
layer,
7
parser
like
Envoy,
to
be
able
to
understand
that
request.
So
the
way
celium
accomplishes.
That
is
that
it
spins
up
a
brand
new
Envoy
process
in
the
celium
agent
pod,
and
then
traffic
gets
redirected
to
that
pod.
B
So
you
can
probably
already
tell
like
okay
there's
a
single
Envoy
pod,
that's
being
shared
for
all
traffic,
that's
coming
through
this
agent.
So
then
you
start
having
multi-tenancy
problems.
You
know
we
talked
about
that
in
the
in
the
ambient
Workshop
a
little
earlier
today,
where
you
have
to
be
careful
about
how
you
do
multi-tenancy
and
Envoy,
you
can
have
Noisy
Neighbor
problems,
because
you
can
extend
envoys
to
do
complex,
expensive
operations
that
you
don't
want
other
pods
in
the
network,
other
requests
that
are
coming
in
to
be
impacted
by
that.
B
So
you
don't
have
quite
have
this
independent
level
of
tenancy
and
there's
also
identity.
Right,
like
you,
don't
want
a
single
Envoy
to
be
able
to
manage
traffic
coming
from
all
identities
coming
in
and
out
of
your
network.
So
we
think
that
this
model,
while
this
is
a
fallback
that
can
get
you
there
at
the
end
of
the
day.
This
is
this-
is
Envoy
doing
layer,
7
stuff.
This
is
istio's
expertise.
Leave
this
to
istio.
Leave
layer,
7
stuff
to
to
istio
there's
already
any
steel
control
plane,
there's
already
an
istio
Envoy.
B
B
So
what
we
do
with
with
glue
is
kind
of
help.
You
abstract
away
all
these
implementation
details,
whether
you
have
to
create
a
network
policy
or
or
an
istio
authorization
policy,
or
you
need
both.
That's
something
that,
if
you
didn't
have
a
management
plan,
you
would
have
to
figure
out
on
a
per
application
basis.
So
again,
it's
a
lot
of
of
potential
areas
for
you
to
make
make
a
mistake
in
the
system
and
misconfigure
it
or
not,
even
configure
it
from
the
beginning,
you're,
leaving
it
up
to
your
developers.
B
That's
where
something
like
a
management
plane
that
can
or
like
this
glue
platform.
That
knows
about
all
the
applications
in
your
set
of
clusters
and
it's
able
to
dynamically
determine.
Where
is
this
application?
Where
is
this
application
that
you're
trying
to
talk
to?
Is
there
a
celium
installed?
Is
there
istio
installed
and
it's
able
to
lay
down
the
right
policies
in
it
can
intelligently
determine
based
on
what's
installed
what
you
have
declared
in
your
kubernetes,
your
deployment,
your
container
ports,
your
service
definitions.
B
We
can
get
you
most
of
the
way
there
in
a
zero
trust
posture.
So
that's
where
a
management
plane
that
knows
your
entire
environment
holistically
gives
you
that
central
place
of
intelligently
being
able
to
create
policies
and
one
big
construct
that
we
use
to
be
able
to
do
that
are
what's
called
workspaces.
Think
of
workspace
as
just
a
set
of
namespaces
a
grouping
of
namespaces
across
clusters.
You
can
say
like
this
namespace
and
this
cluster,
and
these
two
namespaces
and
this
other
namespace
in
this
third
cluster
are
one
team.
B
That
is
how
you
declare
a
single
workspace
right
and
then
you
can
create
multiple
workspaces
like
that.
So
now,
what
you've,
given
the
glue
platform,
is
information
about
your
organizational
boundaries
from
that
information
glue
can
automatically
determine
what
the
boundaries
are.
What
the
istio
authorization
policy
should
look
like
what
the
network
policies
should
look
like,
so
it
can
lay
down
this
defense
in
depth.
It
can
lay
down
multiple
layers
of
policy
automatically
for
you
and
with
using
construct
like
exports
and
imports.
You
can
tweak
it
appropriately
or
you
can
take
over
full
control.
B
If
you
choose
to
you
need
to
do
that.
So
that's
what
the
management
plane
does
is.
You
know
we
hope
to
give
you
a
single
place
for
you
to
apply
this
policy
or
this
workspace
construct
to
group
your
applications
together
and
then
the
management
plan
automatically
determine
you
have
this
version
of
celium
installed
on
this
cluster,
and
you
have
istio
and
psyllium
installed
on
this
other
cluster
and
be
able
to
push
those
policies
automatically
for
you.
B
If
you
take
one
of
the
applications
and
move
it
from
one
cluster
to
another
cluster,
the
management
plane
knows
that
and
it's
able
to
update
the
policy
automatically.
So
it's
just
one
more
way
that
your
life
is
simpler
or
is
simplified
by
not
having
to
create
those
policies
manually
and
then
best
of
all.
It
goes
and
Aggregates
all
the
metrics
information
that
celium
connect
collects
that
the
sidecars
collect
that
ambient
collects,
pull
it
all
back
to
the
management
plane
and
give
you
a
Unified
Service
graph.
B
B
You
know
a
result
like
this,
where
experts
like
Lin
and
Yuval
and
Eton
and
Scott
and
and
Christian,
have
go
into
this
in
much
more
details
than
than
I
did
you
know
I
think
I
covered
like
three
different
big
sections
of
of
Defense
in
depth,
but
you
know
if
you
will
go
watch
these
videos
you'll,
get
it
in
much
more
detail.
So
with
that
I
want
to
say
thank
you,
and
if
you
have
any
questions
you
can
reach
out
to
me
at
romio
or
on
our
slack
Channel.