►
Description
SoloCon 2022:
Improving Your Service Mesh Security Model for Istio and Gloo Mesh
Speakers:
Ram Vennam
Field Engineer, Solo.io
Eitan Yarmush
Architect in the Office of the CTO, Solo.io
Session Abstract:
The speakers of this session have a tremendous amount of experience architecting cloud native solutions for financial companies to run workloads in the strict compliance driven environments. Even if you are not required to adhere to a data compliance standard, there are many security best practice guidelines that every company should follow. In this session, we will share how to improve your application and platform security posture by covering topics such as certificate management, data isolation, authentication and authorization flows and more.
Track:
Service Mesh and Application Networking
A
Hi
everyone
and
welcome
to
improving
your
service
mesh
security
model
tips
for
increasing
the
security
posture
of
your
surface
mesh
using
istio
and
glue
mesh.
My
name
is
eitanyarmish.
I
am
an
architect
at
solo,
io
and
I've
been
working
with
envoy,
istio
and
many
other
cloud
native
networking
technologies
for
the
past
three
years.
B
Great
and
I'm
ron
venom,
I'm
one
of
the
field
engineers
here
at
solo
I
joined
solo
about
a
year
ago.
I
mostly
focus
on
istio
glumesh
and
blue
edge,
but
I've
been
working
on
istio
for
over
three
years
now,
before
solo,
I
was
at
ibm
where
I
also
served
on
the
istio
steering
committee
for
a
couple
of
years
yeah
I
really
enjoy
working
with
customers
to
help
them
adopt
kubernetes
and
istio.
So
that's
kind
of
what
I
do
full
time
now.
B
Today
we
want
to
talk
about,
you
know
mostly
narrow
down
the
conversation
around
security.
What
are
the
reasons
why
people
adopt
a
service
mesh
and
how
can
they
can
go
about
securing
and
making
sure
that
they
are
leveraging
features
that
a
service
mesh
offers
and
how
to
structure
their
environment
properly?
B
B
B
All
right,
zero
trust
networking.
I
think
this
is
a
buzzword
that
is
gaining
in
popularity
quite
a
bit
recently
and
only
seems
to
be
growing
more
and
more
and
and
really
it
kind
of
boils
down
to
our
need
to
solve
the
complexity
that
that
we're
now
seeing
from
a
switch
from
monolith
to
microservice,
because
we
no
longer
have
that
simple,
clearly
defined
perimeter
boundary
for
your
one
application.
Now
you
have
all
of
these
various
applications.
B
Service
mesh
aims
to
solve
a
lot
of
these
challenges
that
people
are
looking
to
address
with
when
they
want
to
implement
a
zero
trust
posture
in
their
in
their
kubernetes
environment.
So,
as
a
quick
recap
of
how
the
service
mesh
works,
essentially
a
proxy
gets
injected
next
to
each
one
of
your
applications
inside
the
kubernetes
cluster.
So
if
your
application
is
a
container
that's
running
inside
of
a
pod
in
kubernetes
with
the
service
mesh,
you
would
have
a
proxy
that
sits
next
to
that
container.
B
The
proxy
is
also
a
container,
and
both
of
these
containers
would
run
inside
the
same
same
pot
and
this
proxy
envoy
proxy
for
in
the
case
of
istio
service
mesh.
This
proxy
is
programmed
to
intercept
all
incoming
and
outgoing
traffic,
and
that's
this
is
really
where
all
of
the
the
magic
happens.
This
proxy
can
start.
You
know
mtls
communication
when
talking
to
one
pod
from
from
another
one
pod
to
another
pod,
so
that
mtls,
encryption
and
handshake
and
authentication
is
all
done
by
by
the
proxy
and
then
the
istio
control
plane
is
responsible
for
programming.
B
These
proxies
with
the
logic
that
you
want,
whether
that's
layer,
7
traffic
policies
or
authorization
policies.
You
don't
have
to
write
envoy
configuration
which
can
be
you
know,
kind
of
verbose
and
complex.
You
write
istio
configuration
which
then
istio
control
plane
will
translate
that
and
distribute
it
to
each
one
of
the
envoy
proxies.
B
So
the
main
feature
that
istio
provides
in
in
terms
of
zero
trust
networking
is
is
actually
two
main
features.
Is
one
this
encryption
from
service
to
service.
So
when
workload,
a
talks
to
workload
b,
the
proxy
on
workload,
a
will
intercept
that
request.
It
will
initiate
an
mtls
connection
to
the
proxy
on
workload
b
and
then
that
proxy
will
receive
that
connection.
B
Do
the
mtls,
handshake
the
pls
termination
and
then
go
on
over
to
workload
b,
and
the
beauty
of
it
is
that
these
workloads
are
now
talking
to
each
other
using
encrypted
mtls
traffic
without
them
actually
making
any
change
to
the
source
code.
So
it's
all
kind
of
transparent
and
done
in
the
proxy
layer.
B
The
the
second
piece
is
the
authorization
and
authentication
flows,
so
istio
provides
a
strong
identity
to
each
one
of
your
workloads.
So
workload
a
has
a
strong
identity
workload
b
has
a
strong
identity
and
then
which
will
allow
you
to
do
authorization
policies,
so
policies
that
say
workload
a
is
allowed
to
talk
to
workload
b,
et
cetera,
and
you
can
get
pretty
granular
when
you
write
these
these
policies
so
because
envoy's
operating
at
a
layer,
7
model,
it
can
understand
what
and
what
the
traffic
is.
B
B
So
with
with
the
zero
trust
network
the
way
you'd
go
about
implementing
it
is
you
would
first
put
down
a
deny
all
policy,
which
means
no
pod
is
allowed
to
talk
to
any
other
pod
and
then
layer.
All
these
authorization
policies
on
top
one
thing
we've
learned
is
that
our
customers
have
like
a
multi-cluster
environment.
You
know
multi
multi-cloud
providers.
B
In
fact,
and
writing
these
authorization
policies
across
multiple
clusters
or
as
workloads
are
moving
from
cluster
to
cluster,
can
become
pretty
pretty
complex
and
you're.
Writing
a
lot
of
policies
and
constantly
having
to
keep
up
with
what's
changing
glue
mesh
is
a
solos.
You
know
istio
offering
right
it's
it's.
Our
istio
enterprise
offering
and
glue
mesh
comes
with
a
management
plane
that
essentially
does
service
discovery
across
all
of
your
remote
clusters
and
is
able
to
propagate
important
information
from
one
one
cluster
to
another.
B
One
of
the
main
reasons
people
adopt
this
multi-cluster
model
is
so
that
they
can
deploy
an
application
across
multiple
clusters
and
talk
to
one
another.
Have
applications
talk
to
one
another
seamlessly
without
you
know
having
to
go
outside
the
network
and
come
back
in
through
traditional,
like
ingress
routes.
B
Instead,
they
can
just
applications,
will
just
treat
the
entire
across
all
their
clusters,
as
kind
of
one
large
mesh
and
they're
able
to
talk
to
one
another
failover
from
one
application
to
another.
When
the
local
instance
of
a
service
is
down
et
cetera,
the
benefit
of
this
when
dealing
with
zero
trust
network
is
that
you
can
write
your
policies
in
the
one
management
plan
and
have
the
management
plan,
translate
those
policies
to
lower
level
istio's
authorization
policies
and
distribute
that
to
each
one
of
your
workload
clusters.
B
So
a
policy
would
look
something
an
access
policy
in
glue
mesh
would
look
something
like
this,
where
you
can
specify
a
source
and
a
destination,
and
then
this
api
is
multi-cluster
aware.
So
you
can,
you
can
be
specific
on
which
cluster
you
want
to
apply
this
on
or
if
you
don't
specify
a
cluster
name,
for
example,
in
the
destination
selector.
B
I
don't
have
a
cluster
name
in
this
example,
it
gets
applied
to
wherever
the
product
page
application
currently
is
living,
so
blue
mesh,
the
management
plane
knows
where
product
page
is
living
and
it's
able
to
apply
that
policy
to
product
page
on
that
cluster.
If,
tomorrow
you,
the
developer,
decides
to
move
that
application
from
cluster
one
to
cluster
two,
the
access
policies
don't
have
to
change,
and
that's
that's
very
key.
B
Another
thing:
that's
important.
Is
you
need
to
be
able
to
monitor
that
the
policies
that
you're
applying
are,
in
fact
being
applied
and
they're
applied
to
the
right
workloads?
A
dashboard
is
actually
very
useful.
We've
learned
that
our
users
are
doing
is
that
they
would
apply
access
policies
and
then
go
check
the
dashboards
to
see
what
workloads
it
actually
got
applied
to.
So
that
example,
I
showed
in
the
previous
slide.
B
You
can
see
that
you
know
it
got
applied
to
that's
the
ingress
gateway
deployment
workload
as
a
source
and
then
a
destination,
and
then
you
can
also
see
which
paths,
methods
and
ports
are
allowed
a
lot
of
times.
The
person
that
is
responsible
for
for
enforcing
these
policies
might
not
have
the
necessary
skills
to
understand.
Like
you
know,
kubernetes
yaml
schema
schematics,
so
for
them
a
ui
like
this
is
greatly
helpful
to
make
sure
that
you
do
have
the
right
policies
in
place.
B
There's
also.
You
should
also
leverage
a
service
graph.
A
service
graph
will
will
show
live
traffic
flowing
from
application
to
application
so
that
you
can
make
sure
that
you're
applying
the
right
access
policies,
but
also
see
if
you've
missed
something.
A
service
graph
is
is
pretty
good
in
an
initial
implementation
of
access
policies
as
well.
So
there's
two
ways
to
of
when
you
first
want
to
start
writing
access
policies.
B
B
So
there
there
needs
to
be
this
like
tenancy
model,
that's
missing
in
istio,
so
with
glue
match.
We
want
to
introduce
that
by
by
this
concept
of
a
workspace,
which
is
a
logical
grouping
of
think
of
it,
as
like
name
spaces
that
you
can
across
multiple
clusters
that
you
can
group
together
and
say
this
is
my
team.
A
this
is
my
team
b.
This
is
my
gateway
team
and
then
you're
able
to
apply
policies
across
all
of
the
workspaces
or
export
and
import
policies
from
other
workspaces.
B
B
The
next
piece
I
want
to
cover
is
data,
isolation
and
boundaries
working
with
some
of
our
larger
clients,
especially
the
ones
in
the
finance
category
they
have
to
imply.
They
have
to
they're
adopting
service
mesh
because
they're
trying
to
meet
the
compliance
requirements
from
like,
let's
say
pci
or
you
know,
nist
or
fedramp,
and
and
these
compliances
essentially
you
know,
boil
down
to
being
able
to
categorize
their
applications
properly
like
card
holder
data
applications
need
to
be,
you
know,
dealt
with
differently
than
than
normal,
traditional,
like
non-sensitive
applications.
B
They
need
to
monitor
how
data
is
flowing
where
data
is
being
stored,
as
well
as
how
traffic
is
going
from
one
to
another.
They
need
to
enforce
ingress
and
egress
policies
to
make
sure
that
every
application
is
only
allowed
to
is
only
talking
to
who
it
needs
to
talk
to,
and
it's
not,
you
know
able
to
talk
to
anyone
else,
especially
with
microservices.
B
So
we
do
a
lot
of
work
with
with
our
customers
to
help
them
build
these
like
these
boundaries,
even
inside
of
their
kubernetes
cluster.
So
with
istio
the
proxy
that's
next
to
each
one
of
your
application.
Containers
is
responsible
for
protecting
that
application
from
making
any
calls
that
it's
not
supposed
to,
but
it's
not
a
100
fail-proof
solution.
B
So
one
of
the
things
that
we
do
is
you
know
recommend
that
your
application
containers
are
all
get
an
affinity
all
get
scheduled
to
worker
nodes
that
don't
have
internet
access
so
that
they
can't
break
out
and
go
talk
to
an
external
endpoint,
and
only
your
ingress
gateway
and
egress
gateway.
Pods
are
are
scheduled
on
nodes
that
have
internet
access,
so
making
sure
that
you
have
your
teams
and
toleration
set
in
place
so
that
you
do
have
these
boundaries
and
then
for
each
one
of
your
applications.
B
The
problem
is
only
exacerbated
when
you're
dealing
with
multiple
clusters,
but
it
but
it.
But
it's,
but
it's
kind
of
like
a
twofold
solution.
A
lot
of
customers
will
put
all
of
their
sensitive
data
in
a
separate
cluster
altogether
and
not
rely
on
like
kubernetes
concepts
to
to
to
delineate
the
two
which
is
good,
because
now
you
have
this
like
better
isolation.
B
But
now
you
need
the
ability
for
one
cluster
to
talk
to
another
cluster
and,
and
that
also
avoids
that
boils
down
to
you
know
a
set
of
best
practices
around
how
you
deploy
your
ingress
gateways,
which
name
spaces.
Do
they
go
into?
What's
their
affinity
policy
and
making
sure
that
gateways
that
are
responsible
for
east-west
traffic
are
in
are
using
a
private
subnet
as
opposed
to
a
public
one,
etc.
B
B
One
interesting
use
case
we
had
from
a
customer
is
they
wanted
to
span
their
their
application,
workload
and
environment
across
private
and
public
cloud,
so
their
their
data
center
kubernetes
clusters
and
public
cloud
kubernetes
clusters,
and
they
wanted
to
deploy
applications
across
the
two
and
have
the
applications
not
know
where
they're
sitting
and
be
able
to
fail
over
or
talk
to.
You
know
back
and
forth
without
the
applications
knowing
about
their
their
their
current
residence.
B
But
you
know
for
their
compliance
reasons.
They
do
have
this
requirement
that
there's
a
dmz
in
the
middle
and
that
dmz
is
responsible
for
making
sure
that
the
traffic
that's
going
through
it.
The
company
needs
to
be
able
to
inspect
that
traffic,
so
we
have,
to
you,
know,
build
a
solution
where
this
dmz
is
is
a
bare
metal
environment,
where
the
only
thing
they
can
run
is
a
docker
image
and
have
traffic
flow
through
that
docker
image.
A
Thank
you
so
much
rob.
I
don't
know
about
the
rest
y'all,
but
I
certainly
learned
a
lot
so
with
that-
let's
jump
into
it.
So
you
know
now
that
we've
discussed
boundaries
and
coordinating
off
our
services
by
different
levels
of
trust
and
boundaries.
As
I
mentioned,
let's
talk
about
how
that
trust
is
actually
implemented
and
the
way
that
the
trust
relationships
are
enforced
in
underlying
an
istio
is
with
certificates,
and
so
how
do
we
ensure
that
we
are
managing
our
certificates
properly
in
istio?
Well
to
talk
about
that?
A
Let's
just
briefly
talk
about
how
istio
how
certificates
work
in
istio,
specifically
with
the
mtls
traffic
that
rob
mentioned
earlier,
how,
when
the
traffic
leaves
your
application,
it
goes
into
envoy,
is
encrypted
sent
to
another
envoy,
sidecar
and
decrypted.
So
when
the
traffic
comes
through,
this
is
at
a
at
a
at
a
high
level,
assuming
you
have
traffic
flowing
into
an
ingress
to
a
proxy
one
through
end
of
them
and
then
out
through
through
an
egress,
but
just
to
just
just
to
get
the
lay
of
the
land.
A
So
when
the
traffic
comes
in
it'll,
be
it
to
the
ingress
and
then
it
flows
from
the
ingress
to
the
proxy.
So
when
it
does
that
again,
the
traffic
is
mtls.
So
how
do
those
certificates
get
there?
Well
has
a
ca,
and
so
that's
the
the
main
way
that
the
the
certificates
are
then
provisioned
to
each
one
of
the
workloads
that
they
can
perform.
A
A
A
Essentially
each
service,
each
istio,
each
sidecar
is
actually
a
little
go
program
called
the
istio
agent
and
that
istio
agent
is
actually
managing
the
lifetime
of
envoy
in
the
sidecar
and
the
one
other
responsibility
that
that
agent
has
is
to
send
out
what's
called
a
csr
or
a
certificate
signing
request,
and
so
what
is
a
certificate
signing
request
well
in
typical
tls
land?
That
is
a
it
has
an
exact
meaning.
It's
it's
something
that
is
used
to
sign
a
certificate.
A
A
So
again,
when
sdod
receives
that
request,
it
then
essentially
asks
that
the
certificate
authority
which
the
certificate
authority
in
a
standard,
istio
deployment,
if
you
were
to
let's
say,
do
istio
ctl
install,
which
is
certainly
how
I
install
istio
these
days.
It
will
create
a
a
ca
certificate
for
you
now.
This
is
not
a
great
idea
in
any
kind
of
production
environment,
it's
great
to
start
just
to
start
using
istio.
However,
if
your
your
root
of
trust
is
generated
by
istio,
then
you
don't
own
it
and
you
will
need
to
rotate
it
right.
A
So
there's
no
there's
no
real
way
to
rotate
it.
If
someone
were
to
steal
it.
This
is
a
problem.
It's
not
really
secure!
It's
just
in
a
secret
living
on
your
cluster.
There
are
many
issues
with
it,
so
that
is
just
the
startup
and
a
brief
explanation
of
how
the
one
how
the
proxy
gets
its
certificate
and
then
how
istio
d
signs
that
certificate.
A
However,
this
is
not
the
only
option,
as
I
mentioned
this,
the
csr
request
that
comes
from
the
agent.
It's
just
a
pro.
It's
just
a
grpc
request,
so
other
people
can
fulfill
those
requests.
One
example
of
doing
this
is
cert
manager.
So
those
who
don't
know
cert
manager
is
a
very
popular
certificate
manager,
software
written
by
jetstack,
and
it
has
a
whole
bunch
of
uses
and
one
one
of
them
is
as
a
basically
as
a
target
of
the
csr.
A
So
what
does
that
mean?
That
means
that
the
instead
of
istio
d,
managing
signing
all
those
certificates
and
managing
the
identities
of
your
workloads
instead
cert
manager
is
doing
that,
and
that
gives
us
a
lot
of
power,
because
cert
manager
can
actually
use
a
bunch
of
different
back
ends
to
sign
those
certs.
A
So
in
this
in
this
diagram
taken
from
their
website
they're
using
venify,
but
you
can
also
use
vault
or
a
lot
of
other
external
plugins
that
they
let
you
use
so
the
flow
here
instead
of
again,
instead
of
going
to
sdid
you'd
go
to
this
search
manager,
plugin,
but
then,
however,
you're
you're
offloading
the
certificate
signing
from
sdod
to
sir
manager
and
by
serve
manager.
I
mean
your
internal
pki.
So
there
are,
there
is
a.
There
are
good
things
and
bad
things
going
on
here.
A
One
you're
using
your
own
internal
pki,
which
is
good
right.
You
can
you
have
your
own
cert
that
you
use
for
lots
of
different
services.
You
have
it
secured
it's
in.
It's
involved
it's
in
venifi,
it's
an
aws
pca.
You
know
it's.
There
are
all
sorts
of
different
cloud
services
out
there
to
manage
these
certificates,
so
it's
more
secure
than
living
on
the
cluster.
A
However,
now
all
of
a
sudden,
all
of
your
workload,
traffic
is
all
of
your
workload-
starts-
are
getting
signed
by
your
internal
pki.
So
that
means
that
if
you
were
to
have
a
node,
rollout
or
any
kind
of
event,
where
lots
of
workflows
need
to
come
up
quickly,
you
could
overload
your
pki
and
that
would
be
really
really
really
really
bad.
So
there
are
again
there
are
benefits
to
this,
but
there
are
also
some
downsides
that
really
need
to
be
kept
in
mind
depending
on
the
scale
of
your
deployment.
A
So
we've
definitely
taken
a
step
up.
We
have.
We
have
taken
we've
ripped
out,
istio's,
ca
right
and
we've
replaced
it
with
our
own
pki,
but
you
know:
we've
also
taken
a
step
back,
because
now
we
can
overwhelm
our
pki.
So,
let's,
let's,
let's
keep
looking
about
what
we
can
to
see
what
we
can
do
about
this.
A
A
So
I
there
are
again
ups
and
downs
to
this
approach
and
this
one
can
work
well
for
certain
situations,
especially
if
you
happen
to
have
all
of
this
in
githubs
and
you
have
in
a
single
cluster
but
right
in
the
second
we're
going
to
talk
about
how
this
doesn't
scale.
When
you
get
to
multiple
clusters.
A
So
now
we've
got
multiple
clusters
and
all
of
a
sudden,
I,
the
user,
need
to
manage
signing
a
whole
bunch
of
intermediate
certs
and
distributing
them
to
my
workload
clusters.
Now
you
might
say:
okay,
that's
not
so
bad
right
like
I,
I
can
do
that
once
or
maybe
whenever
they
need
to
be
rotated.
You
know
once
a
year
once
every
three
years,
however
often
you
know
you
set
your
your
certain
lifetimes
too,
but
all
of
a
sudden.
A
So
with
that
in
mind,
let's
talk
about
blue
mesh
and
how
glue
mesh
can
help
you
solve
this
problem
glue
mesh
ships
with
a
component
that
we
call
the
istiod
agent
sidecar.
Now?
What
does
this
sidecar
do?
Essentially,
it's
really
the
best
of
both
worlds.
This
sidecar
lives
as
a
it
lives
next
to
istio
d.
So,
typically
in
istio
the
side
cars
live
next
to
your
apps.
Well,
we
have
a
side
car
for
istio
d,
and
how
does
this
sidecar
differ
from?
Let's
say
the
normal
vault
sidecar,
which
can
provision
secrets.
A
The
difference
here
is
that
this
sidecar
will
actually
communicate
you
you,
as
a
user,
you
tell
glue
mesh
that
you
want
to
connect
all
of
your
meshes
right.
You
want
to
provision
certs
from
the
same
route
to
all
of
your
istio
instances,
and
our
agent
sidecar
will
then
go
ahead
and
communicate
with
vault,
and
we
will
then
take
that
signed
okay
and
put
it
in
an
ephemeral
volume
next
to
istio
d.
A
So
what
does
all
of
that
get
you
well
all
of
a
sudden
now
you're
managing
the
lifetime
and
placement
of
these
certificates
from
one
central
place,
which
is
one?
That's
an
amazing
benefit.
Two,
your
secrets
are
no
longer
in
a
cert
in
a
your
certificates,
are
no
longer
in
a
secret
they're
in
an
ephemeral
volume.
So
when
your
pods
restart
they're,
they're
gone
they're
not
stored
in
any
database
and
three
you've
taken
the
load
off
your
pki,
because
istio
is
still
signing
all
of
these
certificates.
A
A
So
what
is
the
edge?
Well,
we've
again,
we
we've
talked
all
about
securing
the
the
traffic
maintaining
boundaries,
having
identity,
ensuring
that
only
specific
workloads
can
talk
to
each
other
using
mtls
using
you
know,
certificate
best
practices
for
communicating
within
a
cluster
or
between
clusters,
but
we
haven't
talked
about
traffic
coming
in
to
your
mesh.
A
So,
typically,
the
way
traffic
comes
into
your
mesh
is
with
some
form
of
ingress
in
istio,
there's
the
istio
ingress
gateway,
but
there
are
some
unique
challenges
that
need
to
be
solved
at
the
edge
for,
for
instance,
the
requests
are
usually
from
known
or
unknown
entities
they're,
not
from
trusted
entities
like
inside
of
your
mesh,
and
so
for
that
reason
we
need
to
worry
about
things
like
authent,
like
authentication
external.
You
know
making
sure
that
the
the
the
requests
that
are
coming
in
to
the
mesh
are
verified
and
number
two.
A
We
might
need
to
worry
about
something,
like
rate
limiting,
to
ensure
that
the
users
are
not
spamming
right.
The
services
inside
of
the
mesh-
and
this
can
be
useful
inside
the
mesh
as
well-
do
not
get
me
wrong,
but
there
are
unique
opportunities
for
users
to
overload
services
externally.
So
we're
going
to
talk
about
that
quickly
and
how
you
can
set
that
up
in
istio,
so
just
to
briefly
discuss
what
these
different
strategies
are.
So
external
authorization
istio
essentially
authorized
the
request
prior
to
entering
the
mesh.
A
Now
this
can
come
in
a
few
forms,
one
of
these
being
oidc.
So
oauth,
you
know,
let's
say
you
log
in
with
google,
with
a
google
oidc
or
your
your
organization
uses
awsoadc
any
of
them
right
when
your
traffic
comes
into
the
mesh.
You
then
get
your
token
from
that
from
that
external
source
before
the
traffic
makes
its
way
into
the
mesh
or
you
could
be
an
api
key
right.
A
Let's
say
you
have
a
forward-facing
api
and
you
have
a
key
that
you
need
to
verify
et
cetera
and
for
rate,
limiting
right
you're,
limiting
the
number
of
requests
that
clients
can
make.
You
ensure
that
your
services
don't
get
overwhelmed
and
luckily
onboarding
istio
allow
you
to
do
this
on
many
dimensions,
for
instance
ip
geolocation
etc.
A
So
what
is
rate
limiting?
Look
like
well
when
you
rate
limit
in
istio,
essentially
when
the
when
the
traffic
comes
into
the
gateway
you
have
to
as
a
user,
you
have
to
deploy
a
rate
limit
server
such
that
the
gateway
can
actually
discuss.
Whether
or
not
this
request
should
be
rate
limited
okay.
So
as
a
user,
you
have
to
manage
deploying
that
server
as
well
as
configuring
it
and
then
configuring
the
gateway
to
speak
to
it
for
each
request.
A
A
However,
luckily
glue
mesh,
has
it
it
ships
with
all
these
components
out
of
the
box,
so
as
a
user
or
as
a
as
a
user
of
blue
mesh,
you
can
configure
your
rate
limit
policies
and
your
ex
off
policies
from
one
place
and
your
your
routes
will
automatically
reach
out
to
our
provided
xoth
and
rate
limit
server.
So
not
only
do
we
offer
rate
limit
servers
that
are
simpler
than
the
ones
offered
by
vanilla
istio,
but
we
also
had
our
xo
server
also
offers
oidc
api
key
and
other
integrations.
A
So
you
can
accomplish
that
all
all
in
one
place
without
needing
to
set
it
up
each
time
so
just
to
just
to
step
back
a
second
and
talk
about
edge
traffic.
So
when
we
talk
about
edge
traffic,
the
istio
ingress
gateway
can
definitely
get
you
up
and
running,
but
it
doesn't
come
with
everything
that
you
might
need
trying
to
protect
or
or
deal
with
your
individual
customer
use
cases.
So
here
we
can
see
that
an
api
gateway
has.
A
It
has
advanced
security
features
like
waff
and
dlp,
so
data
loss
prevention,
advanced
authentication,
transformations
rate
limiting,
as
mentioned
earlier,
traffic
routing
and
shaping.
So
these
are
all
different
features
that
allow
customers
to
use
to
use
these
these
technologies
in
their
own
way,
without
being
limited
by
the
small
subset
of
features
that
the
gateway
may
that
the
ingress
might
might
ship
with.
So
just
as
a
as
a
high-level
overview
of
what
glue
mesh
would
look
like
in
this
case
again
the
we
we
would.
A
We
have
our
own
filters
that
we
ship
with
in
our
distribution
of
istio,
and
so
those
filters
can
be
taken
advantage
of
when
designing
routes
into
your
system,
for
instance,
as
mentioned
data
loss
prevention,
so
we
can
mask
sensitive
data.
We
can
interact
directly
with
lambdas.
We
can
transform
your
traffic
et
cetera,
et
cetera,.
B
Yeah,
so
this
was
a.
This
was
like
a
whirlwind
session
where
we
covered
a
lot
of
topics
around
things
that
you
need
to
be
thinking
about
when
you're,
adopting
a
service
mesh
and
then
want
to
enforce
all
the
features
properly.
So
you
know,
if
you
have
any
questions
on
you
know
any
one
of
the
particular
topics,
and
you
want
to
drill
down
a
little
bit
more.
You
know
feel
free
to
reach
out
to
us
use
the
solo
I
o
slack
channel.
You
can
find
me
or
aton
we'd,
be
happy
to
go
into
more
details.