►
From YouTube: Discover, Analyze and Secure your APIs, anywhere
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
I'd
like
to
thank
everyone,
who's
joining
us
welcome
to
today's
cncf
webinar,
discover
analyze
and
secure
your
apis
anywhere.
I'm
livi
schultz
I'll
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenters
today,
pranav
dawadker
vp
of
products
at
volterra
and
jakob
pavlik,
director
of
engineering
at
volterra,
a
few
housekeeping
items
before
we
get
started
during
the
webinar.
You
are
not
able
to
talk
as
an
attendee
there's
a
q,
a
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
A
A
B
Hello
hi
welcome
to
our
webinar
on
discover,
analyze
and
secure
your
apis
anywhere,
I'm
pranav
and
I'm
joined
with
jacob
public,
so
the
the
needs
from
modern
applications
are
changing
dramatically.
In
the
previous
decade
we
saw
the
applications
migrating
from
your
private
data
center
to
one
public
cloud,
so
it
was
a
hybrid
cloud
scenario.
B
However,
what
we're
seeing
now
is
that
there
are
new
application
architectures
like
microservices,
like
serverless,
where
it
has
a
big
impact
in
how
the
applications
are
architected,
networked
and
secured
the
in
in
a
virtualized
environment.
It
was.
It
was
okay
for
the
and
the
the
security
posture
to
be
around
the
ip
address
or
a
network
level
con
construct,
such
as
an
ip
address
or
a
port.
But
what
is
happening
is
with
the
move
to
modern
applications.
B
Applications.
Everything
is
around
apis
right
right.
So
now
you
cannot
have
a
networking,
a
security
that
is
focused
on
a
network
level
construct,
because
everything
is
the
same,
is
the
same
port
443
all
traffic
all
apis
is
going
is
multiplexed
on
the
same
port.
This
has
a
and-
and
therefore
this
has
a
big
impact
in
how
applications
need
to
be
networked.
How
applications
need
to
be
secure?
The
security
policies
cannot
be
based
on
just
a
port
number,
because
all
traffic
is
going
over
the
same
port.
B
So
this
change
of
the
way
applications
are
architected
is
resulting
in
security
holes
because
the
current
tools
that
that
users
have,
which
is
a
web
application
firewall,
essentially
protects
against
web
security
attacks
like
sql
injection
or
cross-site
scripting
or
extermination
entities.
It
does
not
protect
against
api
level.
B
Security
attacks,
which
are
more
like
apis,
is
exposing
too
much
data
or
the
authorization
for
the
api
is
broken
or
the
api
is
not
protected
in
terms
of
rate
limiting,
so
the
moved,
modern
applications
is
is
resulting
in
a
security
hold
which
the
current
tools
are
not
designed
to
protect.
B
That's
why
you'll
see
a
lot
of
api
or
app
firewall
vendors,
essentially
adding
more
api
security
features
and,
and
even
the
market
is
called
as
web
application
and
api
protection.
B
B
The
first
example
is
just
this
happened
last
month,
where
a
navigation
app
a
very
popular
navigation,
app.
The
api
actually
exposed
internal
personally
identified
information
also
called
as
bii
such
as
the
internal
user
id,
which
could
then
be
used
to
actually
get
the
username
of
the
user.
B
So
this
white
hat
hacker
peter
gasper,
used
this
apis.
He
was
just
sitting
on
on
the
road
and
was
was
listening
to
all
these
apis
and
and
seeing
what
information
is
being
shared.
So
essentially,
when
you
drive
on
the
road
you
can,
you
can
say
that
oh
there's
an
accident
or
there's
or
or
there's
a
road
hazard
right
that
api,
which
you're
using
to
indicate
obstacles
in
the
road
or
road
furniture.
B
That
api
is
what
expose
internal
user
ids.
So
someone
listening
to
the
apis
can
then
use
that
api
to
get
your
internal
user
id
then
use
intel
user
id
to
actually
get
your
username,
and
then
they
can
actually
build
a
map
of
where
you
are
traversing
and
and
essentially
expose
a
lot
of
personally
identified
information
of
of
the
user.
B
A
similar
example
is
that
happened
again.
Last
month
is
of
a
dating
app
where
the
password
reset
api
of
the
dating
app
essentially
returned
back
the
temporary
password
in
the
api
response.
B
So
if
I
were
to
just
go
to
the
web
to
the
website
and
say
and
enter
anyone's
user
id-
and
just
say,
you
know
reset
my
password,
the
response
would
actually
be
the
the
the
temporary
password.
So
I
didn't
need
to
even
have
access
to
your
email.
I
could
have
just
executed
the
password
reset
and
I
could
have
got
access
to
your
account.
B
That
again
is
another
example
of
an
api
security
problem
where
the
temporary
password
should
never
have
been
sent
back
in
the
api
response.
This
was
something
that
probably
the
users
or
or
the
developers
were
essentially
doing
in
their
dev
environment,
and
somehow
this
made
it
to
production
without
anyone
checking
or
without
anyone.
Knowing
that
this
is
happening.
B
The
third
example
happened
in
in
the
summer
in
june
is
a
large,
a
chain,
a
coffee
shop,
ap
chain,
there's
an
app
the
mobile
app,
which
allows
you
to
essentially
check
the
balance
of
your
gift
card.
B
So
what
this
this
api
did
is
that
this
app
essentially
speaks
to
something
called
as
a
back-end
for
front-end,
which
essentially
is
like
a
a
front-end
service,
which
then
talks
to
sort
of
the
real
backing
services
right.
So
this
this
this
coffee
shop,
app,
which
is
a
gift
card
api
to
check
the
balance,
was
essentially
sending
http
requests,
such
as
get
and
so
forth.
To
this
backend,
which
essentially
replayed
that
same
request
to
the
through
the
true
backend.
B
The
problem
is
that
if
a
user
essentially
put
in
this
string,
which
is
a
dot
dot,
slash
dot,
which
is
essentially
a
directory
traversal
pattern,
that
pattern
essentially
bypassed
the
existing
security
tool
which
they
which
they
had,
which
is
a
web
application
firewall,
and
so
by
bypassing
this,
then
the
bff
could
actually
speak
to
the
graph
service
and
could
actually
expose
almost
100
million
customer
records.
B
So
the
three
problems
that
this
api
security
attack
exposed
is
first,
this
service,
the
bff
should
never
been,
should
never
have
been
allowed
to
speak
to
a
really
important
services
graph
service,
which
essentially
holds
all
of
the
customer
records.
The
second
thing
is,
they
actually
had
a
web
application
firewall.
However,
this
web
application
firewall
was
easily
bypassed
by
this
pattern.
B
The
api
gateway
did
not
detect
this
pattern
and
did
not
block
it
right.
So
you
will
block
the
api
right
here.
If
they
saw
this
pattern,
then
this
could
have
been
prevented,
and
the
third
problem
that
you
can
see
is
that
there
are
almost
100
million
customer
records
being
sent
back
in
this
api
response.
That
should
have
been
flagged
as
unusual
and
should
have
been
blocked.
B
If
I
take
a
look
at
other
api
security
vulnerabilities,
these
are
not
only
limited
to
just
the
cloud
or
your
private
data
center.
This
is
actually
happening
everywhere,
cloud,
as
well
as
the
edge
I've
redacted.
These
are
all
publicly
available
information
by
the
way,
but
I've
still
redacted
it
in
order
to.
B
In
in
order
to
not
shine
light
on
these
different
vendors
or
the
oems,
but,
for
example,
on
the
edge,
a
smart
tv
which
has
apis
to
control
your
remote
or
to
control
the
channel
or
to
control
other
information,
those
those
are
vulnerable
to
hacking.
B
As
as
seen
at
this
report,
there
was
a
gym
application.
Where
you
can,
we
can
exchange
your
gym
data
when
you
do
a
machine
that
exposed
a
lot
of
information
about
users,
work
for
about
thousands
of
users,
your
wi-fi
hotspot,
that
is
sent
by
a
service
provider.
B
B
And
lastly,
this
is
not
limited
to
just
one
geography.
This
actually
is
happening
across
the
world.
For
example,
in
europe
there
was
a
mat,
there's,
an
online
fashion,
retailer,
which
exposed
almost
one
terabyte
of
data
in
a
massive
data
and
by
the
way,
all
these
examples
are
pretty
recent.
As
you
can
see,
october
or
august
of
of
this
year,.
A
B
The
problem
is,
someone
has
to
look
at
what
the
api
request
is,
what
the
response
is
and
then
identify
if
there's
something
bad
happening
in
case
of
this
large
coffee
shop.
Api,
as
I
saw
the
first
thing,
is
the
problem:
is
they
didn't
detect?
B
B
They
knew
that
they
were
data
being
shared,
but
they
didn't
know
that
that
was
pii
data
in
the
fourth,
the
gym
app,
the
the
password
reset
was
essentially
a
four
digit
code,
so
basically
10
000
requests
and
they
did
not
have
rate
limiting
set.
So
someone
could
and
that's
what
the
hackers
did
is
they.
B
They
basically
tried
ten
thousand
times
and
they
could
break
the
password
reset
and
then
they
could
get
access
to
someone's
pii
personal
health
data,
so
they,
the
problem,
is
that
they
did
not
know
the
correct
threshold
to
set
for
rate
limiting
the
password
reset
request
in
case
of
the
in
case
of
the
online
retailer,
which
was
a
one
terabyte
data
leak.
B
The
problem
is
that
that
there
were
multiple
services
to
each
other
and
it
was
a
very
manual
effort
they
knew
who
was
talking
to
whom,
but
they
didn't
know
how
to
protect
it
and
and
by
the
way,
the
api
kept
changing
the
service
kept
changing.
So
while
it
probably
worked
at
some
point
in
time,
it
did
not
keep
up
with
the
changes,
because
everything
was
done
manually,
it
wasn't
automated,
so
the
problem
is
the
manual
application
of
policies
in
the
in
the
microservices
environment.
B
In
case
of
the
in
case
of
the
auto
oem
or
even
the
smart
tv
uem,
the
problem
is
that
they
only
protected
the
back
end
data
center.
They
did
not
protect
the
actual
edge,
which
is
the
car
or
the
tv
a
because
they
did
not
have
the
the
software
or
or
the
means
to
actually
protect
it
on
the
edge
because
in
the
edge
it
doesn't
it's
it's
constrained,
it
does
not
cannot
run
what
can
run
in
your
entire
data
center.
At
least
the
current
tools
are
not
designed
to
be
run
anywhere.
B
That
is
the
problem
right,
so
they
protected
only
the
back
end,
but
if
someone
could
actually
hack
into
the
edge,
then
then
does
not
matter
how
much
protection
you
have
in
the
back
end
it's
the
edge.
That
is
the
problem,
so
they
needed
a
solution
that
is
essentially
applicable.
That
needs
to
be
deployed
in
both
places.
So
hopefully
these
real-world
examples
can
explain
and
can
show
that
the
traditional
tools
are
not
designed
for
api
security
attacks
and
they
are
not
designed
to
be
run
anywhere.
B
So
the
current
tools
that
we
have
is
the
the
firewall,
a
load
balancer
web
application
firewall
and
an
api
gateway
are
not
designed
to
run
for
new
modern
applications,
and
these
modern
applications
need
something
that
is
more
apt
to
act
or
api
to
api
focused,
and
that
is
what
any
user
who's
looking
at.
These
modern
applications
need
to
look
at
a
solution
that
is
active,
app
or
api
api
focus,
which
essentially
does
four
things.
B
B
B
And
that
is
what
this
this
dot
and
this
demo
will
show
you.
So
if
you,
if
I
dive
one
step
deeper,
the
the
add
to
app
and
api
to
api
security
focus
solution
should
solve
the
following.
Four
things:
for
users:
first
discover
it
should
tell
you
who
is
talking
to
whom,
how
much
and
when
like
is
it?
Is
it
at
night?
B
Is
it
the
normal
communication
in
the
mornings,
or
also
that
night,
so
it
should
basically
establish
it,
should
give
you
information
of
what
is
a
normal
communication
pattern
right
and
based
on
that,
then
you
can,
then
you
can
identify
what
is
abnormal
next.
You
should
tell
you
what
data
is
being
shared
by
your
apis,
and
then
it
should
tell
you,
okay,
given
the
data
has
been
shared,
is
it
pii
data
or
not
right?
It
should
then
tell
you
what
is
the?
What
is
the
normal
request
rate?
What
is
the
normal
response
size
prism?
B
B
The
the
third
step
is
securing
right.
It
should
then
tell
you,
okay,
it's
sharing
this
data,
it
shouldn't
be.
They
shouldn't,
then,
give
you
a
pattern.
So
a
signature
to
say.
If
I
see
this
pattern,
I
know
that
I'm
block,
I'm
I'm
exposing
bi
data
and
I'm
actually
going
to
give
you
the
pattern
so
that
it
is
easy
for
you
to
create
a
policy.
B
It
should
also,
then,
give
you
the
the
ability
to
automatically
apply
the
policies
so
because
your
apps,
your
apps,
are
in
a
microsoft
environment.
Your
apps
are
changing
continuously
your
apis.
Your
developers
are
adding
new
apis
continuously,
it
needs
the
ability
to
you
cannot
keep
up
manually.
Therefore,
you
need
the
ability,
the
for
the
solution
to
actually
automatically
generate
the
policies
for
you
and
a
dude
in
a
positive
security
model
fashion
which
allows
this
is
what
is
allowed
and
everything
else
is
blocked.
B
This
way
you
can
keep
up
with
changing
environments
and
ensure
that
there
are
no
security
holes
and,
lastly,
it's.
The
solution
should
essentially
enable
you
to
run
your
api
security
policies
anywhere,
both
in
the
cloud
in
the
edge
on
the
network
or
in
any
environment.
B
Let
me
hand
it
over
to
jakub
to
show
you
a
demonstration
of
what
a
what
the
solution,
how
the
solution
can
be
used
to
block
some
of
these
security
attacks
that
I
mentioned
earlier.
C
D
C
A
D
I
can
yes,
okay,
okay,
so
let's
start
so.
What
I
have
here
is
I
deployed
application
called
hipster
shop.
It's
an
online
boutique
application.
It's
actually
originally
developed
by
google.
It's
example
microservice
app
and
I'm
running
it
in
the
awsvpc.
D
So
I
am
having
vpc
with
eks
and
I
am
running
a
volt
mesh
gateway,
ingress
gateway
which
is
serving
the
request
to
the
microservices
and
that
this
app
is
consists
from
eight.
I
think
up.
So
all
requests
goes
to
front-end
and
then
front-end
talks
to
ad
service,
checkout
service,
product,
catalog,
redis
recommendation
service.
So
it's
a
real
micro
services
app
exposed
on
the
public.
D
So
if
I
show
you
what
I
mean
so
I
have
it
live
today
on
this
end
point.
So
if
we,
if
we
open
so
this
is
the
micro
services
app
and
if
I
navigate
I'm
actually
hitting
various
components
like
cart,
checkout,
service
and
payment
service
and
service
and
recommendation
service.
So
it's
a
simple
app
served
on
public
which
is
running
in
this
vpc.
D
So
now,
first
thing:
what
I'm
going
to
do
is
I'm
going
to
discover.
D
So
what
is
happening
here
is
visitors
are
coming
to
our
global
backbone
and
the
traffic
is
reaching
here
and
we
are
collecting
locks
and
metrics
to
our
sas
service,
so
we
take
metrics
and
logs
and
we
are
actually
able
to
build
the
first,
the
service
mesh
graph,
so
you
see
like
who,
who
is
talking
to
who
and
we
are
also
able
to
display
usage
graph.
D
So,
let's,
let's
check
it
out,
I
can
go
here
and
first
we
can
start
with
the
up
traffic,
so
I
am
now
logged
in
inside
of
one
of
the
tenant
in
vault
console
where
I
am
serving
the
hipster
shop.
What
would
I
show
you
and
if
we
look
at
the
application
traffic,
we
can
see
that
traffic
is
actually
reaching
the
the
our
our
backbone
and
then
he
goes
to
aws.
So
this
view
is
like
a
physical
view
how
traffic
is
flowing.
D
Now,
if
we
go
to
the
service
mesh
graph,
we
see
we
are
running
a
hipster
shop
and
we
actually
are
able
to
see
the
who
is
talking
to
who,
based
on
the
metrics
graph
in
last
six
hours
or
in
last
12
hours,
so
I'm
able
to
see
the
communications
pattern.
So
this
is
the
front
end
hipster
shop.
It
is
coming
from
the
public
and
then
it
is
going
to
advertise
product
card
service
checkout
service.
So
I
am
able
to
see
how
they
communicate
same
way.
D
If
I'm
interested
on
what
api,
because
this
was
up
to
up.
If
I
want
to
discover
api
to
api
communication,
I
am-
I
am
having
api
endpoint
graph,
where
I
can
actually
see
entire
structure
of
of
my
app.
So
we
can
see
we
are
reaching
the
main
page
and
then
then,
let's
say
44:
0.2
percent
is
going
to
currency
service
and
28
percent
is
going
to
catalog
service
and
then
from
there
36
percent
is
reaching
convert
service.
D
So
you
can
see
you
can
see
each
individual
end
points
and
how
much
they
are
you
can
you
can
zoom
in
out
and
you
can
focus
on
on
the
part
which
you
are
interested,
but
you
see
what
portion
goes
where
and
exact
api
endpoint
what
we
are
hitting.
D
So
this
is
the
discovery
part
where
I
am
not
able
only
to
see
the
what
service,
what
microservice
talking
to
what
microservice,
but
also
both
api
endpoints,
are,
are
used
now
if
we
go
back
so
this
is
the
discovery
part,
so
we
discovered
just
by
running
application
inside
we
discovered
how
they
communicate
now.
This
is
this
is
just
the
summary,
so
we
have
up
to
up
communication
graph
and
api
to
api.
D
Now
next
part
is
analyze
so
because
I
am
having
logs
and
I
am
having
the
metrics,
I
am
able
to
set
the
baseline
for
the
normal
up
to
up
and
api
to
api
patterns.
I
am
able
to
say
what
is
the
normal
request
rate,
what
is
the
size
on
individual
apis
and
I'm
able
to
learn
and
see
what
are
the
time
series
analyzes
and
graph
analysis?
What
are
the
structure,
properties
and
entropy
of
the
node,
and,
what's
more,
I
am
able
to
also
through
the
machine
learning,
find
the
schema
of
the
application
itself.
D
So
I
am
able
to
say
what
they
are
exactly
talking
to,
not
just
who
and
see
the
if
it
is
string
or
if
it
is
integer.
What
is
the
required
field
on
the
api
and
I'm
able
even
to
produce
swagger
for
the
developers
and
get
like
a
documentation
and
what's
more,
we
can
even
analyze
if
it
is
personal
identification.
Information
like
it's
called
pii
data
and
we
can
notify
and
and
alert
our
secops
or
operational
team
that
such
data
are
flowing
through
the
api.
D
So,
let's,
let's
take
a
look
on
how
what
we
can
see
here.
So,
let's
start
with
the
with
the
metrics.
So
if
we
go,
if
we
go
on
the
product
catalog,
which
is
the
main
page,
we
go
on
the
metrics.
D
So
now,
because
this
demo
was
almost
the
shutdown
the
confidence
interval
was,
was
around
six
requests
per
second
maximum.
And
now
you
can
see
that
just
before
demo,
I
made
few
requests
and
you
can
see
that
we
have
anomaly,
because
I
am
reaching
like
8.5
request
per
second
and
it's
anomaly
and
I
can
get
alert
and
I
can
immediately
know
that
there
is
something
wrong
in
the
application
to
application
communication.
So
this
is
a
metrics
metrics
base.
D
Now
I
see
the
request
rate
and
this
is
based
on
metrics,
but
I
also
want
to
see
api
to
api
analyzes.
So
if
I
go
back
to
my
service
mesh
and
my
api
endpoints,
I
can
actually
go
on
the
checkout
endpoint
and
I
am
getting
provided
probability.
Distribution
functions,
graphs,
where,
let's
pick
the
example
on
this
api,
let's
pick
the
request
rate,
and
what
is
this
saying
is
that
there
is
a
let's
say,
98
of
the
request,
r
0.67
kilobytes.
B
D
D
So
now
there
is
one
more
feature
which
is
actually
learn
api.
So
what
this
thing
does
is
we
are
able
to
learn
schema
from
the
requests,
and
you
can
see
here
if
we
go
back
to
the
hipster
shop
and
we
we
will
go
on
on
the
checkout
service.
D
You
can
actually
see
you
can
actually
see
here
that
I
am
sending
emails,
theta,
dress,
zip
code
city
country
and
I'm
sending
credit
card
in
the
request.
D
But
and
if
we
switch
back,
you
can
see
that
what
we
learned
is
exactly
same
set
of
parameters.
So
I
see
what
is
the
required
on
this
same
city,
email,
zip
code,
and
what
we
are
able
even
to
extract
is
what
is
pi
data.
So
in
this
example,
we
identify
that
there
is
an
email
address
which
goes
in
the
api
and
it's
a
pi
data.
So
we
extract
it
for
the
operator.
So
he
see
that
there
is
such
information,
and
I
have
even
example.
D
So
you
can
see
here
is
the
example
len
from
the
from
the
schema
now
one
more
feature.
What
is
available
is
actually
a
pattern,
not
just
the
lan,
how
look
the
schema,
but
we
also
give
you
the
pattern
of
the
field,
and
this
allows
you
to
then
later.
What
I
will
show
is
to
create
the
policies
to
block
such
a
pattern
and
identify
it
in
your
api
and
don't
allow
even
requests
to.
D
And
here
is
what
I
mentioned
the
swagger,
so
you
can
see
that
we
are
able
to
generate
swagger
for
for
the
for
the
api,
so
this
is
the.
D
If
I
summarize
this
part,
what
you
just
saw
is
a
baseline,
normal
up
to
up
communication
patterns
from
metrics,
but
also
api
to
api
requests
and
response
patterns
from
the
individual
apis,
and
I
just
showed
that
we
learn
schema
from
the
application
itself
and
we
can
identify
what
is
personal
information
and
determine
what
is
the
pattern
and
you
will
see
later.
D
I
can
use
the
service
policies
to
block
such
pattern
in
the
request,
so
this
is
matching
what
pranav
was
explaining
those
mistakes?
What
developer
does
that
some
api
responds
with
the
email
back?
This
would
not
happen
if
you
would
configure
a
service
policy
with
this
pattern
to
block
those
responses
on
the
public
api.
D
D
Now,
I'm
going
to
show
you
how
I
can
easily
secure
so
as
a
devops
guy,
I
deployed
the
app
I'm
running
the
app
and
now
from
the
second
point
of
view,
since
we
all
the
discovery,
he
can
analyze
it
and
he
can
easily
easily
block
it.
So
now,
let
me
show
you:
we
have
something
called
service
policy
and
right
now
I
am
having
some
gdpr
example
policies
and
blocking
on
unauthorized
countries,
but
I'm
not
having
much
rules
here.
D
Besides
this
example,
so
you
can
see
there
is
no
like
other
stuff
than
just
blocking
some
embankment
embargo
countries
outside
of
the
in
the
embargo
counties
for
the
united
states.
D
But
now
what
I'm
going
to
do
is
the
everything
what
I
show
you
has
a
api
and
we
built
something
what
we
call
ninja
cattle,
which
is
the
cli
tool
who
actually
pulls
our
api
and
tells
which
client
and
server
talks
to
who
so
how
they
talk,
what
kind
of
methods
what
kind
of
api.
D
Now,
let's
see
the
difference
when
I
will
execute
the
control
command,
which
will
take
last
24
hours
and
program,
the
service
policies
only
on
the
stuff
which
we
learn
and
one
more
advantage
here
is
that
since
it
is
using
generic
labels,
you
can
even
move
between.
You
can
learn
on
the
staging
and
enforce
it
on
the
production.
D
D
If
we
check
the
rules,
there
is
many
rules
now
dynamically
created,
so
I
could
go
and
add
rules
by
hand
like
this,
but
that
would
take
me
a
long
time.
That's
why
we
created
the
cli
tool,
which
does
it
for
me
and
now,
if
I
switch
back
and
we
will
refresh
the
page
instead
of
4.4,
I
am
getting
403
forbidden
because
it's
not
allowed-
and
it's
not
end
point
which
was
learned
from
our
api.
So
main
page
still
works.
D
I
can
still
use
it,
but
the
other
pages
like
catalog
with
number
one
or
two
doesn't
work.
So
I'm
blocking
the
traffic
which
I
which
I
didn't
learn.
So
this
is
the.
This
is
the
way
how
you
can.
D
One
one
use
case
how
we
use
it
is:
we
are
having
staging
where
we
generate
traffic
test
cases,
people
use
it
and
then
we
just
switch
the
namespace
and
run
the
same
app
in
production,
and
we
can
just
move
the
rules
from
staging
to
production
and
make
sure
that
all
api
which
are
allowed
are
properly
allowed,
and
it
is
all
dynamic.
B
So
see
aku,
can
you
explain
how
this
what
you
just
showed
can
be
used
to
block,
for
example,
that
coffee
shop
api
attack?
Can
this
be
used
to
block
that.
D
Yes,
yes,
so
you
can
so
there
is
many
ways
how
to
do
it.
The
service
policy
service
policy
rules
support
various
things,
various
functions
based
on
label,
selector,
name,
client
or
that
regex
method.
So
there
is
a
various
ways,
exact
value
and
even
the
stuff.
What
I
showed
what
we
learned
in
the
service
policy?
D
The
pattern,
the
matching
pattern
on
based
on
pi
data-
you
can
configure
it
in
the
service
policy
and
then
apply
it
to
your
all,
only
all
name,
space
like
all
api,
endpoints
or
particular
part,
particular
micro
service,
api,
endpoint
and
block
block
email,
for
instance,
on
all
apis
that
they
cannot
send
the
email
pattern
easily.
This
can
be
done
through
this
service
process.
D
B
So,
for
example,
the
security
that
we
talked
about
earlier,
where
someone
is
sharing
the
pii
data
email,
you
can
block
it
using
the
regex
pattern
or
even
the
product
three,
where
you
had
changed
the
url.
You
could
block
that
for
the
coffee
shop
api,
where
they
had
that
dot,
dot,
slash
dot
pattern
that
could
be
blocked
using
the
fact
that
you're
creating
these
automated
policies.
D
D
Thank
you
so
now
I
am
passing
ball
back
to
pranav.
D
B
Can
all
right,
I
can,
if
you
can
start
sharing
jakku
when
I
can
share
yeah.
C
B
B
If
you
look
at
whether
problems
occurred,
you
had
some
real
word
examples
where
the
problem
occurred,
because
this
was
running
in
the
public
cloud.
So
you
need
a
solution.
You
need
a
solution
where
the
users
are
accessing.
For
example,
your
your
website,
your
web,
app,
are
directly
coming.
The
traffic
is
coming
to
your
to
your
online
to
your
to
your
backend
cloud,
which
could
be
in
public
cloud.
B
You
need
a
way
to
protect
this
app
or
api
on
the
edge.
If
you
remember
the
example
of
the
auto
em
or
the
smart
tv
oem.
B
In
that
case,
the
app
or
the
api
need
to
be
protected
at
the
on
the
vehicle
or
on
the
home
right,
which
means
that
you
need
a
way.
Any
solution
that
protects
against
apple,
app
or
api
to
api
needs
the
ability
to
protect
the
api
right
on
the
edge
so
that
traffic,
any
meniscus
traffic
or
any
api
attack
being
done
from
the
edge,
is
protected
right
here.
B
B
So
any
solution
that
you
look
for
needs
the
ability
for
the
app
or
the
api
to
be
protected,
where
you're,
exposing
that
api
and
that's
and
that's
one
of
the
solutions
that
you
need
to
look
for
is
ensure
that
the
solution
is
deployable
anywhere.
B
So
in
this
case,
the
solution
that
should
look
for
ensure
should
ensure
that
once
the
devops
systems
define
a
policy
for
api
that
jakob
showed
previously,
you
define
the
policy
once,
but
now
when
the
app
or
the
api
is
exposed
on
the
edge
that
policy
is
sent
by
the
control
plane
to
the
edge.
If
it's,
if
the
api
gets
exposed
or
it's
exposed
to
a
partner
privately
on
the
partners,
data
center,
the
the
the
policy
should
ensure
they
should
be
distributed
down
to
this
edge
as
well.
B
First,
we
established
that
the
needs
for
modern
apps
are
changing
and
add
to
app
and
api
to
api
communication
is
not
protected
by
your
existing
solutions,
which
are
discrete
silos
of
a
network,
firewall,
a
load
balancer,
a
web
application
firewall
or
an
api
gateway.
A
discrete
set
of
solutions
does
not
work
for
modern
applications.
B
Modern
applications,
which
is
predominantly
dominated
by
app
to
app
or
api
to
api
communication,
needs
a
security
solution
that
is
more
focused
on
app
to
app
and
api
to
api,
which
should
essentially
integrate
these
different
functions
into
a
single
stack,
and
we
should
do
four
things
for
you.
First,
it
should
enable
you
to
discover
what
communication
is
occurring
between
the
different
apps,
all
the
different
apis.
B
It
should
give
you
patterns
about
the
communication.
When
is
it
happening?
How
much
is
accumulation?
What
is
the
normal
rate?
What
is
the
normal?
It
should
tell
you
what
data
is
being
shared
by
your
apis,
and
if
the
data
is
pii,
it
should
tell
you
that
then.
It
should
then
enable
you
to
secure
your
app
to
app
and
your
api
with
api
communication
in
an
easy
manner
manner,
but,
more
importantly,
in
an
automated
fashion,
because
your
your
apps
and
your
apis
will
be
continuously
changing
being
conveniently
changed
by
your
developers.
B
So
automation
of
policy
generation
is
key
and
the
fourth
solution
that
fourth
tenet
of
the
solution
that
you
should
look
for
is
ensure
that
any
app
to
app
or
api
to
api
security
solution
is
deployable
anywhere
both
on
the
cloud
on
your
partner
side
on
the
edge,
as
well
as
on
the
network,
I'll
pause
there
and
I'll
open
it
up
for
any
questions.
A
B
B
Right
so
so
the
question
is:
how
do
you,
how
is
the
air
models
being
trained
on
sort
of
a
your
simulated
traffic
versus
real
air
traffic?
This
is
because
of
continuous
learning
right.
So
that's
why
you
have
something
called
as
like.
You
have
this
dev
environment,
a
staging
and
production.
So
so,
let's
see
so
I
think
jakub
talked
about
it
and
let
me
explain
one
step
further
in
a
staging
environment,
you're
actually
sending
a
percentage
of
your
live
traffic
to
your
staging
environment.
B
For
you
to
sort
of
see
how
is
it
performing
right?
You
can
actually
set
that
in
your
weights,
in
your
in
the
amount
of
traffic
that
you're
sending
and
using
that
you
can
learn,
you
can
learn.
Okay,
how
much
is
it?
What
is
your
normal
pattern,
as
jakub
showed?
Is
your
normal
pattern?
B
Is
only
this
request
size
or
this
request
rate,
but
once
you
learn
so
once
you
learn
from
that
you,
you
can
generate
your
policies,
as
you
showed,
with
ninja
cuttle
you,
you
learn
your
poli,
you
learn
your
rates
and
then
you
can
generate
a
policy,
but
the
policy
is
not
is
not
it's
not.
There
is
no
there's
nothing
saying
that
this
is
it's
defined
based
on
the
api
endpoints
right,
so
you
can
just
take
the
same
policy,
learn
from
your
skating
environment
and
apply
in
production
right.
B
So
so
that's
that's
one
way
where
you
can
easily
replicate
whatever
you're
learning,
where
your
staging
environment
is
running
a
percentage
of
your
real-life
traffic,
you
can
learn
that
and
apply
it
to
production.
The
second
thing
also
is
once
it
is
in
production.
It's
not
like
it's
done
deal
it's
an
api
learning
model.
It's
continuously
learning
right.
So
this
api
learning
model
is
continuously
learning
and
that's
where
the
automated
policy
comes
in
is
once
you
learn
it.
You
can
learn
the
same
thing
on
production
and
in
production.
You
can
see
your
probability
distribution
functions.
B
Maybe
the
traffic
patterns
are
different
right,
but
but
the
thing
is
because
it's
an
api
learning
model
you're
conveniently
learning,
so
you
can
create
a
new
probability
distribution
function
and
then
the
key
thing
is:
how
do
you
generate
the
policies
automatically
so
based
on
what
you
learned,
you
can
then
run
the
tool
again
in
production
to
generate
the
policies
and
apply
it.
So
that's
what
you
should
look
for
in
any
app
to
add
or
api
to
api
security
solution.
I'll
go.
D
Back
soon,
I
I
can
add
one
more
right,
so,
of
course,
you
cannot
learn
on
staging
request
rate
right
policy.
That
is
no
sense,
but
you
can
learn
that
example
with
coffee
shop
right.
There
was
some
long
url
with
many
backslash
and
then
something.
This
is
something
where
you
can
learn
in
staging
and
apply
to
production
easily
like
what
api
are
allowed,
but
the
request
rate.
For
instance,
you
cannot
land
on
staging
that
needs
to
be
tuned
on
the
production.
That's
the
that's
the
difference,
god
yep,
absolutely
yeah.
B
Left,
no,
I
don't
have
anything
else.
I
think
we've
covered
everything
that
we
need
to
cover
jacob.
If
you
want
to
add
something
I
am.
I
am
fine.
A
All
right
well,
thank
you
both
so
much
for
a
great
presentation
and
thanks
everyone
for
your
q,
a
that
is
all
the
questions
and
we're
about
at
times.
So,
thanks
for
joining
us
today,
the
webinar
and
recording
slides
the
webinar
recording
and
the
slides
will
be
online
later
today,
and
we
look
forward
to
seeing
you
in
another
cncf
webinar
soon.