►
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
Thanks
for
joining
us,
everyone
as
people
continue
to
join,
we'll,
go
ahead
and
get
started.
I'd
like
to
thank
everyone
for
joining
us.
Welcome
to
today's
cncf
live
webinar,
introduction
to
api
clarity,
a
wireshark
for
apis.
I
am
libby
schultz
and
I'll
be
moderating.
Today's
webinar
I'd
like
to
introduce
our
speakers
today,
zar
kauffman
principal
engineer
at
cisco
and
alexi
kraftsov
technical
lead
at
cisco
as
well,
and
please
introduce
yourself
and
say
your
name:
the
right
way
alexi.
I
know
I
probably.
B
C
A
A
Public
chat,
slack
channel.
Excuse
me
cncf
cncf-online-programs,
to
continue
the
conversation
later
and
address
any
questions
you
have
that
we
didn't
get
to
today.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chatter
questions
that
would
be
in
violation
of
the
code
of
conduct
and
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
A
Please
also
note
that
recordings
and
slides
will
be
posted
later
today
to
the
cncf
online
programs,
page
accessible
via
your
registration
link
or
on
our
online
programs,
youtube
playlist.
With
that,
I
will
hand
it
over
to
zoar
and
alexi
to
kick
off
today's
presentation.
I
know
everyone
is
eagerly
awaiting
so
we'll
get
started.
C
Thank
you
very
much.
Libby
hi,
I'm
zora,
kaufman
and
together
with
me
today,
is
that
execraft
solved
few
words
about
myself.
I
was
the
co-founder
of
cictera
networks
that
is
active
in
the
cloud,
storage
and
enterprise
file
services
area.
Later
I've,
I've,
co-founded
porchev,
together
with
randylani
a
startup
that
focused
on
genetic
security
that
was
acquired
a
year
ago
by
cisco
alexa.
You
want
drinks
yourself,
hey.
B
C
Thank
you
alexa,
so
maybe
you
can
in
order
to
kill
the
echo
in
cisco.
We
joined
an
effort
around
api
security
in
kubernetes
and
stumble
upon
the
problem
space
that
we
will
present
today.
This
work
was
inspired
by
peter
bosch
and
alessandro
dominuco,
so
I
would
like
to
thank
them
both
and
let's
go
to
the
next
slide.
C
So
what
is
on
our
agenda
today?
Why
do
we
need
api
specification
reconstruction
possible,
open
source
packages,
survey
that
we
did
in
order
to
to
solve
this?
We
didn't
find
anything
so,
or
at
least
it's
something
that
they
will
answer
all
our
needs,
so
we
introduce.
We
will
introduce
api
clarity,
a
new
open
source
that
we
developed.
C
C
So
what
is
so?
What
is
the
the
challenge
that
we
stumble
upon?
Cloud
services
are
becoming
more
and
more
popular.
Many
of
them
are
using
an
opi
open
api
specification
to
define
a
standard
language
agnostic
interface,
which
allows
both
humans
and
computers
to
discover
and
understand
the
capabilities
of
a
service
without
access
to
source
code
or
documentation.
C
C
We
would
also
like
to
detect
drifts
between
implementation
and
specification
application
that
they
still
use
the
deprecated
apis
also
called
zombie
apis
and
undocumented
ones.
Also
called
shadow
apis
gardner
recently
published
the
hype
cycle
for
apis,
where
they
state
that
every
connected
mobile,
modern
web
or
cloud
hosted
application,
use,
uses
and
exposes
apis.
C
C
We
looked
for
a
cloud
native
open
source
that
will
allow
us
to
do
all
this,
but
didn't
find
a
solution
that
will
answer
all
our
needs.
In
the
next
few
slides,
we
will
highlight
some
useful
sites
and
solutions
we
found
during
our
survey
and
then
we
will,
of
course
describe
the
api
clarity,
so
the
first
one
is
a
open
api
tools.
It's
a
great
aggregation
of
open
of
api
specification
tools
and
knowledge
by
categories.
C
C
One
of
the
more
interesting
solutions
we
saw
is
from
optic
optic
is
an
open
source
tool
that
helps
developers
to
document
review
and
approve
api
changes
prior
to
deploying
them.
It
is
lag
mode.
Agnostic
works
with
any
rest.
Api
observes
development
traffic
and
that
learns
your
api
behavior
and
has
a
great
mechanism
to
manually
review
and
update
the
specification.
C
C
Swaggerhab
also
has
a
great
solution.
You
may
generate
the
api
traffic
from
the
web
ui
using
their
inspector
tool
record
it
and
create
the
open
api
spec
using
swaggerhub.
However,
they
lack
integration
with
runtime
environments
and
they
don't
have
an
open
source
available
cloud
vector
has
also
a
nice
solution
called
api
shark.
It
has
a
live
monitoring
of
multi-services
environment,
it
can
automatically
detect
parameters
and
create
the
open
api
spec
from
the
runtime
traffic.
However,
it
is
not
open
sourced
and
it
lacks
the
option
to
review
the
spec
and
detect
the
deviations
from
it.
C
Imvision
in
another
is
another
good
solution.
They
do
live.
Monitoring
of
multi-service
environments,
create
open
api
specs
from
runtime
traffic,
support,
detecting
deviations
from
spec
and
have
a
mechanism
to
manually
review
and
update
the
generated
traffic.
So
all
this
is
great,
but
they
don't
have
an
open
source
that
they
we
may
utilize.
C
C
The
user
can
then
review
the
reconstructed
specs
and
declare
them
as
a
baseline
or,
alternatively,
provide
official
specifications
to
be
compared
to
the
reconstructed
ones.
After
afterwards,
we
can
note
all
the
api
events
that
are
different
from
the
approved
spec
and
highlight
zombie
and
shadow
apis.
C
C
We
used
istio
and
then
voice
cycle
proxies
and
they
both
help
help
us
observe
all
the
api
traffic
and,
as
a
result,
we
can
reconstruct
specs,
highlight
api
differences
and
other
abnormalities,
while
the
user
can
review
the
spec
and
make
changes
as
needed.
So
this
was
you
know
our
a
I'd
like
first,
a
first
implementation.
We
will
see
in
the
roadmap
how
we
plan
to
evolve
from
here,
yeah,
so
few
spec
reconstruction
features.
C
It
is
important
to
highlight
we
detect
spec
parameters,
whether
in
the
path
of
the
query
in
the
parameters
in
the
query
parameters
in
the
headers
or
cookies.
We
understand
object
reference
references
that
might
be
included
in
the
spec.
We
support
file
transfer
apis
and
for
security
definitions.
We
we
digest
basic
auth
and
oauth2.
B
Yes,
thanks.
C
B
So,
in
short,
while
I
show
you
a
demo
of
api
clarity
and
my
setup
for
the
demo
is
a
kubernetes
cluster
and
istio
service
mesh
that
is
already
deployed.
I
have
api
clarity
installed,
which
I
will
show
you
in
a
second,
how
we
can
do
it
too,
and
in
order
to
generate
traffic
and
try
to
learn
the
apis.
I
have
the
stock
shop
demo
up
by
weave
and
just
to
help
me
to
generate
some
api.
C
A
B
Okay,
so
in
the
demo
flow
I'll
show
you,
like,
I
said
about
the
deployment
you
can
just
clone
build
if
you
want
it
by
your
own
or
deploy
the
yamls
and
the
the
pre-built
images
and
binaries
that
we
already
provided
you
and
then
we'll
see
in
run
time.
The
all
the
api
events
and
even
know
the
api
events
captured
by
api
clarity
and
we'll
show
you
also
to
how
to
see
the
trends
using
the
graph
and
the
heat
count.
B
Graphs
that
are
also
provided
and
we'll
show
you
how
we
do
the
opening
bi
spec
learning
from
the
generated
traffic
of
the
softshop
demo,
and
I
will
show
you
the
review
process
to
how
can
you
give
that
human
flavor
to
to
the
gen
automatically
generated
api,
and
once
the
apis
are
approved,
we
can.
We
can
try
to
see
divs
against
the
against
the
actual
traffic,
and
that
also
can
be
used.
C
B
B
B
You
just
need
to
you
need
this
sub
model
and
you
have
a
script
that
you
you
can
choose
which
namespaces
you
want
to
monitor
and
see
the
traffic
from.
So
you
just
run,
deploy
with
the
namespace
that
you
are
interested
in
seeing
the
traffic
and
that's
it-
maybe
a
few
words
about
the
design
here
and
the
components
that
are
running
in
the
cluster.
B
Actually,
in
your
kubernetes
cluster,
everything
all
the
traffic
once
the
deploy
the
web
assembly
filters
are
set
in
your
deployments,
all
the
traffic
is
mirrored
using
istio
a
two
api
clarity
to
its
reconstruction
engine,
and
we
also
have
a
nice
web
ui
in
order
to
see
it
all
and
and
manage
your
apis,
and
so
that's
all
you
need
to
do.
Of
course,
there
are
more
instruction
of
how
you
can
build
it
and
even
run
locally.
B
So
the
the
first
page
that
you
that
you
can
see
is
the
dashboard
that
shows
you,
the
trends
that
you
can
choose
in
the
timeline
of
your
own.
I
currently
didn't
run
any
traffic
in
the
past
five
minutes,
but,
as
you
can
see,
I
tried
it
a
bit
before
we
show
you
the
new
apis
that
we
never
the
system
never
saw.
We
have
existing
apis
hit
counts
for
a
guys
that
the
system
already
learned
and
also
you
can
only
select
apis.
B
Some
div
against
the
defined
api
specification.
So
as
soon
as
you
run
some
traffic
that
is
captured
by
api
clarity,
you
immediately
can
see
it
in
the
api
event
screen.
As
you
can
see
here,
we
have
the
time
and
the
method
of
the
http
the
path
and
some
other
attributes
that
you
can
find.
Also
in
in
the
drill
down
of
the
event,
we
also
set
up
with
some
filters
in
order
to
search
the
all
the
events
efficiently.
B
C
C
C
B
B
So
if
in
the
path
we
see,
for
example,
jpeg
image,
so
you
see
we
filter
that
out.
So
if
I
will
hide
this,
and
none
of
these
events
will
be
shown
so
that's
convenient
in
order
not
to
be
distracted
for
traffic
that
are
not
interested
in
only
traffic
that
we
learn
the
apis
of
your
application
from
also
an
important
part.
We
have.
C
B
In
your
cluster
and
external
traffic
towards
the
destinations
like
http
here,
for
example,
and
each
api,
we
create
an
automatic
entry
in
our
api
inventory
section.
B
So
these
are
the
apis
of
the
microservices,
these
actually
the
microservices
of
the
web
stock
chevros.
So
the
web
soft
shop
application
demo-
and
here
you
can
see
that
I
already
provided
some
of
the
open
api
specifications-
and
I
also
reviewed
some
reconstructed
specs,
but
just
to
show
you
how
it
is
done
in
real
time.
B
C
B
So,
let's
try
to
update
the
shipping
to
hit
the
shipping
and
micro
service.
Let's
try
to
also
edit
edit
some
payment
information
to
give
the
payment
information
and
sorry
the
payment
api
and
let's
complete
it
and
make
sure
that
we
generated
enough
traffic
here
and
so
now,
if
you
see
in
the
last
five
minutes
a
good.
C
B
B
B
B
A
A
B
B
And
in
order
not
we
couldn't
guess
it
correctly,
because
it's
up
to
the
user
to
decide
what
is
the
name
of
the
parameter.
So
we
can
select-
and
I
think
that
this
one
is
a
user
id,
for
example,
and
we
will
show
you
what
this
was
merged
from.
So
these
are
the
actual
calls
that
happened
and
we
learned.
C
C
B
B
And
we
can
see
what
is
combined
from
so
looks
good
as
well
here.
If,
for
some
reason
you
say
that
cards
here
undefined,
that's
not
actually
that
that
should
be
a
parameter,
so
you
can
also
click
on
it
and
say
hey.
This
is
my
cart
id.
That's,
not
unpaid,
undefined
and.
C
B
You
set
it
up,
we'll
say
that
this
this
will
be
merged,
and
you
can
also
merge
these
two
because
they
from
the
same
structure.
But
let's
do
it
for
all.
Only
this
one
and
you
see
that
it's
all
immediately
changed
to
cart
id
again.
You
can
say
no
sorry
that
that's
not
correct,
then
define
that
actually
how
it
should
be
and
we
restored
all
the
merged
entries.
B
C
B
B
C
B
C
B
And
the
once
the
spec
is
in
place,
I
can
go
back
and
you
can
see
that
now
the
reviewed
api
of
cards
now
also
have
a
reconstructed
spec
so
and
the
same
basically
with
the
external
apis.
So
here
I
have
http
bin
api,
so
yeah.
These
are
the
last
events
that
we
saw.
I
can
maybe
generate
some
traffic
using
http.
B
So
we're
just
calling
the
delay
api
for
two
seconds
and
just
delaying
my
call
and
I
executing
it
from
all
the
client
of
a
simple
curl.
Maybe
I
can
delay
it
for
one
second,
not
waste
the
time
and
and
yeah.
This
should
create
several
entries
and
that
we
should
see
them
immediately
in
the
run
time
events,
so
you
see
that
these
were
detected
and
if
I
click
on
them,
I
can
go
to
the
http
bin
spec
right
away.
B
So
let's
try
to
reconstruct
this
spec
as
well.
So
you
can
see
that
we
detected
the
parameter
here.
Let's
give
it
a
better
name
that
seconds
and
I
can
also
see
from
which
events
that
was
created,
so
one
in
two
seconds
said
that
I
ran,
and
these
are
the
correct
values
so
no
need
to
modify
here.
Yeah
so
looks
good.
B
I
can
improve
this
and
again
as
for
for
the
in-cluster
traffic,
I
also
have
my
swagger
and
open
api
specification
for
the
bin
8
bin
service,
the
external
service-
and
this
is
actually
not
going
to
the
swagger
editor.
This.
We
generate
these
files
in
api
clarity
service
in
your
cluster,
so
we
generate
these
files
and
then
we
access
it.
So
no
need
to
worry
again.
The
traffic
leaves
your
environments
so
yeah.
As
you
can
see,
we
detect
all
the
models
and
skills
and
what
else
I
think
might
be
interesting
for
you
yeah.
B
C
B
B
So
it
can
be
something
that,
like
in
in
this
case,
that
actually
we
see
here
tracing
headers
of
envoy
that
shouldn't
be
here
so
where
we
actually
needed
needs
still
to
ignore
these,
and
you
can
visualize
all
this
from
the
dashboard
again.
So
you
get
a
numbers
of
api
calls
and
volume
of
your
calls
in
your
cluster
and
you
can
you
can
click
on
the
latest
divs
in
your
cluster?
So
we
hope
that
we
have
something
more
interested
interesting
than
this.
B
That
it
was
defined
as
in
64
and
all
of
a
sudden,
it's
a
double.
It's
not
actually
that
big
of
a
deal,
but
as
you
as
you
see,
things
still
catch
a
drift,
and
this
is
the
method
basically
to
detect
the
shadow
apis.
So
if
this
the
api
is
completely
doesn't
exist,
for
example,
this
call
doesn't
exist
in
the
reconstructed
spec
and
or
in
the
provided
spec,
and
now
we
see
it
in
runtime,
and
so
that's
a
shadow
api
that
it
wasn't
documented
or
we
detected
deprecated
api.
A
B
Or
external
traffic
and
see
whether,
as
as
you
expected
in
the
open
api
specification,
okay,
I
think
that's
it.
C
Thank
you
very
much
alexey
for
the
great
live
demo.
Actually,
the
the
god
of
demo
was
with
us
today,
so
we're
fortunate
for
that.
So
let
me
share
my
screen
again.
C
So
a
a
new
report
from
a
ibm
security
x-force
has
found
that
the
two-thirds
of
cloud
breaches
can
be
traced
to
misconfigured
apis
from
the
report.
Apis
are
fast
becoming
the
technical
basis
for
both
b2b
and
b2c
business
models.
As
such,
where
api,
when
apis
are
developed
and
deployed,
there
is
a
really
no
way
to
estimate
all
the
possible
places
the
apis
are
going
to
get
you
to
go
in.
The
apis
are
going
to
get
used.
Apis
are
silently
but
rapidly
becoming.
C
One
of
the
most
critical
pieces
of
software
supply
chain
organization
are
now
one
vulnerability,
vulnerable
api
call
away
from
potential
major
breach,
so
two-thirds
according
to
ibm
of
the
of
the
breaches
are
related
to
apis,
and
you
know,
after
that
it
comes.
It
should
come
as
no
surprise
that
gartner
predicts
that
within
the
next
few
years,
api
abuse
will
move
from
an
infrequent
to
the
most
frequent
attack
vector
resulting
in
data
breaches
for
enterprise
web
applications.
C
So
we
started
all
this
in
order
to
be
able
to
use
it
in
our
secure
cn
offering
for
kubernetes
security
that
we
are.
We
are
working
on
and
like
said
here
in
the
slide,
knowing
the
api
spec
is
the
first
step
to
identifying
your
api
risk.
Given.
Given
the
api
spec,
one
can
also
run
fuzzing
tests
and
automatically
generate
the
client
and
server
codes.
The
spec
can
also
serve
as
a
good
documentation
for
future
future
usage.
C
We
are,
we
will
utilize
it
for
security
reasons,
but
the
others
can
do
other
things
with
it
so
going
now
into
road
map,
so
the
most
important
I
would
say,
two
row
roadmap
items
are
listed
here
on
the
left.
We
support
today
open
api
spec
version
two.
We
can
broaden
the
scope
to
open
api
spec
version,
three
graphql
and
grpc.
C
Currently
we
are
integrated
with
istio
and
envoy.
I
wish
we
should
add
more
integration
points
like
browsers,
postman,
api
gateways
and
others.
I
want
to
use
this
opportunity
and
call
out
for
the
community
co
to
cooperate
with
us.
42
crunch
that
are
also
behind
api
security,
dot,
io
and
api
metrics
that
are
doing
intelligent.
Api
monitoring
already
accepted
this
challenge
and
will
join
us
in
maintaining
api
clarity.
C
We
would
be
happy
to
see
many
more
of
you
collaborating
with
us
on
github,
so
github.com
api
clarity,
it's
easy,
and
now
I
I
think
that
we
are
down
for
questions,
so
I
already
saw
a
few
questions
in
the
chat
window,
so
the
the
first
questions
was
about
the
https
support,
so
you
know
https.
It
means
that
it's
encrypted,
so
it
sounds
like
a
an
easy
question,
so
it's
expected
that
we
will
say
that
we
are
not
supporting
it,
but
we
do
support
it
in
our
security
and
offering
there
we
can.
C
C
C
B
Can
I
mention
a
few
things?
So
first
thing
is
about
the
encryption
part,
so
if
you're
running
with
this
geo,
so
you
can
encrypt
everything
using
istio
and
if
everything
is
encrypted
using
istio,
you
will
still
see
that
because
and
voice
sends
the
parse
traffic
to
api
clarity.
So
you
can
also
do
it
with
istio
if
the
application
encrypts
the
traffic
and
not
and
void
that's
a
bit
harder.
We
are
thinking
about
about
solutions
that
involve
a
bpf
that
registers
on
receiving
send
maybe
k.
B
Yeah
it's
much
more
complicated
and
and
regarding
the
integrations,
I
think
that
if
we.
B
C
C
B
C
B
Yes,
so
envoy
treats
them
both
as
it's
the
same
parser,
so
it
depends
in
what
part
in
http
2,
but
basically
yeah.
It
still
will
still
get
the
attributes
that
are
relevant
for
the
rest,
part
and
the
json.
So
that's
maybe
a
bit
a
way
of
transfer,
but
all
the
data
that
we
need
is
still
there
and
then
we
can.
C
B
C
C
C
B
And
yeah-
maybe
something
that
I
can
add
so
in
the
review
we
saw
that
we
give
the
user
the
ability
to
modify
the
parameters
of
the
path
so
using
apis.
That's
what
we
support
in
the
ui,
but
actually,
if
you're
interested
within
the
swagger
integration,
or
so
we
suggest
you
a
review
that
has
the
full
content
of
it
and
you
can
return
us
some
something
that
you
want.
So
we
plan
to
extend
the
ui
also
to
be
able
to
review
the
inner
schemas
and
then
the
objects
and
the
types
so
not
only
the
paths.
B
A
Excellent,
yes,
the
slide
deck
will
be
shared
post
event.
If
y'all
would
wouldn't
mind,
resending
that
to
me
via
email.
That
way,
I
have
the
most
current
and
that
will
be
posted
with
the
reporting.
C
A
Think
there
were
some
great
questions
and
remember
to
hit
anyone
up
on
the
slack
channel
later,
if
you
have
any
other
questions,
and
all
of
this
will
be
up
on
the
website
later
on
today,.