►
From YouTube: 006 Using an Edge Gateway & Istio Together
Description
Istio uses Envoy proxy for both north/south and east/west traffic but the edge requires more complementary pieces to properly secure. In this talk, we explore why you need to treat the edge differently with things like Ext-Auth, Rate Limiting and OPA, and how Gloo Edge comes pre-packaged to integrate with Istio.
A
B
A
A
A
A
So
we
hear
a
lot
this
saying
that
api
gateways
are
basically
for
north
south
traffic
and
we're
defining
the
north.
South
traffic
is
basically
everything
going
inside
your
cluster
from
a
client.
So
if
you
think
about
it,
if
you
have
a
mobile
phone
and
you
have
like
an
application,
they're
calling
your
cloud
service
or
anything
like
that-
that's
that
type
of
traffic
is
your
north,
south
traffic
coming
from
outside
to
inside
your
network.
A
Now
the
api
gateways
are
mainly
meant
to
secure
traffic
and
basically
expose
apis.
Do
some
routing
collect
some
metrics,
so
we
use
them
in
front
of
incoming
traffic
in
this
case,
at
the
edge
where
it
takes
traffic
in
enforce
some
policies,
do
some
routing
collect
some
metrics
and
then
route
to
your
either
vms
or
services
in
the
cloud
or
things
like
that
now,
in
terms
of
edge
capabilities,
the
gateways
offer
like
a
request
routing.
So
obviously
you
can
route
to
different
type
of
you
can
or
your
services.
A
You
can
have
like
security
enforcement
like
having
security
policies,
you
can
have
some
tracing
getting
collecting
metrics,
obviously
etls
termination,
you
know,
can
really
canary
release
and,
for
example,
rate
limiting
to
the
secure
gateway.
Your
your
traffic
now
the
service
mesh
in
this
case
right
so
there's
a
big
confusion
and
we're
trying
to,
as
we
explain
right
now,
why?
What's
an
edge
gateway,
we're
going
to
talk
about
what's
a
service
mesh
and
you'll
see
that
there's
a
lot
of
similarities
in
there
so
in
service
mesh.
A
Basically,
nowadays,
the
micro
servers
architecture
is
really
famous
like
it's
to
actually
add
a
lot
of
value
to
your
architecture
in
sense,
where,
back
in
the
days
we
used
to
have
like
a
monolith
of
a
big
piece
of
software,
that
has
all
your
logic
all
together
and
it
was
really
a
pain
to,
for
example,
update
it.
Let's
say
you
want
to
scale
just
a
part
of
your
system
or
update
just
a
part
of
your
system.
A
A
lot
of
companies
start
adopting
this
microservice
architecture.
Where,
instead
of
having
a
big
monolith,
you
have
different
components.
You
have
different
services
and
they're
all
responsible
of
a
logic
in
your
in
your
application.
So
in
a
sense,
if
you
want
to
just
like
scale
only
a
part
of
your
system,
you
don't
have
to
scale
everything.
You
scale
only
one
service
and
if
you
want
to
change
a
part
of
your
system
upgrade
or
something
like
that,
you're
going
to
change
only
a
part
of
your
system
too.
A
Now
this
this
microserver
microservice
architecture
is
really
powerful
in
the
sense
where
you
know.
As
I
said,
it
solves
a
lot
of
problems
that
we
used
to
have
with
the
monolith,
but
also
you
introduced
couple
other
problems
in
the
sense,
for
example,
how
how
to
to
trace
the
requests
if
there
is
any
any
problem
right.
If
you
have
a
problem
within
your
service
service
communication,
how
to
trace?
A
Where
is
the
issue
or
because
you
have
multiple
services,
you
have
a
bigger
surface
surface,
an
attack
surface
where
you
can
have
security
issues
in
couple
components,
and
there
is
a
lot
of
there's
a
lot
of
things
that
actually
are
complicated
to
implement.
With
with
this
microsoft
architecture,
where
you
will
have,
for
example,
to
either
have
different.
Libraries
like
crosscutting
concerns
libraries
that
deal
with
this
metric
collection
that
deal
with
this
retry
like
network
failures
that
deals
with
service
to
service
routing,
and
things
like
that.
A
Basically,
you
know
talking
service
to
service
from
sidecar
to
sidecar,
so
leveraging
a
lot
of
you
know
all
this
similar
pattern
like
tracing
and
security,
and
things
like
that.
So
the
service,
for
example.
Here
in
this
case
there
is
one
calling
service
b,
doesn't
have
to
deal
with
all
like
network
retries,
and
things
like
that.
It's
already
handled
by
the
sidecar
now
in
terms
of
service
mesh
capabilities,
we'll
see
that
we,
the
service
mesh,
allow
like
request
routing
between
services.
A
Enforcing
some
sort
of
security
features
like
jot,
for
example,
you'll
have
like
service
discovery,
you'll
have
also
tls
termination
and
origination.
You'll
have
also
can
releasing
and
all
that
stuff.
So,
if
you
see
this
list
is
really
similar
to
what
we
saw
on
the
api
gateway
side,
it
kind
of
offers
the
same
capabilities
in
this
term
now
like.
If
you
see
like
a
topology,
where
you
see
that
all
together
in
your
your
cluster,
you
will
have
probably
like
an
edge
gateway,
an
api
gateway.
A
You
know
allowing
incoming
requests
from
outside
your
network
to
inside
your
network,
going
to
different
different
or
to
your
service
mesh,
and
we
see
that
here
that
the
topology,
assuming
that,
basically
the
north
south
traffic,
is
managed
by
your
edge
catastrophe,
api
gateway
and
the
east-west
traffic
is
managed
by
your
service
mesh.
Now
this
is
not
really
the
reality
of
the
work
because
a
lot
of
companies
they
have
different
clusters
and
and
they
they
have
like
service
to
service
communication
cross
clusters.
A
Now
in
terms
of
differences
at
the
edge,
you
have
different
concerns
there
compared
to
a
service
mesh
at
the
edge.
You
will
need,
for
example,
to
authenticate
your
your
request
using
like,
for
example,
ydc.
You
want
to
have
be
able
to
call
your
id
pc.
You
know
authenticate
your
call
going
to
your
your
network.
Now
you
want
to
have
you
want
to
apply
some
web
rules
to
secure
incoming
traffic
from
from
outside
from
untrusted
sources?
A
You
want
to
have
some
sort
of
message
transformation
because,
obviously
some
a
lot
of
companies.
They
have
like
legacy
systems
and-
and
you
want
to
have,
for
example,
if
you
have
legacy
client,
you
want
to
have
a
way
to
transform
the
data
before
reaching
your
your
services
and
and
and
different
things
like
that.
A
Also,
you
know
like
having
like
an
api
decoupling,
because
the
api
that
you
expose
at
the
edge
are
different
from
the
apis
that
are
used
within
within
your
cluster
and
also
securing
the
the
edge
you
want
to
secure
it
against
the
os
tax,
having
like
rate
limiting
and
things
like
that,
it's
not
really
a
concern.
Sometimes,
when
you
have
like
a
service
mesh
like
within
your
cluster,
I
mean
so,
we
can
see
that
basically,
the
operate
service
mesh
and
the
api
get
api
get
way
to
operate
at
different
levels.
A
A
Dealing
with
your
you
know,
api,
exposing
and
request
transformation,
and
things
like
that
at
the
application
level,
and
also
the
service
mesh
and
the
edge
gateway,
usually
are
operated
by
different
teams.
So
in
in
term
of
like,
for
example,
the
aggregate
we
will
have
an
api
team,
designing
the
apis
and
actually
exposing
them,
and
you
have
also
the
service
mesh
team,
or
it's
mainly
like
the
platform
team-
that
enforce
policies
globally
across
all
the
organization.
A
A
Let's
take
an
example
of
a
service
mesh
and
the
most
famous
one
is
is
istio,
so
istio
has
has
a
has
an
egress
gateway,
so
we're
going
to
compare
it
to
basically
what's
like
with
the
blue
edge
in
term
of
edge
capabilities,
and
then
we're
going
to
see
how
to
use
them
together
in
in
this
presentation.
So,
first,
what's
the
easter
egg
grass
gateway
the
eastern
ingress
gateway
is
based
on
envoy,
it's
designed
to
basically
take
incoming
traffic
from
outside
the
cluster
directly
to
your
to
your
mesh.
It
has
limited
edge
capabilities.
A
You
don't
have
like
transformation,
you
don't
have
like
out
of
the
block
authentication
and
you
only
have
like
all
the
features
we
saw
at
the
edge.
Now,
let's
see
how
to
compare
with
the
glue
edge
in
glue
edge,
it's
basically
designed
for
edge
traffic,
where
you
will
have
advanced
traffic
management.
You'll
have
also
delegation
in
sense,
like
you
have
different
teams
managing
your
apis.
You
want
to
delegate
only
a
part
of
of
the
api
to
to
per
team,
for
example
per
api
team,
and
then
you'll
have
also
federation
right.
A
So
you
want
to
federate
multiple.
If,
let's
say
you
have
different
gateways
on
different
clusters,
some
serve
like,
for
example,
incoming
traffic
to
the
mesh.
Some
serve
like
traffic
to
to
some
virtual
machines
or
lambdas,
or
something
like
that.
You
can
have
like
a
federated
federated
model
where
you
can
have
applied
configuration
and
have
failover
across
multiple
components.
A
Also,
something
really
important
to
stress
there
glue
edge
offers
out
of
the
box
authentication.
Let's
say
you
have
ydc
it's
it's
out
of
the
box
where
you
can
just
implement
your
auth
policy
and
that's
gonna.
You
know
enforce
traffic
at
the
edge
to
be
authenticated
to
go
inside
your
service
mesh
and
also
support
request
transformation.
A
Let's
say
if
you
have
like
a
legacy
client
that
you
want
to
transform
the
data
before
reaching
your
your
in
your
internal
services,
you
can
apply
this
transformation
at
the
edge.
So
let's
compare
them.
Let's
have
a
look
basically,
first,
a
reminder
like:
what's
the
concerns
that
we
have
at
the
edge
compared
to
a
service
management,
we
discuss
that
we
need
ydc.
A
A
So,
if
you
compare
now
issuing
grass
gateway
with
glue
edge,
you
will
see
that
issuing
grass
gatway
is
not
designed
for
that.
It's
designed
basically
to
take
incoming
traffic
from
outside
to
install
your
mesh
in
comparison
with
bluetooth,
design,
actually
for
edge
traffic.
You
will
see
that
edge
blue
edge
support
out
of
the
box
authentication
api
keys,
ydc
things
like
that
waf,
it
supports
message,
message:
transformation.
A
It
support,
like
rate
limiting
it
supports
federation,
we're
talking
about
it
and
we
suppose
also
apa
portal
in
this
powerful
feature.
If
you
want
to
have,
you
know,
have
a
way
to
expose
apis
and
have
like
a
self
service
where
you
know,
developers
can
just
go,
get
an
api
key
and
be
able
to
use
your
your
your
apis
so
and
we
have
glue
edge
that
integrates
seamlessly
with
easter
ingress,
istio
service
mesh.
A
So
we
we
showed
case
that
how
how
the
edge
traffic
is
different
from
a
service
mesh
and
what
the
concerns
are
and
how
you
can
implement
this
edge
concern
using
glue
edge.
Now,
in
this
section
here
we're
going
to
talk
about
how
to
use
blue
edge
with
actually
service
mesh.
For
that
I
will
let
lawrence
take
here
and
and
show
us
how
to
do
that.
B
All
right,
thank
you,
adam,
so
so
yeah
we'll.
Let's
take
a
look
now
at
how
you
know
in
practice
what
it
looks
like
to
actually
use
an
edge
or
api
gateway
with
a
service
mesh.
So
in
reality
you
know
more
than
likely
you're
you're
going
down
this
journey
of
microservices
you're.
Going
down
this
journey
of
kubernetes
you
you're
going
to
have
some
sort
of
of
legacy
environment.
You
know-
and
maybe
you
have
some
sort
of
hybrid
setup,
but
you
know
an
example.
B
Deployment
may
look
something
like
this,
where
you
have
some
workloads
running
on
vms
kind
of
here
in
this
diagram
we
have
them
running
in
the
cloud,
but
you
know
that
could
just
as
easily
be
an
on-premises
deployment
et
cetera,
maybe
you're
not
fully
to
kubernetes
right.
So
you
still
have
these
vms.
You
also
have
some
workloads
running
in
kubernetes.
B
You
know
without
a
service
mesh
and
then
you're
also
starting
to
start
your
istio
journey.
So
you
have
a
cluster
that
has
istio
installed
and
you
have
a
handful
of
micro
services
running.
You
know
with
with
side
cars
right,
and
so
you
have
a
small
istio
deployment
and
so
you're
in
this
kind
of
state.
Where
you
have
you
know,
you're
not
completely
starting
greenfield
you're,
not
completely
from
scratch.
You
don't
have
the
luxury
of
everything.
B
You're
doing
is
brand
new
and
that's
that's
the
case
for
pretty
much
everyone
that
we
talk
to
here
at
solo.
Just
because
that's
kind
of
the
reality
of
you
know
software
development
right-
and
I
t
like
you
can't
you
know
you
there's
you
can't
just
start
from
scratch,
and
so
so,
with
this
kind
of
environment,
you
know
as
you're,
going
down
your
api
modernization
journey.
You
know
that's
where
an
api
gateway
comes
into
play
and
for
all
the
reasons
that
adam
just
outlined,
there's
a
difference
between
service
mesh.
B
You
know
whether
whether
or
not
you
need
a
service
mesh
depends
on
your
organization,
but
if
you
are
intending
to
expose
apis,
you
more
than
likely
are
going
to
want
an
api
gateway,
and
so
you
know
from
a
from
your
consumer
or
your
clients
perspective
right.
You
want
to
expose
a
set
of
apis,
and
so
in
this
example
right,
you
have
a
user's
api
and
a
cart,
a
shopping,
cart,
api
and
a
payments
api,
and
these
are
available.
B
You
know
at
an
api
domain
right
and
and
the
apis
that
you
expose
to
your
consumers
into
your
clients
that
that
is
that's,
irrespective
of
how
they're
actually
running
inside
of
your
deployment.
You
know
you
that
your
your
consumers
and
clients
don't
care
whether
or
not
a
service
is
running
on
a
vm
on
kubernetes
or
in
a
service
mesh
right.
B
You
just
need
to
expose
they
just
care
about
using
the
api,
and
you
just
care
about
exposing
the
api,
and
you
need
tooling,
like
an
api
gateway
to
kind
of
handle
that
that
that
bridge
that
gap
right
or
to
act,
in
other
words
as
a
gateway
right,
and
so
you
know
in
this
example,
you
have
your
these
three
apis
exposed
and
you
have
your
services
running
in.
You
know
kind
of
this
hybrid
deployment,
and
so
you
have
a
user's
your
user's
apis
being
accessed,
and
that
is
actually
what's
running
on
your
vms.
B
You
have
your
cart.
Your
shopping
cart
service,
that's
running
on
kubernetes,
just
raw
kubernetes,
and
then
your
payment
service
is
a
you
know,
the
most
recent
thing
that
you've
been
doing
and
you're
running
this
as
as
workloads
and
microservices
and
istio
service
mesh.
So
how
do
you
actually
do
this
right?
How
do
what
can
you
actually
use
to
actually
expose
these
gateways?
Handle
the
api
gateway
concerns,
the
edge
concerns
and,
and
also
you
want
something
that
that
can
handle
this
kind
of
hybrid
deployment
right,
and
so
that's
where
we
see
glue
edge
as
right?
B
We've
been
working
with
many
folks
that
are
on
this
journey,
this
exact
journey
and
there
are
various
stages
of
it.
They
know
they
need
an
api
gateway.
They
know
they
want
to
get
to
service
mesh
or
they're
starting
to
get
to
service
mesh,
but
you
still
need
an
api
gateway,
regardless
of
where
you're
at
in
the
service
mesh
journey
and
so
kind
of
the
the
recommendation
and
kind
of
the
pattern
that
we've
seen
to
that's
worked.
B
A
great
success
so
far
is
that
you
take
it
as
an
iterative
journey
where
you
slowly
adopt
service
mesh
and
the
key
to
that
is
by
using
a
gateway,
that's
compatible
with
it,
but
still
provides
the
api
gateway
functionality
and
so
blue
edge.
Is
you
know
our
api
gateway
based
on
envoy
and,
and
you
get
the
benefits
of
introducing
envoy
to
your
infrastructure
without
having
to
go
all
in
to
the
service
mesh
up
front
right.
B
Because
now
your
operation,
your
operation
teams
or
your
sre
teams,
they
don't
have
to
know
multiple
proxies
right,
you're
kind
of
you're
going
down
the
journey
with
envoy
as
your
data
plane
as
the
api
gateway
and
as
a
service
mesh
and
so
glue
edge.
Can
act
as
that
api
gateway?
That's
kind
of
you
know
future
thinking,
but
also
can
provide
you,
the
api
gateway,
tooling,
that
you
need
so
when
you
actually
use
glue
edge
as
your
gateway
right.
It's
it's
a
kubernetes
native
tool
so
and
it's
also
it
also
integrates
tightly
with
istio.
B
So
you
can
have
a
deployment
where
it
looks
something
like
this,
where
you
have
glue
edge,
running
inside
of
your
mesh,
essentially
or
in
the
cluster.
That's
running
your
istio
service
mesh
right,
and
this
is
what
will
front
your
vms
and
your
kubernetes
workloads
and
then,
of
course,
integrate
directly
with
your
istio
services.
So
it's
a
very
powerful
model.
Where
you
can,
you
know
adopt
slowly.
B
You
can
start
pulling
things
out
of
the
vms
services
out
of
the
vm
services,
out
of
just
your
regular
kubernetes
cluster
and
start
integrating
them
into
your
service
mesh
sharing.
But
you
still
have
that
kind
of
that
that
that
safety
layer
of
you
still
have
your
api
gateway
and
that's
still
what's
exposing
apis
to
your
consumers.
Again,
they
don't
care
that
you're
using
a
service
mesh
right.
B
So
what
we'll
do
is
we'll
kind
of
take
a
look
at
these
this
this
concept
right
and
we're
we'll
we'll
look
at
a
demo
here
shortly
and
what
the
demo
is
going
to
do
is
we
are
going
to
have
two
applications
in
this
case:
they're
actually
web
web
applications.
You
know
ui
based
applications
because
it's
easier
to
kind
of
visualize
what's
going
on,
but
we'll
have
a
pet
clinic
application,
which
is
just
a
monolith.
That's
a
spring
based
application
running
in
a
cloud
somewhere
right,
it's
just
running
as
a
vm.
B
B
What
we'll
do
is
we'll
be
using
openid
connect
to
add
authentic,
an
authentication
layer
at
the
edge
through
glue
edge
and
we'll
use
that
open
id
connect,
authentication
for
both
the
pet
clinic
and
the
book
info
application.
And
again,
since
book
info
is
running
on
istio,
that's
not
important
to
blue
edge
right.
Even
though
blue
edge
can
integrate
with
steel,
it
still
is
acting
as
the
gateway.
So
we're
going
to
be
performing
our
open
id
connect,
authentication
with
glue,
and
it
just
so
happens
that
glue
can
integrate
with
istio.
B
So
in
this
example
here
on
the
slides,
I'm
calling
out
mycorp.nip.io
you'll
see
in
a
second
what
that
what
that
looks
like
what
it
actually
looks
like
if
you're
not
familiar
with
nip.io,
it's
a
way
of
kind
of
getting
host
names
or
dns
names
for
just
basic
ip
addresses,
and
so
this
is
how
I'm
kind
of
getting
domain
type
functionality.
For
my
ip
of
some
google
load,
balancer,
basically
so
pet
clinic,
is
going
to
be
running
into
the
petclinic
dot.
B
My
core
domain,
essentially
book
info,
will
be
running
as
the
book
info
domain
and
again
since
we're
integrating
with
istio
the
the
request.
As
it
flows
from
glue
to
istio,
that
will
actually
be
an
issue:
mutual
tls,
you
know
kind
of
leaning
back
to
the
integration
where
we're
not
even
going
through
the
issue,
ingress
gateway.
You
know
there
and
the
differences
are
everything
that
adam
just
talked
about
right,
so
we're
performing
our
edge
functionality
with
glue
with
blue
edge
and
we're
still
participating
in
the
istio
mutual
tls.
B
So
the
whole
flow
from
the
gateway
down
is
istio
mutual
tls,
but
we
get
all
of
the
advanced
functionality
of
using
the
api
gateway
and
then,
lastly,
with
our
odc,
what
we'll
demonstrate
is
that,
since
we
have
you
know
a
component,
that's
acting
as
our
edge
gateway,
the
glue
edge
component
or
edge
gateway
is
providing
authentication
for
the
entire
domain.
So
another.
B
B
So
in
this
case
I'm
running
the
same
kubernetes
cluster
as
book
info
pet
clinic
is
running
somewhere
else,
and
I
have
two
virtual
services
applied
to
my
kubernetes
cluster,
one
for
pet
clinic
and
one
for
book
info
and
again,
a
virtual
services.
That's
just
kind
of
how
you
configure
what
is
exposed
at
the
blue
edge
gateway.
So
in
this
case
I
have
a
domain
exposed,
that's
pet
clinic,
and
then
this
is
my
nip.
B
I
o
address,
in
other
words,
just
the
generic
domain
that
will
resolve
to
this
ip,
which
is
the
ip
of
my
load
balancer,
and
I
have
the
same
thing
for
my
book
info
application,
and
so
essentially,
what
I'm
doing
here
is.
I
have
a
subdomain
called
bookinfo
and
a
subdomain
pet
clinic
they're,
both
being
served
by
the
same
gateway
and
when
I
access
them,
the
same
blue
edge,
endpoint,
more
or
less
is
going
to
handle
these
requests
and
then
kind
of
quickly.
Look
at
the
rest
of
the
config
very
straightforward.
B
I
have
a
single
route
and
based
off
of
a
prefix
path,
matcher
of
slash
or
the
root
path
which
matches
everything
I'm
going
to
route
to
what's
called
an
upstream,
which
is
glued
terminology
for
really
your
destination,
and
so,
in
this
case,
I'm
running
to
an
upstream
called
pet
clinic
which
corresponds
to
the
pet
clinic
application
running
the
vm
somewhere
and
then
on
the
book
info
side.
I'm
routing
to
my
product,
page
upstream,
which
is
really
the
product
page.
You
know
page
of
the
book
info
application.
B
B
They
have
different
subdomains,
but
the
top
level
domain
in
this
case
is
the
nipio
address
right,
which
kind
of
can
correspond
to
your.
You
know.
Whatever
your
web
domain
is
essentially
so
so
now,
let's
go
ahead
and
integrate
with
our
odc
providers.
So
in
my
example
I'm
using
key
cloak,
you
know
you
can
use
any
oic
compliant
oidc
server,
but
yeah,
so
I'm
using
key
cloak
and
so
to
do
so.
I'm
going
to
make
modifications
to
my
two
virtual
services,
which
you
know
I'm
gonna
apply
these
manually.
B
This
could
be
easily
just
be
just
as
easily
be
applied
through
some
sort
of
cicd
pipeline.
The
only
difference
between
these
two
virtual
servers
and
the
one
that
we
were
just
looking
at
is
the
is
the
presence
of
this
options
field
which
specifies
ultimately
specifying
that
hey.
I
need
to
do
odc,
and
here
is
the
odc
configuration.
So
I
have
one
for
pet
clinic
and
I
have
one
for
book
info,
and
so
what
I'll
do
now
is
I'm
going
to
apply
them.
B
B
I
can
access
my
book
info
product
page
with
authentication,
so
I
put
oidc
authentication
in
front
of
an
istio
based
application,
because
the
edge
gateway
is
what's
performing
that
right.
It's
not.
You
know
what
happens
upstream
from
to
use
envoy
terminology.
What
happens
upstream
from
our
gateway
is
is
not
important
to
it.
You
know
we
can
integrate
with
with
istio.
B
We
can't
integrate
with
functions
like
lambdas
and
so
on,
but
you
know
the
the
functionality
that's
provided
by
the
edge
gateway
is
still
the
same,
regardless
of
where
it's
routing
to
so
I
have
authentication
in
place.
You
know
for
my
book
info
and
so
kind
of
to
round
out
the
example
right.
I,
since
I
have
the
edge
gateway,
that's
hosting
essentially
this
web
domain
of
my
ip.nipio.
B
What
I
can
do
is
I
set
up
the
cookies
so
that
now
this
authentication
is
relevant
for
this
entire
web
domain.
So
if
I
were
to
go
back
to
say
the
pet
clinic
application,
because
my
browser
is
authentic-
is
logged
in
more
or
less
I
don't
I
won't.
I
will
not
have
to
re-authenticate,
because
I
have
the
authentication
set
up
to
where
you
know
now.
It
knows
that
okay,
I'm
logged
in
for
this
domain,
that's
being
hosted
essentially
by
my
edge
gateway,
and
so
I
can
go
back
and
forth.
B
My
authentication
is
is
valid
right
for
for
both
of
these
because
they're
running
on
the
same
web
domain,
and
so
you
can
obviously
you
can
architect
this.
However,
you
want,
but
it
just
kind
of
shows.
You
know
the
value
of
having
an
edge
gateway
that
can
do
things
like
odc
authentication,
but
also
can
do
things
like
integrate
directly
with
istio.