►
From YouTube: Secure Gateway & GraphQL Server- Choose Two, Deploy One
Description
SoloCon 2022:
Secure Gateway & GraphQL Server- Choose Two, Deploy One
Speakers:
Kevin Dorosh
Tech Lead, Solo.io
Adam Sayah
Field Engineer, Solo.io
Session Abstract:
Numerous production environments already leverage Envoy as an edge or mesh proxy, and expose services behind Envoy via a separate GraphQL server. To avoid an extra network hop and enable route-level customizations to your Graph, we've written a GraphQL server into Envoy. This uniquely enables users to combine full edge and mesh capabilities at the GraphQL resolver level, such as rate limiting, authn/z, and DLP. We will explore the Envoy filter chain and how existing filters interact with GraphQL using a live demo to illustrate these ideas.
Track:
Gloo Edge and API Gateway
A
Hi
everybody
thank
you
for
joining
this
session
today,
we're
going
to
be
talking
about
envoy,
proxy
and
graphql,
how
you
can
deploy
only
once
and
have
an
api,
a
graphql
api,
secure
and
monitored.
So
your
speakers
today,
my
name
is
adam
saya,
I'm
a
field
engineer
here
at
solo.
I
help
customers
adopt
service,
mesh
and
api
gateways
and
with
me
today,
kevin.
A
Awesome
yeah.
Thank
you
kevin.
If
you
guys
have
any
questions
during
the
session
or
after,
please,
you
know,
send
us
a
message
here
or
on
slack,
we're
always
happy
to
help
all
right.
So
today
we're
going
to
be
talking
first
about
just
a
quick
reminder
regarding
envoy
how
it
is
used
and
we're
gonna
talk
a
little
bit
about
graphql
how
how
to
secure
actually
a
graphql
endpoint
with
envoy
and
then
we're
gonna
go
about
like
how.
A
Why
should
we
actually
embed
a
graphql
server
within
envoy?
What's
the
benefits
that
we
have
there
we're
gonna,
deep
dive
into
a
couple
of
examples,
and
then
we're
gonna
end
up
with
a
demo
so
first
and
voip
proxy,
if
you
guys,
are
familiar
with
it?
If
not
envoy
is
a
super
powerful,
a
proxy
api
proxy
that
is
actually
used
mostly
everywhere?
Now
you
can
see
it
from
you
know
like
an
edge
deployment,
securing
your
ingress
traffic
to
your
clusters
or
to
infrastructure,
or
it
can
also
be
used
in
service
mesh
between
services.
A
It's
a
small,
robust
and
easily.
You
know
manageable
proxy.
It
is.
It
is
one
of
the
main
building
blocks
for
all
the
cloud
native
technologies.
It
support.
It
is
http
2.
First,
it
supports
your
rpc,
it
supports
you,
know
low
level
protocols
and
it
is
actually
driven
with
an
api.
So
you
know
you
can
configure
everything
through
a
control
plane
and
we're
gonna.
Take
an
example
of
blue
edge.
Later
blue
is
basically
a
control
plane
for
for
envoy
and
one
important
feature
there
is
that
you
can
customize
it.
A
So
you
can
add
your
custom
filters
to
enhance
either
security
or
the
processing
of
the
requests,
and
this
is
something
leveraged
here,
a
lot
of
solo.
We
add
our
custom
filters
to
envoy
to
either
add
features
like
data
loss
prevention,
like
request
transformation,
and
so
on
that
we
can
we're
gonna
talk
about
later
in
in
this
presentation,
so
the
way
envoy
can
be
used-
and
this
is
just
an
example
of
how
to
use
envoy
as
an
ingress
to
your
community
service.
A
Again,
as
I
mentioned
envoy
can
be
used
in
the
service
mesh
scenario.
We're
gonna
deep
dive
into
mainly
just
the
edge
scenario
today
to
see
some
contrast,
so
envoy
can
be
in
front
of
your
cluster
right
and
it
can
act
as
an
ingress
gateway
directing
traffic
to
your
cluster.
To
your
rest,
endpoint
and
you
know
it
can
direct
based
on
you
know
it
can
route
traffic
based
on
headers
have
high
decision
on
the
l7
level.
It
can
also,
you
know,
be
customized
to
enhance
security
there.
A
So
you
can
add
your
let's
say,
api
key
feature
or
oidc
or
so
on
right.
So
the
way
it
works
in
invoice
through
the
envoy
filter
chain.
Okay,
so
when
a
request
and
like
hits
envoy,
then
you
have
multiple
filters
getting
activated
to
either
enhance
the
request
or
apply
some
sort
of
authentication
authorization
on
it
before
actually
delegating
this
request
to
the
backend
okay.
A
So
in
this
example
here
we're
looking
at
you
know
a
set
of
filters
and
enabling
external
off,
for
example,
and
then
doing
rate
limiting
and
then
transforming
a
grpc
call
to
a
rest
call.
But
you
can
add
your
custom
filters.
Okay,
so
here
at
solo
we
have
multiple
custom
filters.
We
added
to
envoy
some
of
them.
Let's
just
take
an
example:
here
we
have
the
web
filter.
A
We
have
you
know
wifi
web
application
firewall.
We
have
a
data
loss
prevention,
going
to
see
me
referring
to
dlp
data.
It's
for
data
loss
prevention
that
allows
you
to
mask
sensitive
data.
You
know
going
through
your
request
right.
So
if,
let's
say
your
endpoint
serves
like
social
security
numbers,
you
want
to
mask
this.
This
sensitive
data.
A
We
have
an
aws
lambda
filter
that
allows
you
allow
envoy
to
act
as
a
fast
gateway,
so
it
can
call
out
directly
to
your
lambda
function,
get
the
data
there
and
you
know
you
can
up.
You
can
apply
the
authentication
authorization
everything
to
to
this.
You
know
to
this
call
also
requests
and
response
transformation,
and-
and
many
more
so.
This
is
just
a
quick
introduction
to
how
envoy
works
and
what
filters
we
have
here
at
solo.
A
So
what
is
graphql
mainly
it's
a
great
language
for
your
apis
right,
so
you
will
deploy
you.
You
describe
your
data
as
a
graph,
and
you
allow
a
client
talking
to
this
endpoint
to
fetch
data
from
multiple
data
sources,
assuming
you
have
10
different
microservices,
instead
of
doing
a
rest
call.
If,
instead
of
making
your
client
talk
into
10
different
rest,
endpoints
you'll
have
one
end
point
that
will
collect
data
from
this
different
data
sources.
Okay,
that
optimize
a
lot
of
things.
A
A
Let's
say
a
data
loss
prevention
filter
to
match
some
sensitive
data
before
reaching
the
client,
and
you
see
how
many
network
hopes
we
have
there
right,
and
so
this
is
kind
of
a
standard
way
of
deploying
or
enhancing
security
for
your
graphql
server.
Today
now
we
can
see
that
there
is
a
lot
to
optimize
there.
Okay,
so
some
of
the
things
we
can
optimize
is
the
network
performance.
A
Now,
if
I
have
two
different
deployments,
if
I
have
a
network,
that
means
that
I'm
adding
another
variable,
which
is
the
network
to
my
request
right,
so
you
can
definitely
enhance
your
performance,
your
request
performance,
reducing
the
number
of
the
network
hops.
You
have
right
again.
Another
problem
you
can
have
is
mainly
just
managing
two
different
deployments.
A
So
imagine
if
you
have
both
in
the
same
component,
that
will
just
have
to
be
familiar
to
one
technology
and
apply
the
same
principles
to
all
the
requests
right,
because,
ultimately,
a
graphql
api,
it's
still
just
an
api.
Okay,
another
thing
is
obviously
enhancing.
You
know
how
to
learn
these
new
technologies.
You
can,
if,
if
I
have
multiple
components
to
get
up
to
speed
on
one
component
is
way
faster
than
than
two.
Obviously,
if
you
hire
people
to
manage
your
security,
another
thing
is
the
in-depth
field
control.
A
Now,
if
you
have
the
graphql
server
within
android
right,
you
can't
have
control
over
the
data
within
the
graphql
server
like,
for
example,
if
you
want
to
apply
certain
authentication
authorization,
resolvers
and
or
get
in-depth
like
per
field.
Definitely
you
can
reuse
all
the
concepts
you
have
in
your
your
gateway,
all
the
way
down
to
your
graphql
server
and
and
feel
that
you're
exposing
there.
A
Another
really
important
concept.
Is
you
know
if
you
have
if
you
have
gtops
already
today
and
you
have
pipelines
to
allow
you
to
deploy
configuration
and
secure
your
endpoint?
If
you
have
your,
if
you
can
describe
first,
your
graph
plus
your
security,
that
you
have
on
top
of
your
graph
graphql
api
through
a
github
approach,
that's
really
valuable.
That
will
allow
you
to
roll
out
new
configuration
easily
to
roll
out
easily
and
many
more
other
operations.
A
Another
concept
is
also
reusing.
The
same
metrics
collection
and
logging
that
you
have
today
for
your
api
consumption
to
your
graphql
server.
You
can
apply
alerting
on
certain.
You
know.
Let's
say
endpoints
are
not
available.
You
can
collect
the
same
metrics
that
you
have
already
and
alerts
based
on
them,
and
also
it's
going
to
be
easily.
You
know,
because
you
can
also
integrate
easily
with
let's
say,
datadog
and
any
other
technologies.
A
B
Fantastic
thanks
adam
for
the
getting
us
started
here
with
the
introduction
yeah.
So
the
very
first
thing
I'd
like
to
do
is
just
run
through
some
example.
You
know
scenarios
that
you
see
as
realistic
opportunities
just
places
an
organization
might
be
in.
You
know
how
graphql
and
numberway
can
help
here,
and
you
know
just
provide
real
clarity
on
some
of
the
value
that
it
provides.
So,
for
example,
the
scenario
here
is,
you
know
regular
organization.
Where
already
have
the
google
edge
api
gateway?
B
You
know
built
on
top
of
one
by
proxy.
You
know,
we've
primarily
exposed
it's
written
our
services
with
the
rest
style
and
we've
decided
to
be
like
graphql.
We
like
graph,
you
know
what
it
offers
we
like
to
solve.
The
under
fetching
problem.
We
like
to
increase
performance
by
doing
most
of
the
requests
on
the
server
side.
You
know
make
it
easier
for
developers,
you
know
tab
space
their
way
through
and
discover
their
their
schemas,
and
we
want
to
do
this
in
incremental
way.
B
We
want
to
add
some
services
incrementally
we
don't
have
a
graphql
server
yet.
Additionally,
we
want
to
have
the
same
organization-wide
data,
loss,
prevention
or
dlp
rules
to
scrub
all
access
logs
of
pii
or
personally,
identifying
information.
So
the
example
we
have
at
the
bottom
there
you
can
see
our
json
response
has
like
a
fake
visa
card
and
that's
social
security.
B
We
can
scrub.
Most
of
that,
you
know
scenario
here
is
we
want
to
comply
with
legal?
We
want,
you
know
all
of
our
access
logs
to
be
scrubbed
with
this
data.
You
know
legally
required
to
do
this.
So
most
you
know
companies.
Today
they
have
to
secure
both
their
api
gateway
and
the
graphql
server.
If
you
had
a
separate
server
deployed,
you
need
to
re-implement
this
logic
to
be
compliant.
You
know
your
access
logs
for
both
will
be
separate.
B
They
both
need
to
scrub
the
data,
but
if
I
can
by
merging
or
writing
a
graphql
server
into
envoy,
you
know
you
know
one
set
of
access
logs.
You
only
need
to
implement
this
once
the
same.
Dlp
rules
don't
need
a
single
source
of
truth
to
be
generated
for
both,
so
it's
more
manageable
further.
We
can
also
do
things
special
for
graphql
that
make
it
more
performant.
B
So,
for
example,
we
can
take
these
dlp
rules
and
we
can
apply
them
on
a
per
field
or
per
resolver
level,
whereas
it
would
be
more
difficult
to
do
when
they
were
separate,
and
this
can
lead
to
improved
performance.
So,
for
example,
a
lot
of
the
dlp
rules,
they
parse
the
return
response
or
and
take
a
regex
and
apply
that
regex
and
replace
certain
aspects
of
the
response
based
on
the
regex
match
that
regex
might
be
difficult
or
expensive
to
parse.
B
But
if
we
can
do
it
on
a
per
resolver
level,
then
we're
parsing
less
and
we're
going
to
get
more
performance.
You
know
ignoring
the
the
network,
how
we're
already
saving
we're
going
to
again
improve
performance.
This
is
something
we
only
get
when
we
embed
the
server
in
envoy
so
from
here.
I'd
love
to
move
to
another
example,
so
let's
say
again
we're
in
an
organization,
but
now
we're
talking
about
service
mesh
instead
of
an
api
gateway.
So
let's
say
we're
service
mesh.
B
We
have
istio,
or
perhaps
several
istio
installations
managed
by
glue
mesh
we've
configured
jot
authorization
via
the
request,
authentication
and
authorization
policy,
istio
resources.
Examples
of
those
resources
are
at
the
bottom
here
and
let's
say
that
we
want
to
use
these
jot
authorizations
to
control
access
to
certain
policies.
B
You
know
in
our
graphql
environment
as
well,
so
you
can
see
here
on
request
authorization.
We
have
defined
our
jot
rules,
specific
issuer
and
a
way
to
access
the
key
server,
and
then
we
have
ujot
rules
for
how
to
allow
the
request
on
the
authorization
policy,
with
certain
principles
that
we
need
and
together
this
constitutes
access
or
things
that
we
need
from
that
jot
to
access
a
destination
in
istio,
and
we
want
to
go
ahead
and
reuse.
This
same
policy
to
define
access
to
certain
vacuole
primitives,
such
as
making
graphical
mutations.
B
So
the
example
we've
constructed
here
is:
let's
say
we
have
this
jot
and
this
jot.
It
has
a
claim
that
means
that
you're,
like
a
member
of
the
admin
organization
or
the
admin
team,
and
so
you
can
only
access
certain
backends
if
you're
an
admin
which
makes
sense.
But
perhaps
you
also
only
want
certain
mutations
in
your
graphql
super
scheme
and
the
total
graph
to
be
you
know,
mutated
by
by
admins
as
well,
and
so,
rather
than
defining
two
sources
of
truth,
we
could
use
the
same.
B
You
know
istio
definition
of
a
jot
and
then
reference
that
and
we
should
be
able
to
gate
our
graphical
mutations
by
that
same
exact,
claim
defined
once
further.
We
could
just
use
it
to
strengthen
our
defense
and
depth
case,
so
we
could
just
layer
certain
fields
at
a
field
level
or
the
response
itself
by
the
jot
as
well.
B
So
there's
value
there
as
well
pivoting
from
these
two
very
specific
examples:
let's
talk
a
little
bit
further
about
what
other
things
can
we
do
so.
Obviously,
these
aren't
the
only
things
that
we
get
by
a
declarative
approach,
embedding
graphql
and
envoy.
There's
you
know
so
so
much
more
and
just
to
kind
of
give
you
a
flavor
of
some
of
the
things
I'm
talking
about
here
or
is
you
know,
an
existing
api
gateway
or
service
mesh
built-in
envoy?
We
already
have
a
lot
of
features,
for
example,
rate
limiting
and
external
authentication.
B
B
So
you
either
put
the
work
in
or
envoy's
intelligently
doing
this
for
you
by
embedding
a
graphql
server
in
envoy,
we
define
our
resolver's
envoy,
originates
the
requests
to
all
the
upstreams,
and
by
doing
so
it
uses
the
envoy
clusters,
it
kind
of
reuses
logic
from
the
router
filter
and
what
this
means
is
for
free
you're.
Getting
a
lot
of
these
other
resiliency
features
and
observability
features
that
you're
used
to
having
and
you
don't
have
to
redefine
or
rewrite
any
of
this
logic
and
resolvers.
B
So,
for
example,
it's
you
know,
envoy's
aware
of
which
upstreams
are
circuit
breaking
right
now
or
how
what
a
load
balancer
policy
we
want
to
use
or
which
ones
are
actively
healthy
from
active
or
passive
health
checking
and
our
resolvers
get
to
reuse
that
logic
and
you
don't
have
to
define
it
as
a
user
because
either
it's
already
there
or
you've
already
defined
it.
But
additionally,
we
get
more
for
free,
so
doing
things
with
declarative.
Resolvers
is
really
nice.
You
know,
one
very
specific
example
is
per
request.
B
You
have
to
say
how
can
I
group
a
bunch
of
requests
into
a
single
one,
so
think
you
know
a
large
sql
query
with
a
bunch
of
ids
instead
of
per
id
and
also
can
cache
the
results.
So
it
can
be
smart
and
say:
hey
I'm
resolving
these
fields,
and
I've
already
made
this
request
to
this
upstream.
I'm
going
to
reuse
the
response
and
not
hammer
my
back
end,
and
so
it
can
cache
but
usually
requires
that
the
user
provides
a
caching
id.
We
can
do
per
request.
Caching,
because
our
resolver
is
declarative.
B
We
know
exactly
what
the
request
outgoing
is
going
to
look
like
and
without
providing
an
id.
For
example,
we
can
do
smart,
caching,
so
user,
no
user
configuration
provided.
We
already
can
do
some
caching
for
you
that
otherwise
would
require
user
intervention.
You'll
get
other
optimizations
as
well
other
things
that
we
get
for
free
with
declarative
resolvers.
Obviously,
it's
been
talked
about
before,
but
git
ops,
everything
that
comes
nicely
with
git
ops,
so
a
nice
version,
edit
history,
secure
controls
on
who
can
main
you
make
edits
to
your
graphql
service,
your
photograph.
B
You
also
get
what
I
call
like
to
call
standard
resolvers
and
that
you
know
because
they're
declarative,
it's
easy
to
look
at,
and
it's
also
easy
to
understand.
If
they're,
all
programmatic,
you
have
to
read
a
lot
of
source
code,
they
might
not
follow
the
same
style.
You
kind
of
have
to
follow
the
same
style
when
you
follow
our
declarative
model
and
then,
lastly
validation.
You
know
we
can
do
simple
things
like
make
sure
that
there's
no
fat
fingers
in
you
know
remote
cluster
location.
B
We
can
do
the
standard
validation
that
comes
in
the
control
planes
that
are
driving
envoy.
This
can
be
leveraged
as
graphql
as
well,
and
all
these
benefits
come
without
losing
any
features
that
you're
used
to
so
other
security
features.
You
might
be
used
to
graphql
features.
Are
things
like
query,
cost
analysis
so
figuring
out
which
queries
are
expensive
and
how
to
limit
them
or
persistent
queries?
You
know
making
sure
we
only
run
queries
that
have
been
approved
for
production
things
like
that.
B
We
can
still
do
there's
no
technical
limitation
on
the
implementation,
the
graphql
server
that
we
embed
in
envoy.
We
just
get
other
things
for
free
on
top
of
as
add-ons,
and
that's
really
the
vision
of
what
we're
doing
here
so
from
here.
I'd
love
to
pivot
to
the
demo.
The
demo
here
mirrors
pretty
much
exactly
our
use
case
number
one.
So
we
have
an
api
gateway,
we're
an
organization.
B
We
want
to
authenticate
it
with
an
external
authentication
policy
and
we
want
to
scrub
a
request
or
access
logs
using
data
loss
prevention,
and
we
want
to
do
this
in
envoy
with
our
embedded
graphql
server.
So,
thankfully,
we
have
adam
he's
prepared
a
live
demo
for
us
today
and
I'm
really
excited
to
hand
it
off
to
him.
A
A
So
what
we
are
trying
to
achieve
during
this
demo
is
to
create
some
services
within
our
cluster
demo
services.
Then
we're
going
to
create
a
graphql
api
that
will
aggregate
data
from
these
three
different
data
sources
and
we're
going
to
secure
these
endpoints.
Okay,
so
first
step
here
is
to
create
some
services
that
we're
going
to
use
in
this
example.
Here
I'm
using
the
book
info
demo
application.
A
A
There
is
different
type
of
upstream
that
you
support
in
blue
edge
all
right
so
now
that
we
are
familiar
with
these
two
concepts.
First,
the
virtual
servers
for
the
routing
and
upstream
we're
gonna
see
how
we
can
first
use
them
to
route
some
traffic.
So
here
once
the
services
gets
created
in
the
cluster,
blue
edge
will
detect
them
and
we're
going
to
create.
It's
will
create
an
app
stream
for
each
service.
A
A
System
we'll
see
that
an
app
stream
it
just
as
a
again,
it's
just
a
representation
of
a
destination.
In
this
case,
it's
a
cube
service
within
the
same
cluster,
all
right
now
that
we
have
our
app
streams,
we're
going
to
create
our
graphql
api
and
for
that
we'll
go
and
create
a
graphql
schema,
cr
and
here's
an
example
of
of
one
yeah
of
an
api
that
will
represent
these
three
services
here,
we'll
see
at
first
the
graphical
schema.
A
So
once
we
create
our
resolver
here
and
we
have
different
ones,
we
have
one
for
author
one
for
pages
and
one
for
your
and
basically
all
the
resolvers
we
need
we
can
go
and
create
our
schema.
So
here
we
can
define
mainly
our
types
and
we
can
define
the
query
in
this
case
here.
I'm
representing
a
product
type
and
review
type
ratings
and
then
I'm
using
them.
Basically
in
a
query
here:
that's
all
you
have
to
do
to
define
a
graphql
schema
in
goog.
A
A
A
In
this
case
it
is
the
virtual
service,
the
cmo
it's
pretty
straightforward
here
I
have
matching
on
anything
and
it
will
route
some
traffic.
In
this
case,
all
the
traffic
to
the
slash
graphql
will
go
to
so
yeah.
The
slash
graphql
traffic
will
go
to
the
schema
we
just
defined
right
now
and
all
this
is
just
the
course
section
for
us
to
be
able
to
use
any
web
ui
to
explore
the
schema
okay.
A
A
That
should
be
enough
for
us
to
expose
an
api
graphql
api.
Let's
take
a
look
quick
here
and
to
I'm
using
altair
in
this
example
here
just
to
query
my
services,
so
I'm
gonna
call
the
endpoint
I
just
exposed
using
my
virtual
service
and
I'm
gonna
use
this
query
here.
This
will
fetch
data
from
three
different
data
sources.
A
A
Basically,
just
using
envoy
we
controlled,
we
sent
the
configuration
through
our
control
plane,
which
is
glue
edge.
This
configuration
got
replicated
on
our
data
pane,
which
is
envoy,
and
we
exposed
a
graphql
api
all
right.
So
this
is
the
first
step.
We
see
that
it's
easy
to
to
expose
any
graphql
api.
Now,
let's
take
this
a
step
further
and
let's
secure
this
endpoint
using
an
api
key.
A
A
A
A
So
if
we
take
a
look
here
at
one
of
the
config
for
the
api
key,
it
just
describes
that
it
is.
It
needs
an
api,
key
authentication
and
I
invite
you
to
explore
all
the
other
options
we
have
in
blue
edge.
We
have
many
other
options
that
you
can
use
in
the
alt
cafe.
You
can
use
oidc
workflow.
We
can
use
basic
auth.
You
can
use
opa
open
policy
agent
for
authen
for
for
odd
z,
and
you
can
also
use
your
custom
authentication.
Let's
say
use
hmac.
A
A
That's
all
we
need
here
we're
gonna,
just
reference
this,
this
cr,
which
is
the
auth
conflict
cr
in
our
virtual
service
that
you
create
we
created
previously.
So
let's
take
a
look.
How
a
virtual
service
would
look
in
this
case,
so
no
wrong!
One
virtual
service,
api
key
and
we'll
see
here
that
we're
just
using
the
same
virtual
service
this
time
we're
just
enhancing
it,
adding
the
api
key
support
by
just
referencing
the
cr
we
created
okay.
So
here
all
we
need
in
our
virtual
service
to
enforce
an
api
key.
A
And
see
that
we
have
here
a
401
unauthorized
and
that's
mainly
because
of
our
api
key
right
now,
we'll
have
to
basically
create.
We
will
have
to
pass
the
api
key,
so
we
can
call
the
back
end
right
and
here
is
how
to
do
it.
We're
gonna
have
to
go
under
setting
the
headers
here
and
we're
gonna
define
a
header
called
api
key
and
I'm
going
to
grab
the
value
of
the
secret.
A
I
just
created
and
save,
and
let's
make
a
request
again
there
you
go,
we'll
see
it
now,
using
only
one
simple
step:
we
enforce
api
and
api
key
security
at
at
the
api
level
right
and
think
about
it.
You
can
again
use
all
the
authentication
authorization
mechanism
we
have
in
glue
edge
to
achieve
the
same
result:
okay,
good!
A
A
So
in
this
example,
we
are
just
we're
going
to
use
a
dlp
policy
to
mask
the
reviewers,
but
think
about
this.
When
you
want
to
mask
social
security
numbers
account
numbers,
any
sensitive
data
can
be
masked
all
right.
So
to
do
this,
we'll
just
have
to
go
back
to
our
configuration
here
and
take
a
look
at
a
dlp
example,
and
here
is
a
virtual
service,
with
some
vlp
configuration
again
using
the
same
virtual
service
we
used
previously.
A
Now
that
our
virtual
service
is
configured,
let's
go
back
and
make
another
graphql
query
so
going
back
here
same
again,
let's
make
a
call
just
know
that
now
I
have
reviewer
still
and
clear,
but
now,
if
I
make
a
call
again
see
that
data
is
masked
okay,
so
this
is
a
quick
example
to
what
you
can
use.
You
know
we
actually
exposed
the
graphql
api
and
we
secured
we
secured
it
using
an
api
key
and
we
masked
some
sensitive
data
using
dlp,
but
we
support
many
other
filters.