►
From YouTube: #DevOpsSpeakeasy at #kongsummit22 with Tyler Reynolds
Description
On API Security
A
A
B
Absolutely
I
think
it.
You
know
the
Genesis
of
it
right
is
getting
an
accurate
inventory
of
every
API
exposed
to
the
internet,
as
well
as
understanding
your
internal
API
sprawl
and
third-party
apis.
They
may
be
integrated
into
your
applications
right
so
most
organizations.
If
you
were
to
ask
them
today
how
many
apis
they
have
they.
If
you
ask
three
different
people,
you
might
get
three
different
answers
right
right.
You
know
you
ask
the
the
owner
of
Kong.
B
He
or
she
would
have
a
very
good
understanding
of
the
API
schooling
through
Kong,
but
the
truth
of
the
matter
today
is
with
Legacy
applications.
Api
gateways
with
you
know,
10
15
years
of
tech,
debt
that
are
on
premise
still
there's
just
very
little
visibility
into
all
of
those.
Let
alone
is
the
documentation
accurate.
What
kind
of
authentication
is
in
place?
How
that
API?
Is
there
sensitive
data
flowing
through
it?
So
first
it's
about
getting
that
accurate
inventory
from
there.
B
B
A
That
that
makes
sense,
of
course,
and
then,
when
I,
do
this
inventory
and
I
found
all
those
apis
and
then
I'm
going
to
bring
them
into
the
fold
and
make
sure
that
I
manage
them
correctly
with
Khan.
That
at
least
takes
the
headache
of
like
on
like
just
apis
that
were
forgotten
and
out
there
and
probably
exposing
vulnerable
code,
because
they
buy
definition
Legacy
and
abandon
right.
So
this
is
kind
of
why
it
took
care
of
now.
How
do
I
deal
with
other
aspects?
A
B
Absolutely
I
would
say
the
the
existing
Solutions
today
out
there
that
are
trying
to
address
this
are
really
looking
at
just
the
edge
or
the
edge
plus
one,
but
the
truth
is
Right.
An
edge.
Api
call
may
look
like
normal
so
to
the
subsequent
API
calls
really
understanding
how
Edge
apis
talk
to
internal
apis,
all
the
way
to
the
egress
right,
the
third
party,
API
or
back-end
database.
B
Once
you
start
to
build
models
based
off
of
the
roles
and
permissions
of
the
users,
all
sorts
of
outliers
and
you
can
identify
API
abuse
that
way
so
core
the
kind
of
traceable's
thesis
as
a
company
is
that
distributed
tracing
is
actually
the
best
way
to
gain
that
into
invisibility
and
model.
The
behavior.
A
That
makes
sense,
and
especially
considering
that
I
probably
already
have
tracing
like
in
the
in
the
in
the
part
of
my
observability
efforts
tracing
it
one
of
the
pillars
I
already
have-
maybe
probably
hopefully
you
all
have
already
tracing
done
with
maybe
agents.
Maybe
some
other
tools
that
are
a
part
of
my
observability
solution.
Now
can
I
use
that
in
order
to
add
this
aspect
on
top
of
performance,
reliability
and
other
observability
aspects.
B
So
the
answer
is
yes,
and
no,
so
if
you
look
at
actually
the
open,
Telemetry
specs,
it
doesn't
give
you
visibility
into
full
request
response
studies
there.
Unfortunately,
you
have
to
kind
of
enhance
unopen
Telemetry,
which
is
what
we
did
with
our
in-app
instrumentation
or
leverage
Technologies
like
ebpf
to
gain
that
visibility.
We
also
have
ways
to
deploy
out
of
band
entirely,
so
you
don't
need
to
leverage
that
end-to-end
traceability
component.
A
That
makes
sense,
but
it
means
more
overhead
from
one
of
my
knowledge
of
observability.
One
of
the
aspects
that
people
kind
of
care
about
is
what
is
the
overhead
of
instrumentation,
and
this
is
one
of
the
reasons
to
open
Telemetry
exist
when
they
say
like
hey,
you
deploy
One
agent
and
it
serves
all
your
observability
purposes.
So
I
would
like
to
leverage
my
existing
instrumentation
in
order
to
gain
more
from
it,
including
security.
So
how
do
I
go
about
that.
B
Yeah
without
getting
into
the
all
the
Nuance
of
our
deployment
options,
all
of
our
customers
start
off
with
a
deployment
option
that
adds
zero
latency.
So
VPC
mirroring
pod
level.
Demon
set
level
mirroring
in
a
kubernetes
application
where
it
takes
15
minutes
to
get
started
and
give
your
customers
that
initial
wind
around
Edge
API
abuse,
Edge
API
Discovery
go
in
and
automatically
reverse
engineer
the
open,
API
specs
over
time
as
we
gain
our
customers
stress.