►
From YouTube: 20181219 - API Management Working Group Meeting
Description
Presentation of proposal to enable API management on Istio.
A
A
What
I'm,
really
looking
for
here
is
creating
a
vendor,
neutral
minimally,
opinionated
way
of
handling
the
system
of
accepting
an
API
description,
along
with
API
policies
and
routes
into
the
system
and
and
allowing
isseo
to
respond
to
that
with
different
vendor
backends,
and
things
like
that
and
still
allowing
the
operator
to
control
the
low-level
policy
and
and
authentication
and
authorization
stuff.
So
let
me
get
into
that
then.
A
So
I
want
to
start
off
with
what
my
definition
an
API
is
because
I
think
there's
a
lot
of
definitions
in
this
case.
What
I'm
saying
is
it's
a
name
set
of
API
operations
which
are
basically
you
know
and
band
points
in
an
API?
So
it's
a
group
of
that
and
these
this
API
is
accessible
to
a
client
by
a
certain
set
of
credentials.
That
is
specific
to
a
a
group.
A
A
A
To
the
right
of
that,
you
see,
api
credentials
are
what
gives
access
to
the
api's,
and
I
put
in
client
application
I'm,
not
really
it's
not
enforced.
It's
not
really
a
thing
in
Sto.
It
won't
be
a
thing
in
this
view,
but
it's
it's
just
an
example
of
this
is
the
common
pattern
that
credential
belongs
to
an
application,
and
application
has
access
to
multiple
API,
but
you
can
drop
application
right
out
of
there.
Actually.
D
A
A
Okay,
so
we're
going
to
initially
work
on
supporting
two
different
API
specification.
One
is
open
api
with
some
extensions
so
that
we
can
read
the
information
out
of
the
open
api
and
create
the
necessary
structures
inside
the
video,
and
the
other
thing
would
be
to
provide
a
set
of
extensions
for
a
G
RPC
so
that
the
api's
could
be
specified
there
as
well.
So.
A
Everybody
may
or
may
not
be
familiar
with
open
api,
but
basically
in
a
nutshell,
it's
just
a
json
or
e
mo
specification.
It's
designed
for
both
human
and
machine
readable.
So
and
it's
it's
really
designed
around
restful
web
services.
It's
not
necessarily.
It
doesn't
have
to
be
restful
exactly,
but
it's
it
also
can't.
It
is
limited
in
scope.
A
So
here's
a
here's,
just
a
really
simple
example
of
the
hello
world.
You
can
see
it's
broken
down,
basically
into
some
basic
information
about
which
version
of
open
API.
It
is
the
information
about
the
spec
itself,
the
title
or
the
API
itself.
The
title
of
the
API,
the
expected
end
points
of
where
it's
going
to
be
coming
from
the
servers
would
be
mapped
to
hello
world,
and
then
you
can
see
it's
a
path.
It's
hello,
a
method,
get
the
operation
ID
and
it
basically
you
just
respond
with
a
string
and
on
the
right
there.
A
That's
specified
in
your
spec
to
some
sort
of
underlying
operation
that
a
an
adapter
that
and
handler
that's
been
created
inside
of
this
do,
and
that
is
so
right
now.
You
would
not
specify
the
how
the
policy
operates
itself
inside
of
the
API
specification,
just
that
it
should
be
applied,
and
what
would
happen,
then
is
the
rules
that
are
generated
when
this
is
ingested.
Would
map
saying
that
if
this
operation
is
called
call
these
policies
and
that
that
would
be
the
entirety
of
the
mapping
and
the
the
creation
of
these
policies?
A
A
A
Actually,
actually
I
take
that
back
in.
In
this
case,
that's
actually
two
different
things.
Sorry
I
misspoke,
so
the
the
one
above
is
actually
for
the
API
as
a
whole.
One
below
would
be
for
the
that
specific
path.
That's
Pacific
operation,
okay,
so
you
can.
You
can
declare
them
in
two
different
spots
CIC,
but
this
name
will
appear
somewhere
else.
I.
B
E
A
C
A
Or
not,
that
would
be
a
good
idea
how
much
how
much
of
a
language
we
should
bring
into
the
open
API?
Oh
yeah,
okay,
next
routing
routing
works.
Similarly,
basically
for
a
destination,
you
need
a
host
port
and
path,
so
those
can
be
specified,
as
re
I
should
say
at
the
top
of
the
servers.
So
we
want
to
be
able
to
map
to
a
gateway
because
we're
basically
creating
a
virtual
service,
so
the
Gateway
itself,
the
main
gateway,
should
be
already
created
by
the
operator.
A
C
A
A
We
so
we
don't
want,
we
don't
want
to
map
them
against
anything
that
already
exists
in
the
system
of
services,
because
well
I'll
touch
on
this
a
little
bit
later,
but
for
a
given
incoming
host
and
path
you
could
have
different
api's.
That
actually
applies
that,
depending
on
your
access,
depending
on
your
your
particular
credentials,
yeah.
E
A
C
A
Yeah,
so
there's
there's
two
ways
of
looking
at
it:
one
is
an
API.
Has
multiple
I
guess
versions
is
one
way
to
look
at
it
in
stage
ways
or
instantiate
I
yeah
right.
The
other
way
to
look
at
is
an
API.
Is
that
right?
So
in
in
Appaji
at
least,
we
had
the
idea
that
a
host
my
path
was
was
the
API
right
or
was
you
know
where
you're
going
to
on
the
API?
A
And
then
you
you
could
branch
off
of
that
based
on
your
credentials,
this
kind
of
inverts
that
a
little
bit
in
that
the
API
is,
is
more
than
the
host
and
the
path,
it's
also
the
credentials.
So
by
the
time
you
get
to
the
point
of
choosing
which
API
it
is
you've
already
chosen.
The
the
route
that
you're
going
to
on
the
back
end
and
so
I
can
have
I
can
have
an
API
that
has
like
a
gold
level
and
the
silver
level,
and
it's
the
same.
C
A
C
E
E
C
A
F
F
E
C
D
B
B
B
A
A
A
A
The
only
thing
that
I've
added
here
is
on
the
bottom
right
over
here.
You
can
see:
there's
a
X,
a
bank
policy,
where
you
can
specify
some
of
the
information
that
that
you
need
for
like,
for
the
jot
token,
to
get
the
issuer
and
the
J
works
URI,
which
is
something
that
we
support,
sto
directly
and
then
also
which
claims
coming
from
that
could
be
used
for
API
key
D
or
an
authorized.
The
authorized
set
of
API.
For
that
particular
token,.
A
E
Right
so
the
it
is
that
the
second
form
here
is
kind
of
a
superset
of
the
first
form
right,
if
you're
doing
jaw
off.
If
the
jaw
does
valid
you're
looking
for
a
claim
called
API
key
and
then
you're
doing
the
same
thing
you
do
if
it
was
an
API
key
to
see,
if
that
he
is
authorized
to
make
that
particular
API
call
right.
Yes,
yes,.
A
B
A
In
there,
okay,
yes,
okay,
all
right!
So
this
is
just
an
overview
of
kind
of
how
how
the
ingestion
works
right.
So
you
submit
your
open,
API
CR
or
some
JRPG
CR
into
the
API
server
that
gets
processed
by
Galli,
and
then
it
gets
spit
out
in
a
whole
bunch
of
different
configurations
for
HTTP
API,
specs
policy,
CRS
and
n
rules
right
that
end
up
in
mixer
and
pilot
and
get
processed
by
the
auth
policies
and
and
such.
A
So
so
what
happens?
Is
that
galley,
you
know
generates
some
of
these
entities
it
generates.
Virtual
service
is
authentication
policy,
some
sort
of
API
identification,
Handler
and
route
directives.
Now
that
API
identification
handlers
is
what
or
region
doesn't
generate
the
handler
it
may
have
the
endpoint
to
it
and
route
directives
and
we'll
see
that
in
a
minute
the
API
references
some
of
the
underlying
things
by
name
as
we
talked
about
so
for
authentication.
A
C
So
the
implication
here
in
that
flow
is
that
the
operator
is
creating
these
high-level
CRS
of
the
open,
API
spec
and
the
lower-level
stuff
that
is
consumed
by
mixer
and
pilot
do
not
necessarily
materialize
as
resources
and
communities
right.
So,
in
other
words,
you're
going
to
create
a
virtual
service.
But
that's
not
necessarily
by
creating
a
virtual
service
resource.
B
H
C
B
C
Correct
so
in
theory,
let's
say:
there's
a
bug
in
the
there's,
a
bug
in
the
transformation
logic,
and
you
could
do
some
objects
that
that
are
failing.
The
fact
that
you're,
exposing
it
into
the
API
server
makes
gives
up,
gives
a
place
for
SEO
to
report
status.
Hey
this
virtual
service
that
was
created
by
API
management
is
completed.
For
these
reasons
do.
C
Official
kubernetes
pattern
would
be
to
go
and
create
these
sub
resources.
These
derived
resources
in
the
API
server.
Okay,
the
problem
is,
then
they're,
first-class
resources,
the
user
can
go
and
luck
with
them,
delete
them
and
that
kind
of
stuff-
and-
and
it's
it's
a
it's-
it's
also
pollution,
the
certain
extent
right,
I,
the
user
does
not
want
to
deal
with
this
virtual
service.
He
just
wants
to
create
whether
the
the
CR
in
the
top
level
and
we're
polluting
their
space
with
this
these
derivative
stuff.
C
A
H
A
C
So
I
think
that
the
right
implementation
for
this
model
would
be
to
have
a
standalone
API
management
controller.
It
reads
the
API
management,
related
resources
and
just
writes
back
to
the
API
server,
the
underlying
stuff
and
that's
where
it
stops
and
then
galley
will
read
the
underlying
stuff
and
deliver
that
to
the
rest
of
the
system.
Okay,.
C
B
This
kind
of
thing
in
its
deal-
yes
well
I
mean
that's,
that's
a
kubernetes
thing
and
this
move
toward
operator
towards
CR
DS
+
operators
is
a
something
that's
going
on.
Industry-Wide.
It's
it's
relatively
nascent.
I
think
it's
all
really
come
about
in
the
last
year,
but
it's
also
a
huge
huge
deal.
We
should
talk
to
Tim
Hawken
about
best
practices,
he's
a
big
huge
advocate.
Well,.
A
C
I
was
just
thinking
about
that,
so
it
all
it
means
is
Gally
will
be
able
to
ingest
all
the
low-level
primitives,
including
the
HTTP,
API
spec
and
you'll,
be
able
to
pump
that
directly
through
an
MCP
port
as
input
to
Gally.
So
so
it's
it's
divorced
from
the
API
server.
What
is
tied
to
the
API
server
in
this
world
would
be
you
need
logic
to
read
your
high-level
CR
and
the
logic
to
push
the
lower-level
CR.
That
transformation
would
be
an
equipment
any
specific
component.
Okay,
you.
B
F
A
A
The
so,
basically
the
the
way
it's
going
to
happen,
then,
like
the
way
I'm
proposing
anyway,
is
that
the
API
is
what
we
basically
merge
down
by
host
into.
Essentially
what
is
a
virtual
service
to
target
toward
the
authentication,
and
then
the
final
API
operation
would
be
selected
from
the
list
of
authorized
api's
by
path.
So
what
that
really
means
is
that
for
any
given
host
you
can't
have
api's.
A
B
B
A
B
E
A
Question
right
so
again
that
goes
back
to
the
definition
of
an
API.
If
you
believe
the
definition
of
an
API
is
really
just
hosts
and
path,
then
this
it
doesn't
get
that
it's
actually
more
than
that,
and
that
allows
you
to
have
multiple
api's
that
share
hosts
and
paths,
but
have
actual
different
operations
to
them.
Right.
B
C
C
C
B
Yeah,
okay,
I
get
it
I,
get
it
I'm,
just
wondering.
If
there's
you
know
it's
the
name
API
it
will
people
if
people
will
find
that
confusing,
because
I
don't
think
that
commonly
I
yeah-
and
this
is
this
is
I
mean
anecdotally,
it's
not
the
first
thing,
I
think
I,
don't
know
who
else
other
people
who
haven't
talked
at
all?
If
you
want
to
say
how
you
feel
about
this,
does
this
feel
weird
or
does
this
feel
understandable?
I.
A
B
B
A
B
C
B
E
A
E
You
know
it's
the
spanner
API,
but
I
only
paid
for
slows
matter,
right
pay
for
fast
spanner.
So
if
this
is
just
distinguishing
like
kora,
it
might
be
confusing
to
the
end-user.
But
if
it's
distinguishing
it's
a
different
collection
of
things,
you
know
that's
a
different
story
right
because
it
could.
A
E
A
B
Possibly
I
mean
if
we
evaluate
something
that
would
allow
you
to,
you
know,
create
one
API
with
multiple
policies
say:
API
policy
we'd
have
to
call
it
and
let
you
choose
those
separately.
Maybe
we
end
up
with
a
more
complicated
design.
We
wouldn't
like
him,
I
can't
I
can't
say
no.
This
is
not
good
right.
Yeah.
B
Think
we
should
look
at
it
and
and
actually
look
at
a
couple
of
implementations.
Just
take
a
simple:
we
have
a
gold
and
we
have
a
silver
and
they
have
you
know
slightly
different
policies
or
they
have
different
services
and
policies.
Here's
here's
how
it
would
look
under
the
current
proposal.
If
we
change
proposal
to
have
a
new
thing,
call
that
I
don't
know
API
policy,
then
here's
how
it
would
look
and
then
fundamentally
just
look
at
what
the
what
the
config
would
look
like
and
what
the
differences
would
be.
B
C
C
A
The
nice
thing
about
doing
it,
the
other
way
that
you're
proposing
is
actually
it's
simpler.
As
you'll
see
here
it's.
This
is
basically
a
byproduct
of
the
way
doing
it
this
way.
So
we
have
some
sort
of
virtual
service
that
it
comes
into
as
a
host,
so
example
comm,
you
know
/hello,
we
get
the
the
claim
actually
not
Rock
clangs
would
just
get
requests
off
claims
or
the
API
key.
We
have
some
sort
of
verification
of
that
right,
and
that
gives
us
the
list
of
authorized
api's.
A
So
now
we
identify
which
API
it
is
that
we're
calling
we
set
that
API
that
sets
the
route
selection
based
on
you
know
the
the
extensions
that
I
said.
We
we
replace
the
route
based
on
that
and
then
allow
sto
to
go
ahead
and
do
its
routing.
At
that
point,
it's
a
regular
routing,
whatever
the
operator
is
already
set
further
for
that
post
port
path,.
A
E
A
Right
one
way
or
another
yeah,
it
has
to
be
supported
that
way
and
so
theoretically,
to
what
I'm
proposing
here
could
support
either
one.
If
we
go
the
other
direction,
we
really
are
locked
into
and
a
more
normalized
view
of
things.
But
let's
move
forward
so
again.
Here
we
have
a
request,
comes
in
we
the
the
credentials
right,
we
authorize
those
api's
and
then
we
select
an
API
and
that's
why
I
just.
A
B
A
Have
overlapping
hosting
paths
you
can
have
as
many
api's
accessed
as
many
api's
as
you
want.
They
just
goes
that
that
set
of
api's
has
to
be
distinguishable
by
hosting
paths
which
which
api
it
is
that
you're
going
to
actually
get
okay,
so
you're.
Basically,
what
it
does
your
credentials
say
which
potential
api's
you
can
hit,
then
we
select
based
on
hosting
path,
good.