►
Description
Applications of all types including monoliths, microservices, serverless functions, and any combination of them often need a way for external clients and users to access them in a safe and secure way. As incoming requests can be numerous and varied, protecting backend services and globally enforcing business limits can become incredibly complex being handled at the application level.
Rate limiting is a strategy that can prevent service outages by protecting the service from being overrun with more requests than it’s resources can process and respond to within the agreed service levels. Rate limits can be set to limit the number of times the service can be called (per second, minute, hour) within a specified time period (total received in a day, week, month).
Attend this session to learn how to leverage Envoy Proxy at the edge to implement advanced rate limiting use cases:
* Configure multiple rate limits per client
* Secure rate limit actions with JSON Web Tokens (JWT)
* Combine rate limits with WAF and Auth
* Gloo control plane to manage Envoy configurations
Download the presentation https://speakerdeck.com/soloio/advanced-rate-limiting-use-cases-with-envoy-proxy-api-and-gloo-api-gateway
About Gloo https://www.solo.io/products/gloo/
Try the demos yourself https://bit.ly/2BDUpvW
Request a trial https://lp.solo.io/lp-request-a-trial-general
Questions? Join the community at https://slack.solo.io
A
Good
morning
or
good
afternoon,
everyone,
depending
on
where
you're
joining
us
from
my
name,
is
Betty
I'm
here
at
solo
I/o
and
today,
we're
excited
to
have
another
session
digging
into
various
use
cases
as
possible
with
glue
our
next
generation
API
gateway.
So
today
we
have
brick
to
Cod
director
of
engineering,
he's
gonna
talk
about
some
advanced
use
cases
for
rate
limiting
using
the
Envoy
API.
This
session
is
being
recorded,
so
we'll
send
out
the
recording
after
the
after
the
talk
and
also
this
slides.
B
So
we're
gonna
start
with
some
background,
though
pretty
quickly
in
this
session,
we're
going
to
kind
of
get
straight
into
some
demos
and
I'm
really
going
to
start
start
kind
of
with
the
basics,
but
quickly
get
into
some
more
advanced
use
cases
that
are
more
representative
of
things
that
our
customers
and
our
users
are
experiencing
as
some
backgrounds
and
what
is
very,
limiting
it's.
It's
really.
The
goal
is
to
protect
applications
and,
ultimately,
from
fill.
You
know
we're
trying
to
protect
from
failures
related
to
bursts
of
network
traffic,
which
could
be
intentional
or
unintentional.
B
We're
also
trying
to
potentially
tie
our
API.
Is
that
we're
exposing
with
our
application
and
generally
just
you
know,
encourage
kind
of
usage
patterns
that
fit
in
with
the
plan.
So,
if
we're
selling
an
API,
we
might
have
a
particular
quota
or
a
particular
plan
that
we're
selling,
alongside
it
so
rate,
limiting,
can
both
be
used
in
terms
of
protecting
your
application
and
it
can
be
used
as
a
way
of
kind
of
modeling.
Your
business
and
a
really
basic
example,
here
of
a
rate
limit
is
you
know,
I
might
want
to
enable
100
requests
per.
B
So
the
way
this
works
with
envoy
is
envoy
has
an
endpoint
and
essentially
with
envoy.
What
we're
doing
is
we're
constructing
these
kind
of
listener
configurations.
So
envoy
is
sitting
at
the
edge
of
our
application,
and
it's
listening
on
a
particular
report
and
when
a
request
comes
into
that
port
depending
on
whether
it
matches
on
you
know,
hostname
and
certain
criteria.
You've
configured
about
your
routes
envoy
will
then
apply
a
chain
of
filters.
B
The
last
one
being
kind
of
a
router
to
send
it
on
to
the
application,
and
one
of
the
filters
that
we
can
configure
with
glue
is
rate
limiting
now
glue
ships
a
so
the
way
that
this
filter
works
with
envoy
is
that
you
kind
of
plug
in
an
implementation
of
an
API
that
envoy
exposed,
which
is
a
G
RPC
API,
and
then
you
provide
essentially
a
service
that
envoy
can
connect
to
that.
Implements
that
so
we're
going
to
look
at
glues,
kind
of
built
in
out-of-the-box,
Enterprise,
rate-limiting
server.
B
Now,
in
terms
of
the
demos
that
we're
going
to
look
at
the
first
will
be
kind
of
configuring
limits
related
to
the
clients
so
saying
you
know,
I
want
to
make
sure
that
for
each
unique
client,
that's
accessing
my
application.
They
have
they.
You
know
X
requests
per
second,
we'll
get
into
some
more
advanced
cases.
B
Second,
we're
gonna
look
at
limiting
based
on
HTTP
methods.
In
addition
to
client,
ID
and
and
kind
of
this
is
related
to
a
use
case.
We
hear
often
called
load
shedding
and
third
we're
going
to
look
at
how
we
can
integrate
rate
limiting
with
things
like
the
JWT
filter
to
more
securely
enforce
limits
on
on
in
that
game.
In
this
case,
headers,
which
are
derived
from
claims
in
a
jot
I,
will
get
into
that
a
little
bit
later
for
the
first
use
case,
we're
going
to
look
at
rate
limiting
per
client.
B
Essentially,
you
know
the
idea
is
very
simple
and
it's
very
intuitive.
You
want
to
provide
unique
limits
for
different
users
that
are
accessing
the
service
and
we'll
get
to
a
pretty
complex
version
of
this.
Where,
potentially,
you
know,
we
would
want
multiple
rate
limits
for
the
same
remote
address,
potentially
to
kind
of
enforce
a
a
usage
plan
over
a
long
interval,
but
also
prevent
kind
of
bursts
of
traffic
and
smaller
intervals,
but
I'm
going
to
start
with
the
basics
and
shift
into
this
demo.
So
let
me
first
I'm
starting
from
really
a
blank
slate.
B
All
that
I've
done
is
installed.
Glu
CTL
and
I've
got
an
empty
gke
cluster
that
I've
that
I'm
working
with
and
for
the
purpose
of
these
demos,
I'm
just
going
to
be
using
a
little
bit
of
shorthand
in
my
command
line,
K
for
cube,
CTL
and
a
few
others,
but
as
we
can
see,
there's
nothing
installed
in
this
cluster.
B
What
I
would
recommend
doing
is
glue
CTL
upgrade.
It
looks
like
we've
got
an
issue
with
being
rate
limited
by
the
github
API
ironically,
but
we
can
come
back
to
that,
but
ultimately
I've
upgraded
to
the
latest
version
of
glue
CTO,
which
you
could
grab
from
the
releases
page
just
so
that
we're
installing
one
for
so.
This
is
a
new
release
that
came
out
enterprise
glue
one
for
zero.
We're
going
to
use
that
today
in
this
demo,
and
the
first
thing
I'll
do
is
actually
just
install
glue
Enterprise.
B
So
this
will
take
a
second
and
well.
This
is
going.
Let's
look
at
what
we're
going
to
be
installing.
So
the
first
thing
that
I
want
to
kind
of
talk
through
is
what
we're
going
to
in
terms
of
the
actual
service
that
we're
going
to
deploy
we're
going
to
deploy
this
very
simple
service
called
spelunker.
That's
really
just
here
for
helping
us
see
what's
going
on.
It
helps
show
the
example
and
with
glue
there's
two
bits
of
configuration.
We
need
to
configure
to
set
up
a
route
through
envoy.
B
B
I'm
also
applying,
and
now
it
so
now,
I'm
deploying
that
actual
applications,
voluntary
and
the
second
piece
of
configuration
to
get
this
kind
of
exposed
through
glue
is
the
actual
route
and
that's
what
that's
where
you
define
a
virtual
service.
So
this
is
a
very
simple
glue
configuration
that
says
to
match
on
any
domain
and
there's
just
a
single
route
with
a
prefix
slash.
So
really
any
path
to
any
domain
will
match
on
to
this
virtual
service,
and
this
configuration
just
says
forward
that
requests
to
our
spelunker
upstream.
B
Now
that
should
take
effect
pretty
quickly
we're
going
to
use
another
convenience
mechanism
here.
So
this
this
is
a
glue
CTL
command
to
get
the
actual
URL
for
the
the
service.
I'll
show
you
where
that's
coming
from
in
a
second,
but
as
we
can
see
when
we
curl
it
and
actually
I'll
just
turn
that
into
a,
and
so
when
we
curl
this
endpoint
on
any
path
we're
getting
forwarded,
and
this
is
kind
of
the
response
of
our
spelunker
service
and
just
to
get
a
sense
of
where
that
IP
address
is
coming
from.
B
I've
deployed
glue
to
gke
cluster
and
using
a
load
balancer
service.
This
is
our
gateway
proxy.
Our
Envoy
instance
is
actually
assigned
an
external
IP
by
Google's
load
balancers
and
that's
that's
the
UI.
That's
the
IP
address
that
glue,
see
tail
has
figured
out
to
be
the
URL
of
our
proxy,
and
so,
when
we
curl
that
you
know
it's
essentially
matching
on
that
single
route
that
we've
configured
forwarding
to
our
service.
B
So,
let's
take
a
look
at
what
actually
before
before
we
get
into
the
glue
config.
There
are
two
things
that
we
need
to
do
to
actually
set
up
remote
address,
forwarding
something
that
we
could
note.
If
we
look
at
the
response
that
we
got
from
this
curl
request,
our
spelunker
service
is
conveniently
printing
out
the
requests
and
the
headers
that
it
received-
and
something
to
note
here
is
this
request-
is
not
there's
no
indication
to
the
service
that
this
request
is
actually
coming
from
me
and
actually
Envoy.
B
You
know,
isn't
really
receiving
my
IP
address
my
public
IP
address
at
all,
that's
receiving
the
IP.
It
looks
like
this
request
is
coming
from
Google's
load
balancer.
What
we
really
want-
and
you
know
into-
obviously
we
don't
want
to
rate
limit
based
on
which
load
balance
or
the
requests
came
through
we're
trying
to
remit
based.
You
know
for
me,
and
so
what
we
need
to
do
is
set
up
the
remote
address
and
get
envoy
to
be
forwarding
the
correct
IP
address
of
my
address
in
the
x-forwarded-for
header,
so
there's
two
bits
of
configuration.
B
We
need
to
establish
to
enable
that
the
first
is.
We
want
to
tell
envoys
listener
that
it
should
be
using
the
remote
address,
so
this
is
a
configuration
that
essentially
gets
associated
with
the
route
that
we
had
set
up,
and
it
just
tells
the
connection
manager
to
just
to
set
that
up.
So
we
can
patch
our
gateway
object
with
that
configuration.
B
The
second
thing
that
we
need
to
do
is
we
need
to
instruct
the
actual
kubernetes
service
how
to
basically
that
with
a
traffic
policy,
so
that
it
knows
that
you
know
that
this
traffic
is
basically
coming
from
through
envoy,
and
it
should
also
honor
the
x-forwarded-for
header,
so
we'll
patch,
the
actual
kubernetes
service
for
envoy.
With
this
additional
configuration
and
that's
what
works
in
gke
with
other
cloud
providers,
it
might
require
a
slightly
different
configuration.
B
B
B
Wow,
this
is
getting
itself
configured
I'm,
going
to
just
like
jump
ahead
a
little
bit
and
talk
through
just
what
that
rate.
Limiting
configuration
looks
like
so
we're
gonna
start
with
the
simple
or
just
like
a
simple
version
of
this
use
case.
Let's
just
say
we
want
a
specific
rate
limit
per
client,
so
you
know
we'll
get
into
having
multiple
ones,
but
to
start,
let's
just
say
for
any
unique
user
for
any
unique
client
will
allow
five
requests
per
minute.
B
So,
first,
what
we'll
do
is
we'll
we'll
patch
our
glue
settings
to
setup
that,
as
a
rate
limit
descriptor
that
basically
establishes,
in
our
rate,
limit
server
that
for
this
tuple
for
this
kind
of
unique
client,
in
this
case
it's
a
tuple
of
one,
but
it's
the
unique
client
address.
This
is
the
limit
to
associate
with
it.
B
Okay,
as
we
can
see
so
jumping
back,
we,
the
the
service
change,
finally
took
effect.
Our
requests
are
now
going
through,
but
they
look
a
little
different.
What
we
now
have
going
to
our
service
is
the
actual
x-forwarded-for,
with
my
public
IP
address,
which
means
that
we
now
have
envoy
properly
forwarding
and
google
properly
forwarding
the
request,
as
we
expect,
and
we
can
rate
limit
on
this
header
cool.
B
Now,
that's
not
sufficient,
so
all
I've
done
is
set
up
the
possibility
of
using
rate
limiting,
but
what
I
haven't
done
is
actually
apply
it
to
our
particular
route,
so
I've
created,
in
other
words,
have
created
the
descriptors
I've
made
our
rhythm
at
server
aware
of
these
limits,
but
I
haven't
told
glue
that
we
should
be
kind
of
incrementing
our
counters
like
when
it
matches
on
this
particular
requests.
So
that's
the
other
half
of
the
config
that
we
need
to
actually
apply.
B
We
can
look
at
what
that
looks
like
so
here
was
our
original
virtual
service
that
created
that
route
to
our
destination
service
and
now,
we'll
just
add
this
option
to
turn
on
rate
limit
and
really
the
important
part
is
here.
All
we're
doing
is
rate
limiting,
based
on
a
single
kind
of
you
know,
we're
taking
a
single
rate
limit
action
means
we'll
increment
a
single
counter
for
the
tuple.
That
is
just
our
remote
address.
B
B
Navigate
like
SSH
into
our
cluster
into
one
of
our
boxes
that
happens
to
have
curl
installed,
so
I'll
be
running
this
essentially
from
the
node,
the
public
IP
address
of
the
node,
rather
than
my
own
personal
IP
address.
Let's
continue,
you
know,
let's
make
sure
this
stays
rate
limited.
We
can
actually
do
something
like
that,
so
we're
slamming
the
server
now,
but
what
we
should
see
I
need
to.
B
B
But
that
wasn't
really
sufficient
for
our
use
case.
So
this
is
a
great
start,
but
what
we
really
want
to
express
are
two
different
limits
in
practice.
Maybe
we've
got
you
know
a
single
plan
that
gives
an
overall
quota.
Let's
say
you
know
a
hundred
thousand
requests
per
month,
but
we
may
want
to
limit
our
traffic
inverse
so
that
they
don't
all
appear.
B
B
And
to
see
this,
we
probably
need
to
go
back
and
issue
a
bunch
of
requests,
but
we
can.
This
is
a
little
hard
to
read,
but
if
we
kind
of
look
back
through
the
history
now,
what
we're
seeing
is
you
know
some
requests
go
through
as
we
expect.
So
we
get
a
200,
it's
you
know
200,
but
we
do
start
to
get
rate
limited
because
for
each
second,
we're
only
allowed
one
request,
and
then
you
know
we
see
some
work
but
at
a
certain
point,
we'll
hit
our
overall
quota
or
permanent
quota.
B
And
then
every
request
is
getting
rate
limited
at
that
point.
So,
as
we
can
see
we're
kind
of
able
to
kind
of
work
with
both
of
these
different
limits,
we
can
see
them
both
take
effect,
and
in
this
way
we
can
start
to
create
much
more
kind
of
nuanced
complex
rules
that
better
reflect
the
usage
plan
that
you
might
want
to
set
up
with
your
users
when
you're
kind
of
selling
your
api's.
B
So
that's
about
it
for
the
first
demo,
I'm
gonna
go
back
to
just
to
kind
of
summarize
that
use
case.
What
we
did
is
you
know.
First,
we
took
a
look
at
just
how
to
rate
limit
based
on
unique
client.
We
prove
that
it
was
working,
but
more
more
realistically,
we
learned
how
to
create
several
different
limits
per
user
to
kind
of
create
a
usage
plan
that
better
reflects
both
long-term
quotas
and
kind
of
short
term
constraints
in
terms
of
burst
traffic.
B
So
we
can
move
on
to
the
second
demo,
and
this
is
really
kind
of
a
sister
to
the
first.
It's
going
to
be
a
lot
shorter,
but
really
what
we're
we're
kind
of
going
to
showcase
here
is
that
we
can
do
the
same
kind
of
thing
on
any
kind
of
other
key.
But
you
know
in
that
first
example:
I,
just
hard-coded
these
names
per
minute
and
per
second,
but
you
could
also
have
other
ways
of
defining
tuples.
In
this
case
we
could.
B
This
is
related
to
a
use
case
that
we
hear
from
customers
called
loadshedding
where
you
basically
have
kind
of
different
controls.
You
know
different
kind
of
fine-grained
ways
to
provide.
You
know
limits,
and
here
we're
leveraging
kind
of
the
fact
that
envoys
config
for
rate
limit
is
quite
expressive.
So
we
can
actually,
you
know
not
just
express
multiple
rules,
but
there's
kind
of
you
know
as
before.
B
B
So
first
I'm
just
going
to
apply
this
you
know
like
before
is
just
a
patch
to
our
settings
and
and
as
we've
been
seeing
that
that's
what
basically
triggers
glue
to
tell
the
rate
limit
server
here.
The
here
are
the
quotas
for
these
different
kind
of
tuples
of
descriptors,
and
then
we
can
connect
that
to
our
actual
route,
by
adding
the
rate
limit
options
and
creating
these
actions
on
our
route.
Now,
in
this
case,
the
actions
look
a
bit
different.
B
So
before
we
had
two
actions
that
both
you
know,
hadn't
had
a
generic
key
on
the
talk
once
said
per
minute.
One
said
per
second,
but
but
now
they
look
a
little
bit
different
because
you
know
we're
incrementing,
you
know
essentially
a
counter
just
for
the
remote
address.
That's
our
five
requests
per
second
limit
and
also
incrementing
a
counter
for
a
specific
methods.
B
B
B
So
now
what
we
should
see
you
know
our
default
HTTP
method
when
we
issue
these
curl
requests
is
get
so
we
should
see
our
limit
and
our
rate
limit
of
on
gets.
You
know
come
through
after
two,
just
as
we
expect
just
as
we
had
configured,
but
we
should
see
you
know
if
we
issue
other
methods.
We
see
that
we
aren't
hitting
that
limit.
I.
B
B
So
what
this
shows
is
you
know
we
can
really
do
something
similar
to
what
we
did
before,
but
we
don't
need
to
just
use
kind
of
a
generic.
You
know
per
minute
per
second
kind
of
key
to
identify.
You
know
which
part
of
the
plan
that
we're
in
we
can
actually
create
more
complex
logic.
You
know,
maybe
by
loadshedding
you
know
some
traffic
for
get
requests
that
are
coming
in,
as
in
this
example,.
B
B
So
at
this
point,
I'm
going
to
shift
gears
and
and
start
going
into
a
different
way
of
essentially
taking
action
on
rate
limiting.
So
up
until
now,
we've
been
we've
been
using
on
our
in
our
glue.
Config
we've
been
using.
Essentially
this
remote
address
as
a
way
to
kind
of
trigger
a
rate
limit
and
we've
been
using
some
other
things
like
the
generic
key
or
the
method
of
the
of
the
requests.
But
we
actually
have
a
pretty
extensive
ability
to
rate
limit
on
any
header
that
is
coming
in.
B
So
the
first
thing
I
want
to
do
is
talk
through
what
our
new
rules
are,
so
basically
we're
going
to
throw
out
all
the
config
we
had
before
around
remote
address
per
minute.
You
know
around
those
usage
plans
now
we're
going
to
have
two
criteria
to
rate
limit
on
the
first
and
they're
both
had
they're
both
going
to
be
headers,
though,
from
the
point
of
view
of
glue
settings.
B
It
doesn't
really
matter
where
they
come
from,
but
we'll
see
how
we
populate
them
in
a
second,
but
really
we're
going
to
have
two
different
kind
of
keys.
One
is
the
type
of
message,
and
the
other
is
the
number
of
the
message,
and
so
this
is
kind
of
pseudo.
It's
kind
of
simulating
a
Telecom
style
use
case
and
different
value.
Different
possible
types
include
things
like
messenger
and
whatsapp,
and
so
what
what
these
rules
are?
B
Basically
expressing
or
you
know
it's
using
a
few
different
features
of
glue,
called
nesting
and
rule
priority,
but
essentially
what
we're
expressing
is
for
any
request
that
comes
in
of
type
messenger.
It
always
gets
rate
limited
at
two
per
minute
for
anything
that
comes
in
with
type
whatsapp
by
default,
we'll
rate
them
in
at
1
per
minute,
but
if
it
is
2
the
number
for
1
1
4.
What's
that
will
give
it
a
much
larger
limit
of
30
requests
per
minute
and
we're.
A
B
A
weight
here
to
kind
of
inform,
glue
of
how
to
order
and
prioritize
these
rules,
basically
with
what
it's
saying
is
if
this,
if
this
rule
gets
hit
this
more
specific
one
for
the
number,
then
we
won't
increment
this
counter,
so
we
won't
trigger
our
sorry.
We
won't
be
rate
limited
on
this,
so
we'll
allow.
What's
that
message
is
of
two
four
on
one
go
through
even
after
we've
hit
our
our
kind
of
fallback
limit.
B
On
the
glue
config
side
so
for
our
route,
we're
going
to
basically
trigger
off
of
two
different
headers,
so
if
only
the
X
type
header
is
present,
will
increment
that
and
yeah
I'm.
Sorry,
let
me
say
that
it
slightly
differently
will
always
increment
one
counter,
just
with
the
X
type,
just
based
off
of
X
type
for
the
type
tuple.
B
Essentially
that
links
us
to
that
first
rule
and
basically
ensures
that
you
know
if
the
messenger
request
comes
in
after
two
of
them,
we'll
rate
limit,
because
of
that
first
rule
we'll
also
take
an
action
on
the
type
and
number
to
poll
so
that
we
can
get
to
that
nested
rule
as
well.
So,
let's
see
these
in
action.
B
Okay,
so
now
we're
going
to
be
well,
let's
see
this,
you
know,
let's
make
sure
things
are
working.
Ok,
everything
looks
good,
we're
not
getting
rate
limited
now,
let's
actually
start
to
trigger
and
actually
for
the
purpose
of
making
this
a
little
easier
to
read.
Since
the
text
is
so
big
I'm
just
going
to
leave
it
without
the
verbose
flag.
If
we
don't
get
a
response,
that
indicates
that
we
have
been
rate
limited
for
now.
Well,
we'll
bring
back
for
both
a
little
bit
later.
But
let's
see
these
specific.
B
B
B
B
B
The
first
flaw
here
is
that
if
we
don't
specify
a
type
that's
well
defined
in
our
in
our
settings,
then
we
won't
enforce
any
rate
limit
whatsoever.
So
you
know
I,
don't
think
even
be
able.
It
wasn't
really
intended
that
a
different
header
here
would
have
would
have
led
to
no
very
limiting
at
all.
We
just
forgot
to
introduce
a
fallback
rule
so
fixing
that
pretty
easy.
We
can
just
add
one
more
different
rate
limit
just
on
type,
but
with
no
specific
value
and
that
kind
of
creates
our
fallback
so
pache,
and
that.
B
And
as
we
can
see,
it
immediately
takes
effect
now
you
know
now
any
other
type,
unknown
type
is
rate
limited
just
as
we
expect
now.
There's
some
other
constraint.
There's
some
other
cases
like
this,
which
I'll
come
back
to
because
we
we
might
want
to
utilize
some
security
features
to
block
other
types
of
requests,
but
we'll
come
back
to
that
in
a
little
bit.
B
The
next
flaw
that
we
need
to
address
is
the
fact
that
right
now
we're
placing
the
onus
on
the
user
or
the
client
to
provide
honest
headers
on
which
we
can
actually
do
the
rate-limiting,
so,
for
instance,
if,
if
the
client,
you
know
specified
something
different
or
if
they
omitted
the
header,
we
wouldn't
trigger
our
rules
that
isn't
really
what
we
want.
What
we
really
want
is
something
where
we
we
know
that
some
authoritative
source
kind
of
gave
us
the
values
of
the
type
and
of
the
number.
B
So
what
we
can
actually
do
is
we
can
move
that
you
know
we
can.
We
can
basically
leave
rate
limiting,
as
is
but
what
we
want
is
we
want
incoming
requests
to
have
a
valid,
JWT
and
valid
jot,
which
is
a
token
that
indicates
that
we've
authorized
them
to
access
our
service.
So
we
want
that
job
verification,
and
then
we
want
to
extract
from
the
job
if
it's
valid
different
claims
and
put
them
into
these
two
headers.
B
B
The
first
thing,
I've
done
is
just
you
know,
created
for
the
purpose
of
testing
a
public
and
private
key
pair
and
in
terms
of
the
job
you
know
all
we
need
to
change
about
our
virtual
service
about
our
glue
config
is
we
want
to
add
that
JWT
configuration,
so
all
I've
done
is
I've.
You
know
we're
we're
doing
local
verifications,
I'm,
providing
the
public
key
and
the
issuer,
so
we
can
kind
of
have
envoys
validate
that
the
JWT
associated
with
the
requests
is
actually
valid.
B
It's
looking
for
that
token,
in
the
X
token
header
or
in
the
token
query,
pram
will
use
that
header
to
supply
it
and
there's
one
other
feature-
that's
utilized
here,
so
to
tie
it
to
our
rate
limit
config,
we'll
we'll
basically
extract
those
two
values
from
those
two
headers
cool.
So
let's
we
can
actually
just
go
and
apply
this.
We
don't
need
to
make
any
other
configuration
change
to
glue
because
we've
already
set
up
the
rate
limits
that
we
want
we're
just
provide
supplying
those
values
from
a
new
source.
So,
let's
update
our
route.
B
And
what
we
should
start
to
see
are
requests
coming
back.
If
we
look
closer,
we're
actually
getting
a
401
unauthorized
response
now,
which
is
exactly
what
we
expect,
because
we're
not
supplying
a
valid
JWT
and
that
is
what's
required.
Based
on
our
route.
Configuration
I've
gone
ahead
and
created
a
few
for
us
just
kind
of
emulating
the
scenarios
that
we
looked
at
just
when
we
supplied
the
headers
directly,
so
first
I've
got
a
JWT
and
I'll
verify.
B
B
Sorry,
by
adding
in
the
jot
configuration
to
extract
the
header,
we
are
able
to
kind
of
work
with
our
existing
rate
limit
can
and
just
to
you
know,
one
other
thing
that's
worth
proving
is
this:
you
know
helps
protect
against
something
like
this,
where
a
user
is
actually
just
supplying
a
fake
type
header
by
the
time,
this
request
actually
gets
all
the
way
to
our
service.
We
know
that
that
header
has
been
actually
written
by
our
JWT
filter.
So
it's
it
doesn't
matter
what
the
user
provides
as
long
as
they
provide
a
valid
shot.
B
Great
so
last
thing
I
want
to
show
and
then
we'll
kind
of
open
it
up
for
then
we'll
close
this
out
and
then
open
it
up
for
questions.
But
you
know
we
layered.
Basically,
one
set
of
security
features
on
top,
which
is
utilizing
JWT
verification
to
require
that
our
clients
have
valid
shots
and
to
extract
you
know
and
to
rely
on
our
identity
management
system
to
to
kind
of
indicate
what
we
should.
B
You
know
that
our
plan
and
then
actually
rate
limit
based
on
on
that
trusted
Authority,
but
there's
some
other
limitations
or
some
other
kind
of
weaknesses.
Still
you
know
this
is
much
more
secure
than
what
we
had
before,
but
there
are
some
other
limitations.
So
the
first
is,
you
know
we
might
want
to
add
in
some
kind
of
web
application
firewall
in
front
to
actually
block
malicious
looking
traffic.
B
For
instance,
we
might
want
to
inspect
the
payload
of
the
JWT
and,
if
there's
no
type
at
all
or
if
the
type
isn't
one
of
the
that
we've
written
a
rate
limit
quota
for,
maybe
we
want
to
reject
it
as
an
unauthorized
request
instead,
so
these
kinds
of
things
are
really
easy
to
kind
of
layer
on
top
just
to
kind
of
get
you.
You
know
security
from
every
different
angle.
So
let
me
just
apply
that
real,
quick
and
now
we
can
kind
of
start
to
see
some
interesting
things.
B
B
Okay,
so
now
we
can
see
if
you
know
now
that
this
hits
this
triggers
a
rule
that
we
had
put
in
front
for
a
while.
So
we
actually
can
get
an
intervention
even
before
rate
limiting.
We
can
also
layer
rate
limit
on
top
of
other
features
like
like
OPA
or
like
external
auth,
and
in
that
way
we
can.
We
can
do
things
like
block
requests
as
unauthorized,
if
they're
for
type
that
we
don't
that
we
don't
approve
so
going
back
to
our
SMS
example.
B
If
we
wanted
to,
we
could
have
a
valid
token
that
came
from
our
authoritative
source,
but
if
it
it
still
may
not
be
valid
for
this
route
based
on
our
off
config
and
in
dupes.
In
that
case,
we
can
kind
of
see
a
forbidden
in
the
way
that
we
expect.
So
this
is
just
to
show
you
know,
there's
there's
a
lot
of
different
angles
that
you
would
want
to
think
about.
B
In
addition
to
rate
limiting,
when
you
are
using
rate
limiting
as
a
way
to
secure
and
expose
your
API
GRU
makes
it
really
easy
to
start
to
layer
those
on
top
of
each
other.
So
you
know
we
looked
at
how
we
could
just
do
that
through
extracting
headers.
We
made
that
significantly
better
by
incorporating
the
jot
filter
and
extracting
it
from
jot
claims,
but
we
can
even
do
better
and
layer
additional
security
features
on
top.
B
Great,
so
just
to
kind
of
wrap
this
up-
and
this
is
this-
is
a
slide
that
highlights
really
the
range
of
features.
What
we
looked
at
today
was
an
enterprise
feature,
which
is
our
built-in
integration
with
envoy
for
rate
limit,
utilizing
our
rate
limit
server
that
we
provide
with
Enterprise
glue
now
open-source
glue
you
could
still
use
rate
limiting
and
auth
and
and
all
of
these
other
features
with
open-source
glue.
B
We
just
have
a
lot
kind
of
that
comes
out
of
the
box
with
our
implementation,
and
just
you
know
want
to
highlight:
we've
got
a
bunch
of
customers
using
glue,
there's
some
really
interesting
case
studies
on
our
website,
so
I
encourage
you
to
check
that
out
and
in
particular,
I
drew
some
of
several
of
the
examples
that
we
went
through
today,
we're
kind
of
from
working
with
customers
on
this
list.
So
you
know
I
really
wanted
to
highlight
some
representative
rate
limit
examples.
B
A
Thanks
Rick
I'm
in
folks,
so
here
are
some
links
here
for
you
to
get
more
information
on
glue
for
glue
open-source,
as
well
as
the
enterprise
trial.
First
question
here
we
actually
got
it
a
few
couple
different
times.
Rick
is
the
demos
you
show
today
is
the
code
and
the
instructions
for
that
available
anywhere,
yep.
B
It's
all
available,
I
need
to
I,
think
commit.
So
this
is
it's
in
a
repo
that
I've
been
kind
of
maintaining
called
glue
reference
architecture.
It's
got
a
bunch
of
different
scenarios.
Betty
do
you
have
a
list
of
like?
Is
there
a
way
that
we
can
follow
up
with
a
link
to
it?
I
need
to
basically
commit
and
push
out
these
resources.
Yes,.
A
B
I
would
I
would
recommend
for
folks
listening
and
who
want
to
try
that
I,
you
know,
is
in
prepping,
for
this
I
did
write
instructions
in
terms
of
how
you
can
go
through
it
all
the
resources
that
I
used,
including
the
kind
of
back-end
bunker
service,
are
all
here.
So
you
know
it
should
be
pretty
easy
to
run
through
yourself,
great.
A
B
Great
question
so
generally,
we've
designed
the
components
to
be
completely
separable
and
kind
of
independently
scalable,
so
the
the
application
of
rate
limit
settings
doesn't
really
depend
on
how
many
replicas
of
Envoy
you
have.
Instead,
it
depends
on
where
you've
bound
rate
limit
config
on
to
your
routes
and
like
where
those
are
long
on
which
envoys
and
on
which
listeners
do
those
rats
exists.
So
just
you
know
to
to
make
that
a
little
more
clear
in
our
virtual
service
here
you
know
we
had
a
single
virtual
service.
B
It
was
bound
to
our
standard
like
HTTP
port,
and
then
any
request
going
into
the
HTTP
ports
would
kind
of
trigger
those
limits.
If
we
had
multiple
replicas
of
that
listener,
both
of
those
would
be
kind
of
triggering
the
same
limit.
The
same
quota
they'd
be
on
goal,
be
talking
to
the
same
rate
limit
back
end,
so
we
can
scale
up
envoy.
We
can
kind
of
granularly
associate
different
rate
limits
on
different
routes
without
worrying
about
replicas
and
how
we're
scaling
on.
A
B
It
really
depends
on
you
know
how
you
want
to
design
your
and
exposure
api's.
So
all
of
the
things
that
I
showed
are
relatively
interchangeable.
Envoy
offers,
like
the
two
building
blocks,
that
envoy
offers
are
descriptors,
which
define
essentially
four
particular
tuple
of
values.
What
the
limit
is
and
then
actions
which
say
how
to
construct
those
tuples.
So
in
that
way
you
could
you
could
you
could
create
as
many
of
those
as
you
want,
you
could
create
them
with
different
shapes,
depending
on
how
you
want
to
construct
it.
B
The
way
that
I
kind
of
like
to
work
with
people
to
refine.
It
is
really
starting
with
that
use
case.
So
if
we
could
describe-
and
you
know
in
kind
of
just
like
English
how
we
would
want
to
enforce
like
what
policies
are
we
trying
to
enforce
and
then
we
can
use
those
underlying
building
blocks,
that
envoy
gives
us
to
construct
the
policy
that
makes
sense.
But
you
know
everything
that
we
looked
at
here
is
interchangeable,
relatively
easy
to
swap
in
and
out,
depending
on
the
use
case.
A
And
then
you
know
earlier
on
in
your
in
the
presentation
you
showed
kind
of
you
showed
the
the
different
kind
of
filters
that
you
can
have
in
envoy,
with
rate
limiting
being
one
of
them.
Any
any
comment
on
like:
what's
the
impact
of
performance
on
having
all
these,
you
know
filters
and
how
often
is
envoy
talking
to
glued
to
get
you
know
the
quotas
or
configurations
a
great.
B
Question
so
there's
a
couple
things
there
then
I
would
like
to
kind
of
pull
out
and
respond
to
so
the
first
is
in
what
way
does
envoy
and
glue
do
envoy
and
glue
talk
to
each
other
glue
is
basically
pushing
configuration
to
envoy
behind
the
scenes,
not
on
the
request
path
over
a
protocol
that
envoy
publishers
called
XDS.
So
envoy
is
always
serving
a
last
known,
good
configuration
and
relatively
quickly
when
glue
sees
an
update,
it'll
push
something
new,
but
that
doesn't
impact
actual
kind
of
request
performance.
B
What
does
impact
it
as
I
think
the
question
pointed
out
is
which
which
filters
you
have
in
your
filter
chain
and
that
depends
on
you
know
you
could
have
a
ton
of
different
routes
and
a
ton
of
different
filter
chains
or
in
our
example.
We
just
had
one
in
terms
of
the
performance.
It
really
does
vary
a
lot,
so
you
know
the
filter
chains
could
do
things
like,
like
rate
limit
or
off,
where
they
reach
out
to
a
service,
to
make
a
decision
and
to
receive
a
response.
B
They
could
do
things
like
woth
or
JWT
verification
where
they
do
these
like
very
rapid
in-memory
kind
of
in
envoy
checks,
or
they
could
do
other
things
that
might
be
a
little
more
intensive
in
terms
of
Io
like
transformations,
so
it
ultimately
does
depend
on
which
features
are
being
used.
You
know
a
transformation
on
the
body
of
large
requests
and
responses
is
obviously
going
to
be
slower
and
will
require
more
envoy
to
get
those
requests
through.
B
But
in
terms
of
you
know,
in
terms
of
performance
yeah
like
it
Altima
lead
appends
on
that
stuff
and
fortunately
a
rate
limit
can
be
configured
to
be
you
can
you
can
kind
of
granularly
decide
where
you
want
rate
limit
to
sit
in
that
chain,
so
by
default
it
happens
right
after
we've?
Had
customers
put
it
in
front
of
us
for
the
purpose
of
essentially
using
rate
limiting
as
a
way
to
protect
their
off
server?
A
B
Fantastic
question:
I,
you
know
in
one
for
just
came
out.
One
of
the
features
is
latency
metrics
that
gives
you
know.
We've
basically
built
it
in
conjunction
with
a
customer
to
get
pinpoint
accuracy
on
the
exact
timing
kind
of
in
and
out
of
envoy,
and
so
that
you
know
we
we
can
develop
basically
a
really
good
insight
into
the
performance
inside
of
you
know,
from
kind
of
entering
to
exiting
envoy
and
the
breakdown
of
like
where
that
time
is
being
spent.
So
there's
some
new
yeah
I
would
look
for
those
in
the
release.
A
B
B
A
B
B
B
A
Wraps
it
up
for
the
questions
Rick,
can
you
go
back
to
that
slide
that
flashes
the
links?
Yes
great,
so
thanks
everyone
for
joining
today
we
will
be
digging
into
more
fun
topics.
Specifically,
you
know,
you
know
detailed
use
cases
within
the
API
gateway
with
Rick,
so
watch
out
for
invites
for
that
we'll
try
to
do
them.
You
know,
try
to
come
up
with
fun
topics,
monthly
or
so,
and
if
there's
a
specific
area
that
you
are
interested
in,
please
go
ahead
and
hop
into
our
slack
community.
A
A
B
Just
to
add
to
that,
if
you're
interested
in
running
through
this-
and
you
know
you're
having
trouble
or
you
want
to
just
like
ask
me
a
question
I'm
on
the
slack
too,
so
don't
hesitate
to
just
drop
me
at
the
Animus.
If
there
is
something
you
want
to
follow
up
about
it
about
this
specific
webinar
content.