►
Description
The transition to microservices architecture changes how we build and operationalize these new applications, specifically how we secure then as the surface area grows from a single service to potentially hundreds of services accessible by end users.
This webinar shows how to apply a zero trust networking model to protect your microservices. We will cover how API Gateways can act as a control point in your architecture for security, authentication and traffic control configurations that safeguard your environment.
Learn more about Gloo https://www.solo.io/glooe
Start trial https://www.solo.io/gloo-trial
Question? Join the community https://slack.solo.io
A
And
I'm
excited
to
talk
to
you
today
about
securing
microservices
on
zero
trust
networks
using
API
gateways,
so
just
to
set
the
stage,
usually
we're
talking
to
customers
who
are
looking
or
somewhere
on
their
journey
towards
microservices.
Now,
as
people
moved
away
from
Omelas
towards
micro
sources,
it
brought
a
lot
of
advantages.
It
led
to
increased
productivity,
allowing
multiple
different
teams
to
move
in
parallel
on
different
parts
of
an
application.
It
led
to
and
enforce
good
software
design
principles
and
it
was
flexible
at
capsulated
knowledge
effectively
across
an
organization,
but
it
did
create
challenges.
A
So
the
first
challenge
is
obvious:
it
more
dependencies
there's
more
services
to
deploy
as
part
of
an
application.
Now,
applications
are
just
more
complex
and
as
a
request,
spans
multiple
hops,
there's
performance
considerations
around
latency
and
other
issues.
It's
more
costly,
more
difficult
to
manage
and
maintain
these
applications
and,
as
you
start
to
develop
many
services
that
have
different
interactions,
it
can
be
pretty
difficult
to
actually
test
end
to
end
that
everything
is
working
in
a
representative
way.
A
Another
way
of
looking
at
this,
so
in
a
ma
in
the
old
monolith
world,
you
kind
of
had
a
single
box
here
on
the
Left,
where
you
have
users
interacting
with
some
UI
or
some
client
tool.
Do
some
business
logic
hit
the
data
layer,
but
this
will
all
really
be
contained
inside
of
a
single
process
and
thinking
about
security,
which
was
fairly
easy.
Now,
in
a
world
with
micro
services,
you
still
might
have
a
single
entry
point.
A
You
might
have
many
entry
points
and
then,
on
the
back
end,
there's
potentially
hundreds
of
processes
and
end-users
may
need
to
access
any
number
of
those
services
at
any
point
in
time
they
might
need
to
talk
directly
to
them.
They
might
be
going
through
a
UI.
There
could
be
a
lot
of
different
hops
to
fulfill
a
request
across
an
application,
and
so
this
necessarily
changes
how
we
need
to
think
about
an
approach.
Application,
security.
A
The
concept
is
pretty
simple:
basically
by
default,
don't
trust
anything
inside
or
outside,
and
you
need
to
verify
that
every
request
is
coming
from
a
trusted
source
and
is
coming
with
the
correct
authorization
and
authentication
before
granting
access
to
the
underlying
resources
and
in
reality
there
might
be
things
you
want
to
do
on
the
response
end
as
well,
which
we
might
get
to
a
little
bit
later
now.
Why
is
it
useful
to
think
in
terms
of
your
trusts
from
a
risk
perspective,
as
you
start
to
develop,
Microsoft's
architecture
is
the
surface
area
for
that
risk.
A
The
potential
vectors
of
where
attack
vectors
increases
dramatically
and
users
also
might
need
to
access.
There
might
be
many
more
access
points
into
the
system
depending
on
the
different
layout
of
your
back-end
architecture.
And
traditionally
the
met
are
the
traditional
kind
of
approach
to
static
security.
Just
doesn't
really
work
effectively
in
micro-services
worlds,.
A
So
our
our
solution
for
the
API
gateway
is
glue.
It's
a
next
generation,
API
gateway,
an
ingress
controller
built
on
Envoy
proxy,
so
typically
there's
some
proxy.
Typically,
you
call
this
API
gateway.
That's
sitting
in
from
the
application.
Proxy
envoy
is
an
open
source.
Scalable
high-performance
proxy.
A
It
was
designed
that
lift
and
has
been
used,
seems
to
be
one
of
the
kind
of
yeah
the
most
commonly
used
proxy
for
both
API
gateway
and
service
met,
use
cases
super
lightweight,
it's
natively
integrated
with
the
cloud
and
there's
a
ton
of
use
cases
around
deploying
on
blowing
kubernetes
that
have
been
well
thought
through
and
there's
a
ton
of
features
related
to
security
and
traffic,
shaping
that
really
help.
You
fine-tune
the
behavior
and
enforce
kind
of
the
rules
that
you're
trying
to
enforce
when
it
comes
to
zero
trust.
A
Cool
so
as
I
was
preparing
this
we're
kind
of
listing
out
the
different
features
that
are
relevant
when
we're
talking
about
security
and
thinking
about
zero
trusts.
The
first
year
are
obvious:
there's
a
there's.
A
web
application.
Firewall
is
kind
of
the
typical
phrase
used
to
talk
about
protecting
your
system
against
requests
that
looks
suspicious
coming
in
and
as
well
as
potentially
blocking
responses,
depending
on
the
nature
of
the
responses.
A
B
A
I
was
preparing
demos
for
this
webinar.
It
became
pretty
clear
that
we
couldn't
really
cover
everything
here
in
in
just
one
session,
so
I'm
gonna
call
this
part
one
of
security
in
particular.
The
things
I
want
to
focus
on
today
are
the
Web
Application,
Firewall,
authentication
and
authorization,
and
then
integration
with
and
at
the
end,
we'll
talk
about
how
glue
integrates
with
service
meshes.
A
Cool,
so
the
first
thing
that
we're
going
to
focus
on
here
is
web
application,
firewall
or
waffe,
so
the
web
application
firewall.
The
idea
behind
it
is
preventing
harm
for
harmful
traffic
from
entering
your
environment.
Now
there.
This
is
an
area
of
active
research
and
there's
been
a
lot
of
work
done
in
this
area
for
many
years.
So
we
took
the
approach
of
let's
leverage.
A
All
of
that
great
work
done
with
the
open
source
community
particularly
were
looking
at
an
implementation
of
this,
the
library,
mod
security,
and
we
wanted
to
incorporate
mod
security,
the
core
rule
set
for
mod
security
into
envoy,
as
well
as
allow
it
to
be
highly
configurable
so
that
we
could
inspect
and
block
traffic
as
necessary,
based
on
the
rules
that
were
defined
and
applying
that
to
all
of
your
kind
of
outbound
in
them
down.
Traffic.
A
I
should
note
here
that
way
for
the
Web
Application
Firewall
is
not
something
that's
built
into
Envoy
and
in
fact
no
other
Envoy
back.
The
API
gateway
has
another
and
out-of-the-box
solution
for
this.
This
is
a
custom
filter
that
we
built
and
and
we've
extended.
So
if
you
took,
but
if
you
deploy
Enterprise
glue,
you'll
get
it
on
the
box
cool,
so
I'm
going
to
shift
gears
and
go
over
to
a
demo
and
I'm
going
to
use
this
cluster
for
all
the
demos
today,
just
to
set
the
stage
a
little
bit.
A
This
is
a
view
of
my
cluster
from
the
command
line
here
all
the
pods
running
in
the
cluster.
It's
running
in
google,
kubernetes
engine
or
gke
and,
as
you
can
see
here,
beside
the
system,
pods
I've
deployed
gluing
to
the
glue
system.
Namespace,
and
this
is
the
latest
Enterprise
glue
that
ships
with
glue
CTO,
as
well
as
I've
deployed
here
in
the
pet
clinic
application
for
demo
purposes,
and
if
I
go
back
to
my
browser,
I
port
forwarded
the
the
UI
for
glue
onto
the
just
local
is
one
two
three
four
just
to
show
you.
A
Here's
the
actual
cluster,
as
you
can
see,
I'm
managing
one
envoy
here
and
we
can
we'll
dig
into
what
that
envoy.
Configuration
is
in
a
little
bit
and
I've
got
some
upstream,
some
of
which
were
discovered
and
I've
also
added
an
AWS
upstream
for
the
pet
clinic
application,
and
then
in
particular,
I've
got
one
virtual
service
here,
I
just
called
a
default.
The
domain
is
star
and,
as
you
can
see,
it
just
has
a
single
route.
Excuse
me
to
the
pet
clinic
upstream,
on
port
8080
from
the
command
line.
A
So
the
first
thing
I
want
to
do
is
showcase
web
and
now
there's
a
couple
different
ways:
I
can
configure
laughs
so
basically
envoy
lets
you
generally
expose
lets.
You
generally
apply
configuration
on
three
levels:
one
is
kind
of
at
the
across
entire
proxy
or
across
the
entire
gateway.
I
should
say
one
is
on
the
virtual
service
or
virtual
hosts
in
the
Envoy
language
and
then
finally,
on
the
rabbit
and
I'm
going
to
show
all
three
of
those
here.
A
A
B
A
Okay
and
it
looks
like
my
gateways
been
configured
and
just
to
show
you
what
that
looks
like
I'm
gonna
go
into
the
admin,
API
UI
and
look
at
the
configuration.
We
now
show
the
rock
configuration
for
all
the
resources
that
allow
that
we
expose
here
just
to
make
it
easy
to
to
look
at
what
the
gamal
is.
A
A
So
this
is
the
Web
Filter,
picking
up
on
the
fact
that
it's
matched
a
rule
that
I
had,
which
said
I
deny
things
with
the
scammer
user
agent
and
if
I
actually
look
at
what
the
response
code
is
I
can
see
it
was
a
403
forbidden,
which
is
how
I've
configured
it
I'm
going
to
turn
this
off
now
and
in
the
UI.
We
now
allow
for
editing
of
the
animal
directly
here
just
for
a
convenience
thing
so
going
to
make
that
change.
Remove
that
section
that
I
added
apply
it
and
I
expect
that
this
should.
A
A
So
now
I've
added
a
virtual
host
plug-in
here,
which
configures
laughs
here
by
putting
the
configuration
here.
What
it
means
is
for
every
route
on
this
virtual
host
I
want
to
apply
this
configuration
and
so
in
in
glue
terminology.
That
would
mean
that
every
virtual
service
that
that
provides
configuration
for
this
domain
every
route
across
those
virtual
services
would
have
this
plug-in
configuration
and
it
would
the
introduction
of
a
new
feature
that
we
added
called
delegate
routes.
A
It
would
also
be
the
case
that,
if
you,
you
know
you
know,
all
of
the
routes
that
were
delegated
from
this
virtual
service
into
a
different
route
table
would
also
have
this
configuration
applied.
This
configuration
is
applied
now,
so
let
me
just
show,
as
you
can
see,
this
curl
request
has
been
blocked
again
with
the
mod
security
intervention
and
finally,
I
want
to
update
the
configuration
and
apply
it
just
to
the
route.
A
Cool
so,
and
if
we
look
at
that
so
now,
my
configuration
has
changed
here.
It
used
to
be
on
a
virtual
hosts,
plug-in
section,
and
now
it's
on
a
route
plugins,
just
to
kind
of
showcase.
This
behavior
modified
the
virtual
service
to
have
two
routes.
Now
one
is
the
more
specific
/
owner
prefix,
which
we've
configured
now
to
reject
anything
with
the
user
agents
camera
and
as
well
as
a
default
route
matching
on
prefix
on
this
just
slash
as
a
prefix.
A
I
was
having
some
trouble
with
my
I
browser
cache,
but
I.
Think
I
should
be
able
to
show
this
here.
So
if
I've
turned
on
a
header
called
scammer,
if
I
refresh
here,
it
looks
like
the
application
and
it's
fine
as
we'd
expect.
If
I
go
to
the
best
page,
it's
fine.
If
I
go
to
the
owners
page
now,
we
can
see
modsecurity
interventionist,
happens,
cool,
so
I'm
going
to
do
one
more
thing.
Basically,
I
want
to
show
just
a
different
rule
set
mod
security.
A
A
And
let's
look
at
what
that
configuration
is
so
now
I've
been
using.
The
coral
set
I
got
rid
of
the
other
rat,
so
this
is,
you
know
everywhere.
Basically,
there's
only
one
rat
that
matches
every
prefix
or
every
every
actual
path
and
now
for
the
map.
Basically,
this
rule
set
is
a
little
more
verbose
and
it's
defining
things
like
access
logging,
it's
defining
default
behavior
around
blocking
with
a
403.
A
And
finally,
this
bottom
section
says
allow
things
that
come
in
with
HTTP
two,
and
so,
if
I
do
a
one
more
curl,
so
mod
security
intervention
occurred,
but
it
would
occur
anyway.
Even
if
I
didn't
pass
that
scammer
header,
because
by
default
I'm
sending
these
request
HTTP
1.1.
Now
let
me
just
provide
a
flag
to
curl.
It
should
be
to
prior
knowledge
and,
as
you
can
see,
the
curl
actually
returns
correctly.
Now,
so
that's
it
for
the
RAF
demo,
as
I
mentioned,
the
this
is
highly
configurable.
A
I
just
wanted
to
showcase
a
few
different
ways
in
which
we
can
demonstrate
the
behavior,
as
well
as
a
few
different
places
in
which
you
can
inject
that
configuration,
but
for
to
find
out
more
there's
a
ton
of
information
over
here
on
at
modsecurity
org
and,
if
you're
interested
at
all,
in
protecting
yourself
against
traffic
coming
in
via
a
web
application.
Firewall,
I'd,
highly
recommend,
checking
out
mod
security
and
then
looking
at
glue
as
having
extended
envoy
to
support
the
mod
security
library.
A
A
A
All
right,
so
that's
the
first
kind
of
major
area
that
you're
gonna
working
you're
thinking
about
in
terms
of
protecting
incoming
edge,
protecting
against
malicious
incoming
traffic.
Now
we
want
to
authenticate
that
traffic,
and
then
we
potentially
may
want
to
do
additional
things
like
apply.
Some
authorization
just
apply
some
authorization
ensuring
that
the
user
that
was
authenticated
actually
has
access
to
the
particular
resources
or
the
particular
endpoints
that
they're
trying
to
access
now.
Well,
we
recognize
that
our
enterprise
customers
have
a
ton
of
different
approaches
to
author-it
authentication
and
authorization.
A
There's
a
bunch
of
different
identity
providers
out
there
and
a
bunch
of
different
implementations.
Glue.
Out-Of-The-Box
natively
supports
a
few
things
so
for
one
it
supports
authentication
with
with
OAuth
and
for
anyone
that
that
is
kind
of
implementing
the
Open
ID
Connect
protocol.
We
use
Google
OAuth
internally
to
protect
some
of
our
internal
services,
ensuring
that
essentially,
people
that
are
accessing
them
are
part
of
our
Google
account,
but
some
of
our
customers
have
other
identity
providers
such
as
Cognito,
some
use,
LDAP
and
glue
and
glue
out-of-the-box
supports
a
lot
of
these
integrations.
A
And
that's
what
has
all
these
built-in
implementations
X
das,
an
alternative
to
using
X
das?
Is
you
could
write
your
own
custom
server,
which
is
something
that
some
of
our
customers
have
done
and
it's
just
a
larger
maintenance
burden,
but
it
might
make
sense,
depending
on
the
level
of
the
technical
level,
as
well
as
the
willingness
to
take
on
more
romanians
burden
from
our
customers.
A
B
A
We've
had
customers
that
have
wanted
to
do
and
basically
implement
custom
authorization
approaches,
so
we've
worked
with
them
to
help
develop
their
own
custom
plugins.
So
these
are
all
options.
I
should
note
that
our
API
allows
for
chaining
of
these,
so
it
may
be.
It
may
make
sense
first
to
have
an
authentication
step
which
could
even
modify
the
request,
adding
a
header
to
indicate
what
user
or
other
competitors
that
other
information
that
helps
with
other
checks
and
then
later
in
the
chain
also
perform
some
kind
of
authorization.
And
that's
a
that's,
a
workflow.
B
A
A
A
A
There
are
two
different
users
that
have
accounts
and
have
accessed
the
application,
admin
and
user
and
there's
a
secret
value
that
inclu
needs
to
know
about,
and
then
there's
a
password
associated
with
each
of
these
accounts
and
for
you
know,
as
part
of
this
example,
it's
just
password
so
Dex
is
installed.
Now
we
need
to
actually
go
first,
create
this
secret
okay.
So
now
we've
we've
kind
of
encoded,
the
secret
into
we've,
encoded,
a
secret
that
matches
what
Dex
is
expecting
into
our
glue
configuration
and
now
we're
going
to
apply
another.
A
A
So
I
had
a
browser,
caching
issue,
but
now
I've
opened
in
an
incognito.
So
now
I
have
my
login
screen.
This
is
what
Dex
is
providing
and
as
I
mentioned
before,
as
long
as
I
provide
an
account
that
was
in
that
statically
static
configuration
that
I
passed
the
decks
at
install
time,
I
should
be
able
to
log
in
so
my
one
of
the
accounts
was
admin
at
example.com
way.
The
password
and
now
I
can
access
the
pet
clinic
application.
A
Just
to
review
we've
added
this
Olaf
configuration
to
the
virtual
service,
and
now
we've
performed
this
authentication
check
as
part
of
accessing
the
underlying
resource.
In
this
case,
it's
the
pet
clinic
application,
any
path
for
that
application,
and
in
this
case
it's
any
domain
which
we've
just
port
forward
it
to
localhost
8080.
A
But
now
I
want
to
do
something.
Different
I
actually
want
to
restrict
access
of
certain
portions
of
this
application
to
a
user.
So,
in
addition
to
just
perform
this
login
function,
I
want
to
demonstrate
that
depending
on
which
user
logged
in
I
can
modify
the
underlying
access-
and
let's
just
for
the
purpose
of
demonstrating
this,
let's
say
that
this
final
owners,
section
of
the
application,
will
be
restricted
only
to
Edmunds
and
whereas
everything
else
can
be
accessed
by
both
admins
and
and
the
main
user.
A
So
here
we're
using
another
built-in
feature
of
glues,
external
lot,
server,
which
is
otha
authorization,
OPA
authorization
and
essentially
we're
enforcing
that
work.
Essentially,
what
we're
doing
is
we're
going
to
read
rules
out
of
a
module
called
allowed
jot
and
that's
in
a
config
map
and
based
on
those
rules,
will
decide
in
this
step,
if
the,
if
the
user
that
got
authenticated
in
the
first
step
actually
has
access
to
the
resource
that's
being
requested
and
to
see
what
those
rules
are.
Let's
look
at
allowed.
A
Jawed,
they
use
a
language
called
Rhaego,
and
it
essentially
is
this
is
the
definition
of
it
where
the
default
rule
here
is
access
is
denied,
but
there
is
an
allow
rule
for
admin
to
be
able
to
access
everything
and
then
an
allow
rule
for
user
to
be
able
to
access.
Everything
accepts
everything
that
does
not
start
with
slash
owners,
and
so
this
is
the
way
in
which
we're
going
to
add
an
authorization
for
admins
to
access
owners,
but
for
users
to
be
denied.
A
A
A
A
Can
see
that
the
particular
owners
section
of
this
application,
this
user
is
not
authorized
to
access
that
great.
So
that
is
the
second
part
of
my
demo
here
showcasing
essentially
that
with
glue
there's
a
lot
of
configuration
options
for
doing
authentication
and
authorization.
I've
shown
you
a
few
of
them
here
today.
First
I
showed
an
authentication
step
that
uses
Dex
as
a
net
identity
provider
and
as
a
login
mechanism,
and
it
does
ooofff
against.
A
In
this
case
my
static
configuration
and
through
that
mechanism,
I
was
able
to
authenticate
both
the
user
and
the
admin
that
I
logged
in
as
and
then
I
was
able
to
add
a
subsequent
step,
which
was
to
do
additional
authorization
of
the
specific
resource
being
accessed
whereby
if
it
was
admin
trying
to
access
it,
they
would
be
allowed.
But
if
it
was
just
if
it
was
user,
it
would
be
disallowed.
A
Now,
outside
of
just
a
gateway
use
case,
there's
a
lot
more
that
you
can
do
with
glue
and
with
other
integrations
and
in
particular
what
we've
talked
about
today
so
far
is
essentially
north-south
traffic
as
it's,
essentially
all
the
requests
coming
in
to
your
application
go
through
a
central
gateway
and
then
the
Gateway
farms
out
those
requests
to
the
underlying
service
or
resource
that
they
should
that
they
should
go
to.
But
now
once
an
app
once
requests
to
stand.
Imagine
then
to
for
a
service
to
satisfy
that
request.
A
It
needs
to
reach
out
to
other
services
and
typically,
as
we've
started,
to
see
over
the
last
few
years,
people
have
started
to
think
about
this
traffic,
which
we
called
east-west
traffic
as
another
place,
in
which
we
need
to
be
thinking
about
security
and
finding
some
mechanism
to
ensure
security
and
a
zero
trust
network,
and
usually
the
implementation
of
this
is
deploying
a
service
mesh.
So
one
example
of
a
service
mesh
is
Sto
which
has
its
own
control
plane.
A
But
in
fact
it's
talking
to
the
sidecar
and
then
the
size
of
the
traffic
from
one
service
to
another
is
all
happening
from
sidecar
to
sidecar,
and
by
doing
it
that
way
we
can
reconfigure
the
proxy
or
set
up
certain
features
on
the
proxy
to
ensure
that
the
traffic
is
encrypted.
We
can
ensure
that
the
traffic
is
shaped
in
different
ways.
We
can
do
things
like
logging
observability
very
easily
without
having
to
go
redeploy
your
application
or
update
the
code
at
all.
A
But
what,
if
you
want
to
do
both?
So
what?
If
you
want
to
do
both?
It's
like
you,
set
up
a
gateway
that
does
authorization
and
authentication
and
handles
your
north-south
traffic
into
your
application,
but
you're
in
a
zero
trust
network.
You
want
to
ensure
that
you've
got
mutual
TLS
and
cross
every
all
of
your
east-west
traffic
across
your
application,
and
you
want
your
gateway.
A
You
know,
ultimately,
what
this
boils
down
to
is
you
need
your
gateway
and
your
service
match
to
have
compatible
certificates
I'm
going
to
demonstrate
how
we
can
easily
configure
glue
to
talk
to
an
application.
That's
been
that's
running
with
this
Geo
and
the
glue
proxy
can
talk
directly
to
the
sidecars
or
directly
to
the
services
that
are
deployed.
With
this
deal.
A
So
sto
install
in
those
two
steps.
The
first
is
deploying
all
of
the
all
the
CR
DS
and
other
static
and
things
that
don't
change
across
upgrades
and
then
and
we
can
ensure
that
all
those
looks
like
not
all
this
year
to
user
there.
Yet
now
they
are
it's
two
as
23
CR
teams
that
it
ships
with
and
then
we
can
deploy
demo
of
basically
we're
going
to
deploy
manifest
called
sto
demo
off.
A
This
is
a
good
time
to
mention.
I've
essentially
created
a
few
different
workflows
to
try
out
these
different
security
features,
we'll
be
publishing
both
a
video
of
these
demos,
as
well
as
documentation
for
how
to
run
through
these
yourself,
which
can
be
a
very
useful
way
to
actually
get
a
better
mental
model
for
how
these
features
work.
A
A
A
So
it
created
a
bunch
of
pot.
It
created
a
bunch
of
deployments.
The
the
book
info
application
is
essentially
a
first
a
product
page
and
then
the
product
page
to
populate
data
on
the
product
page.
It
accesses
a
few
underlying
services
for
details
about
the
products,
ratings
and
reviews
about
the
products
and
there's
it
also
ships
with
a
few
different
versions
of
the
review
service.
If
you're
kind
of
trying
to
play
around
with
a
traffic
shifting
type
of
scenario
for
our
purposes
here
today,
we're
just
looking
at
security
by
deploying
the
autumn
live
deployed.
A
Basically
the
deployed
sto
and
set
up
the
injector
so
that
traffic
is
enforcing
the
proxies,
are
enforcing
mutual
TLS
across
the
application,
and
we
can
do
a
check
on
that
using
the
built
in
SEO
tool.
Okay,
so
now
it
looks
like
all
of
them
on
all
the
pods
that
I've
added,
as
you
can
see
there,
there
are
two
containers
and
each
of
the
ones
I
just
deployed,
which
indicates
that's
not
just
both
the
under
the
book
info
container,
as
well
as
the
sidecar
proxy
are
deployed
in
them.
A
So
now
I
wanted
to
show
a
few
things
to
indicate
to
just
approve
that
we've
actually
got
TLS
setup.
So
this
is
there
is
this:
is
the
output
of
s
Tio's,
built-in
sto,
CTL
tool
that
tells
you
essentially
performs
a
check
to
indicate?
Are
you
talking
with
M
TLS
between
the
pod
that
you've
provided
and
everything
else
in
the
system?
And
it
looks
like
the
answer
is
yes
here,
but
we
can
prove
it
so,
let's
first
access
the
application
directly
and
I'm
just
expecting
this
curl
to
return
response.
A
A
And
we're
getting
termination
errors
now
on
the
response
here
and
if
we
pass
the
past
k
option
we're
still
going
to
get
some
termination
errors
here.
Essentially
we
don't
have
the
right
certs
to
actually
fulfill
this
requests
and,
finally,
if
I
do
kind
of
make
the
request,
while
also
providing
the
certs
I,
can
get
a
200
great.
So
this
proves
that
insight
once
you're
inside
of
the
network
accessing
the
application
traffic
is
flowing
with
MPLS,
but
now
I
want
to
actually
add
a
route
through
my
gateway
proxy.
A
A
And
it
looks
like
I'm
not
able
to
curl
that's
expected,
because
I
haven't
really
done
anything
related
to
setting
up
certificates
with
Bluto.
So
that's
the
final
step
here.
I
want
to
essentially
ensure
that
glue
is
writing
to
an
upstream
that
it
knows
to
use
SSL
with,
as
well
as
updating
the
proxy
to
have
the
correct
certificates.
So
let's
look
at
what
those
look
like
first.
A
So
what
I
currently
have
here
is
just
the
destination
which
is
a
queue
service,
but
there's
nothing
about
the
SSL
configuration
and
as
I
showed
before
word
I'm
going
to
add.
Now
is
the
actual
SSL
config
telling
glue
that
this?
When
talking
to
this
upstream,
there
is
a
there's,
there
are
certificates.
Let
me
first
apply
this.
A
A
A
A
A
Great,
so
this
is
the
this.
Is
the
book
info
application,
but
now
we've
done
it.
We've
accessed
this
in
a
way
where
we're
hitting
kind
of
a
proxy,
our
API
gateway
at
the
front
door,
so
the
north-south
traffic,
the
traffic
from
me
into
the
application,
is
being
guarded
by
that
proxy
and
then
that
proxy
is
using
SSL
with
compatible
certificates
with
sto
to
ensure
that
all
the
communications
within
the
application,
because
this
is
the
zero
trust
network-
is
actually
encrypted.
Ssl.
A
All
right
so
I'm
gonna
go
back
to
presentations,
that's
it
for
the
demos.
I
just
wanted
to
showcase.
You
know
just
to
kind
of
summarize
one
more
time
now,
when
you're
thinking
about
New,
York
trust
networks,
you
can
want
to
follow
the
request
path
and
ensure
that
every
step
along
the
way
thought
about
all
the
risk,
vectors
and
ensured
that
we're
properly
guarded,
and
so
that
starts
with
is
the
traffic
coming
in
encrypted
with
SSL,
with
a
known
certificate.
A
A
variety
of
functions
should
perform
laughs
to
ensure
that
the
traffic
isn't
suspicious
both
in
the
request
and
the
response
path
should
be
able
to
then
go
apply
an
authorization
and
authentication
set
of
filters
or
a
filter
that
can
perform
one
or
more
sets
of
steps
around
authentication
and
authorization
of
the
requests
and
then
finally,
as
you're
continuing
to
propagate
traffic
throughout
the
system
throughout
the
application,
you
may
be
leveraging
a
service
mesh
to
do.
Mpls
and
glue
can
seamlessly
integrate
with
that
service
mesh,
avoiding
the
need
for
any
extra
hops
the
gloop
rocks.
A
A
There's
no
extra
filters
that
you
need
an
envoy
to
enable
that
which
means
that
if
you
wanted
to
use
open-source
glue
as
your
gateway
in
front
of
an
sto
servers
mesh
application,
you
can
do
that
today,
but
then
Enterprise
glue,
packs
and
a
bunch
of
extra
features
to
really
help
with
security
and
some
of
the
ins.
Your
present
work.
A
There
are
a
lot
of
other
topics,
I
didn't
get
to
just
for
the
purpose
of
time,
in
particular,
once
you've
gotten
past
this
stuff,
there's
a
number
of
other
things
you
might
want
to
do,
such
as
observe
and
monitor
measure
the
actual
cost
of
traffic.
So
how
much
time
does
how
much
latency
is
incurred
by
actually
running
through
the
authorization
steps?
A
There
are
then
potential
ways
that
you
want
to
work
with,
how
you're
deploying
these
things
to
optimize
that
performance.
So
we
enable
running
external
loss,
for
instance,
as
a
side
card
next
to
on
point
directly
to
avoid
the
hop
that
you
would
normally
take,
as
the
request
is
going
from
envoy
out
to
the
authentication
service
that
and
a
number
of
other
topics,
I
mean
I,
look
forward
to
talking
through
in
more
detail
at
a
future
webinar,
but
for
now
I
think
that
wraps
this
up
and
we
can
shift
into
questions
all.
B
Right
so
folks,
please
type
your
questions
into
the
Q&A
window
or
the
chat
also
if
there
was
something
that
that
Rick
just
mentioned,
but
did
not
demo
today
and
you'd
like
to
see
more
you'd
like
to
see
that
in
topic
in
more
detail,
go
ahead
and
actually
put
that
in
the
chat
as
well.
So
we
can
kind
of
capture
that
and
use
that
for
a
subsequent
topic.
B
A
B
I'm.
Seeing
a
couple
of
questions
here,
Rick,
you
know
you
talked
about
they're,
asking
I'm,
just
laughs.
You
mentioned
quickly
that
wife
handling
traffic
both
ways.
The
way
in
you
know
for
wife,
kind
of
to
inspect
and
block
the
traffic
coming
into
the
cluster
totally
makes
sense.
What's
the
what
does
it
do
to
the
returning
traffic
yeah.
A
I
can
I
can
share
what
left
does
and
then
what
it
doesn't
do
so
well
well,
essentially
does
is
provide
a
yes/no
answer
based
on
a
set
of
pre-configured
or
custom
rules,
whether
the
traffic
should
be
allowed
through,
and
otherwise,
as
you
saw
in
my
examples
it
would.
The
mod
security
library
would
intervene
and
block
that
traffic,
and
so
those
rules
can
be
applied
both
to
the
request
and
the
response
itself.
A
In
the
case
where
a
response
is
blocked
by
the
set
of
rules-
and
it
just
replaces
the
body
of
the
response
indicating
that
the
request
was
blocked.
So
that's
what
lab
does
do
in
terms
of
what
it
doesn't
do.
We've
had
customers
explore
and
ask
about
things
related
to
data
loss
prevention,
so,
let's
say
I
don't
want
to
just
reject
requests,
but
I
do
want
to
potentially
mask
data
as
it's
leaving
the
proxy
to
ensure
that
sensitive
information
perta
personally
identifying
information
doesn't
leak
out.
A
Laughs
doesn't
do
that
other
box,
though,
as
I
mentioned,
we
are
working
with
customers
interested
in
that
and
I.
Think
we'll
have
more
to
say
about
it,
those
kinds
of
use
cases
at
a
later
date,
but
yeah
regarding
laughs.
The
short
answer
is:
it
performs
the
same
function
as
it
does
on
the
on
the
requests
on
the
response,
and
that
is
all
configurable.
B
Cool
I've
got
another
question
here:
it's
can
glue,
replace
the
sidecar
Envoy
proxy
of
an
sto
service
match
and
I
think
this
is
a
really
good
question
because
we
do
with
all
these
proxies
everywhere.
As
we
look
at
you
know,
from
a
PITA
gateways,
microservices
and
mesh.
This
is
a
pretty
common
question.
Rick.
Do
you
want
to
comment
answer
that,
with
kind
of
an
explanation
on
the
architecture
yeah.
A
A
That
being
said,
there
may
be
things
what
we
have.
We
have
explored
with
customers
essentially
or
sto.
It
deploys
envoy
as
well
as
glue
and
on
sto,
both
deployed
envoy,
and
they
both
deploy
envoy
with
a
slightly
different
set
of
filters,
and
we've
explored
resolving
those
into
a
single
envoy
image
so
that
we
can
leverage
the
configuration
across
both
the
API
gateway
and
across
the
sidecar
proxies.
A
The
we've
also
tried
to
ensure
that
we
would
just
work
seamlessly
with
the
proxy
with
the
sidecars,
as
I
mentioned,
as
I
demonstrated
in
this
demo
today.
So
that's
ultimately
glue
could
replace
in
the
sto
kind
of
terminology,
the
ingress
gateway,
but
yeah
I
wouldn't
say
like
we're
completely
trying
to
replace
the
side
cards
altogether
or
become
the
control
plane
for
those
sto
side
cards.
I
think
that's
the
bread
and
butter
of
SCO
and
we're
not
really
trying
to
be
the
mesh
at
this
point.
A
But
what
we
do
we
have
found
it
to
be
very
useful
for
how
to
have
glue
the
front
door
performing
like
your
general
kind
of
authentication,
authorization
and
and
then
leverage
the
other
features
of
sto
proper.
So
that's,
hopefully
that
answers
the
question.
It's
in
short,
like
we're
not
completely
trying
to
replace
sto
I,
think
you
know
we're
trying
to
really
make
it
work
seamlessly
and
in
cases
where
he
needs
to
leverage
kind
of
filters,
and
both
we
definitely
have
explored
tabs
forward
to
to
make
that
a
reality
and.
B
It's
actually
a
good
shout
out
for
what
Rick
talked
talked
about
today
was
functionality
within
the
API
gateway,
but
the
other
aspect
of
what
solo
does
is
works
with
service
mesh
and
actually
using
the
kind
of
the
Envoy
proxy
sidecar
architecture
to
provide
additional,
do
more
interesting
things
and
provide
functionality
into
the
mesh.
So
if
you're
interested
in
some
of
that,
you
can
hit
me
up
on
on
the
slack
and
I
can
send
you
links
to
some
of
those
Rick.
We've
got
a
question
here.
B
A
What's
the
latency
of
those
hops
and
like
generally,
how
to
optimize
the
performance
around
this
kind
of
stuff,
so
the
the
way
envoy
is
built
it
does
do
it
does
reach
out
to
an
external
authentication
service
to
perform
that
that
X
dot
check,
so
it
should
be.
It
will
be
one
hop
to
that
other
service
inside
of
that
check
implementation.
It
can
perform
all
of
your
both
of
both
your
I
think.
You
know
it
can
perform
all
the
different
steps.
A
A
B
Oh
looks
like
that's
it,
for
the
questions
and
I
want
to
thank
everyone
for
a
state
sticking
around
past
the
hour,
thanks
Rick
for
the
for
the
session
today
and
folks
remember
hop
into
the
salaat
community
in
case.
There's
a
question
that
you're
thinking
about
that
you
haven't,
you
haven't
asked
yet
or
if
there's
a
specific
topic
that
you'd
want
to
dig
in
more
related
to
security,
we'll
get
this
recording
at
Charlie
and
we'll
see
you
soon
at
the
next
one.
Thanks.