►
Description
The Developer Portal for Istio by Solo.io provides the ability to catalog and expose running APIs in an Istio cluster and provides the ability to enable external auth to the services running in Istio
Try the Tutorial https://solo.io/blog/tutorial-external-authorization-of-service-requests-in-istio-service-mesh
Request a Trial https://lp.solo.io/lp-request-a-trial-general
Learn More https://www.solo.io/products/istio-developer-portal/
Question? https://slack.solo.io
A
So
why
is
this
something
you
might
be
interested
in?
Well,
a
lot
of
organizations
are
moving
toward
istio
to
help
with
managing
and
observing.
What's
going
on
in
the
internals
of
their
kubernetes
deployments,
istio
has
a
robust
feature
set
to
address
these
kinds
of
east-west
traffic
concerns,
in
fact
we're
huge
istio
fans
at
solo,
but
we're
also
experts
in
building
envoy-based
edge
gateways
like
our
glue
product.
So
we're
aware
that
while
enterprises
might
like
to
leverage
istio's
ingress
gateway
as
a
full
gateway
solution,
it's
not
full
featured
out
of
the
box.
A
That's
the
question
we'll
explore
in
this
tutorial,
specifically
we'll
explore
solo's
istio
developer
portal
and
how
you
can
use
it
to
configure
an
external
auth
server
to
manage
the
publication
of
api's
api
policies
and
client
identity.
So,
let's
start
with
some
prerequisites:
first,
we
assume
that
you've
walked
through
the
developer
portal
setup
guide.
A
So
we
can
take
a
look
at
that
here
and
you'll
notice.
There
are
actually
two
setup
documents
here:
one
for
glue
and
another
for
istio's
ingress
gateway,
so
glue
is
solo's
open
core
product
that
acts
as
a
dedicated
cloud
native
api
gateway
and
since
both
glue
and
istio
are
based
on
the
envoy
proxy.
The
istio
dev
portal
is
able
to
share
a
single
code
base
with
the
glue
dev
portal.
A
Let's
take
a
look
at
the
startup
guides
here,
so
you'll
notice
that
that
there
are
three
parts
to
this
guide:
we're
only
going
to
focus
on
the
first
two
here
and
then
we'll
be
building
out
some
features
after
we
after
we
walk
through
the
first
two
parts
of
this.
So
in
part,
one
we've
deployed
the
standard
pet
store
app
to
our
cluster
and
we've
created
an
api
document.
That's
based
on
the
open
api
schema
for
that
service.
So
take
a
look
at
take
a
look
at
vs
code.
A
Here,
here's
here's
what
we
have
for
the
api
document,
so
this
just
consumes
the
swagger
interface,
the
open
api
interface
for
the
pet
store
app,
and
it
exposes
four
endpoints
out
from
that
app.
We've
also,
then
put
those
together
into
an
api
product,
so
the
api
product
is
a
is
another
custom
resource
that
that
defines
things
like
routing
rules
for
the
for
the
service
and
how
to
get
to
it,
and
also
some
of
it
also
defines
some
of
the
policies
that
we'll
be
getting
to
later
in
this
exercise.
A
A
So
let's
go
back
to
vs
code
and
just
take
a
look
at
that
document,
so
you
can
see
there's
a
lot
of
there's
a
lot
of
custom,
styling
and
so
forth
that
you
can
do
here.
So
if
you'd
like
to
be
able
to
customize
this
interface,
to
have
say
your
company's
branding
to
have
documentation
to
have
to
have
custom
stylings,
that
sort
of
thing
you
can
define
all
of
this
in
this
in
this
portal
component
and
then
and
then
seo
dev
portal
will
actually
build
out
the
portal
interface
for
you.
So
that's
pretty
cool.
A
So,
let's
take
a
look,
so
we've
applied,
we've
applied
these
three
components.
Already:
we've
installed
the
pet
store
app,
and
so
let's
take
a
look
at
where
we
are
so
I'm
going
to
switch
over
here
to
the
to
the
admin
ui.
So
over
the
course
of
this
tutorial
we're
going
to
be
basically
wearing
two
hats.
The
first
hat
is
that
of
an
administrator
someone
who
has
who
has
set
up
who's,
actually
administering
the
details
of
this
portal,
setting
up
policies
creating
users
and
groups,
and
that
sort
of
thing.
A
A
Here's
the
swagger
pet
store
endpoints
that
are
available
and
we
could
customize
this.
We
could
you
know
we
could.
We
could
take
some
of
these
away
and
so
forth,
but
we'll
just
we'll
go
with
the
full
set
of
four
here.
There
are
also
some
plans
where
we'll
get
into
more
details
of
how
we
want
to
to
provision
policies
for
this
for
this
product,
what
portals
we've
assigned
it
to
so
you
can
see.
A
So,
in
addition
to
the
api
product,
there's
also
the
portal
configuration
itself,
so
you
can
see
some
of
the
the
custom
stylings,
the
the
logo,
the
the
favicon
that
we
put
together.
We
can.
We
can
even
do
things
like
custom,
css
stylings.
If
you
want
to
to
go
to
that
level
of
detail,
you
can
define
documentation
for
for
external
developers
who
are
onboarding
to
your
apis
and
that
sort
of
thing.
So
so
that's
what
we
have
so
far
now,
let's,
let's
switch
over
and
take
a
look
at
our
running
environment
here.
A
So
you
can
see
from
canines
here
that
we
have
the
pet
store
app
that
has
been
deployed,
and
then
you
can
see
a
number
of
pods
that
are
associated
with
the
dev
portal
itself.
So
here's
the
here's,
the
admin
server,
which
we've
just
been
taking
a
look
at
that
at
that
web
interface.
There's
the
core
dev
portal
component
itself,
which
actually
watches
the
kubernetes
crds
and
takes
action
based
on
changes
that
occur
there.
A
And
then
there
are
two
external
services:
there's
the
xda
service
which
handles
all
of
the
the
authorization
decisions,
and
so
we're
going
to
be
configuring.
This
here
momentarily
and
also
the
rate
limiter
service
that
we'll
be
talking
about
as
well
and
finally,
a
a
redis
backing
store
that
supports
the
rate
limiting
service.
A
A
So
now,
let's
curl
the
pet
store
interface,
that's
out
there,
and
what
we
will
see
is
that
it
works.
We
get
back
our
two
pets
we
have
in
our
database.
Here
we
have
a
dog
and
a
cat
and,
as
you
can
see,
we're
we're
hitting
this
service
anonymously
right,
and
we
can
do
this
as
often
as
we
want
to.
There
are
no
restrictions
on
the
interface
it's
just
sitting
out
there
ready
for
us
to
hit.
A
So
what
we
want
to
do
now
is
go
back
to
the
administrative
interface
and
we
want
to
do
a
few
things.
First
of
all,
let's
associate
our
portal
with
the
pet
store
api
that
we
want
to
publish
so
we'll
go
to
this
tab,
we'll
add
an
api
product
and
there's
only
one
at
this
point
for
us
to
choose
from
so
we'll
select
that
and
we'll
add
the
api.
A
So
now
the
portal
knows
which
which
api
to
publish
second
we're
going
to
establish
a
usage
plan
that
will
allow
access
to
the
api,
and
so
let's
go
to
the
api
product,
and
we
will
check
out
the
plans
here
you
can
see.
We
don't
have
anything
active
at
this
point
and
let's
just
create
something
that
whoever
has
access
to
this
plan.
A
Let's
call
it
the
unlimited
plan,
whoever
has
access
to
it,
can
basically
just
they
can
just
pound
on
this
interface
as
much
as
they
want
to
okay.
So
we
will
create
that
usage
plan,
and
now
we
need
to
allocate
some
to
find
some
users
and
bind
that
plan
to
them.
So,
let's
go
to
access
control,
we
will
create
a
user
and
we'll
just
call
it
user
one
give
it
a
super
sophisticated
password.
A
We
will
not
assign
it
to
a
group
at
this
point,
we'll
come
back
to
that
shortly,
but
we
will
assign
this
this
api
to
it.
We
will
also
assign
it
the
unlimited
plan
that
we
defined
and
we
will
associate
the
user
with
this
portal.
Okay,
so
we'll
create
that
user.
You
can
see
it
shows
up
and
now
that
we
have
a
usage
plan
and
we've
activated
that
if
we,
if
we
go
back
here-
and
we
try
to
hit
it
anonymously
again,
it's
like
no,
it's
not
going
to
let
that
happen.
A
So
we
turn
on
some
verbosity
and
you
can
see
that
in
fact
we're
getting
an
unauthorized,
401
unauthorized
error,
because
there
are
there's
now
a
usage
plan,
that's
activated
as
a
user
associated
with
it,
and
so
anonymous
access
is
no
longer
allowed.
Okay,
so
let's
go
and
take
a
first
look
at
the
portal
and
see
if
we
can
use
this
user
to
actually
access
the
portal.
So
let's
take
a
look
at
our
portal
interface
and
let's
log
in
as
our
user.
A
So
we're
now
logged
in
as
user
one.
We
can
take
a
look
at
the
apis
and
you
can
see
here's
the
pet
store
product
it
has
been.
It
is
available
to
our
user
and
if
we
try
to
access
this
right
now
without
authorizing
we're
going
to
get
we're
going
to
get
a
401
unauthorized,
just
like
we
did
with
anonymous
access.
A
A
So
you
can
see
no
restrictions
there,
okay!
Well,
so
let's
say
this
introduces
a
couple
of
problems
for
us
with
our
system
here.
So
the
first
problem
is:
let's
say
we
have
too
much
load
on
our
system,
so
some
of
these
external
developers,
like
user
one
here,
they're
banging
on
this
expensive
interface
that
goes
and
dumps
our
whole
database,
and
so
there
there
are
certain
users
that
we
need
to
restrict
to
to
lower
request
levels.
Okay,
so,
basically
a
rate
limiting
use
case.
A
And
second,
we
want
to
limit
the
administrative
burden
associated
with
onboarding
new
users.
We
don't
want
to
have
to
provision
detailed
permissions
every
time
we
create
a
new
user.
What
we'd
like
to
do
is
establish
user
groups
instead
and
assign
permissions
at
that
level.
So
for
a
new
user,
we
simply
add
them
to
the
appropriate
group
and
then
and
then
based
on
its
group
membership.
We
can
delegate
authors
that
authorization
decisions
to
the
external
auth
server,
which
then
understands
how
to
make
decisions
based
on
both
individual
users
or
or
group
membership.
A
A
So
let's
go
back
to
our
admin,
ui
we'll
go
to
our
api
product
and
in
that
api
product
we're
going
to
create
a
new
plan
and
we're
going
to
call
this
plan
the
limited
plan,
and
let's
restrict
that
to
something
much
less
like.
Let's
say
three
requests
per
minute,
and
so
now
that
usage
plan
is
available,
you
can
see
there
are
no
no
users
or
groups
associated
with
that.
At
this
point,
and
so
let's
go
and
create
that,
so
we
will
create
a
new
user.
We
will
call
this
user
user
two.
A
Let's
see
yep
that
password
should
work
and
we
won't
assign
to
a
group
at
this
point
because
we
don't
have
any.
We
also
we're
not
going
to
give
it
access
to
the
api
directly
again
we're
going
to
handle
that
through
group
membership,
and
so
let's
create
this
user
and
now
we're
going
to
create
a
group.
A
And
then
we'll
assign
a
user
to
that
group
and
then
we'll
at
the
group
level,
we'll
assign
the
api
we'll
assign
the
limited
usage
plan
and
we'll
also
associate
it
with
this
portal.
Okay,
so
once
we
create
that
group,
then
we
should
be
ready
to
go.
So
let's
go
back
to
the
portal
again
we're
changing
hats.
Here
we
have
our
administrator
hat
on
at
the
moment.
Now
we're
going
to
go
back
to
our
user
hat,
and
so,
let's
log
out
of
user
one
and
we're
going
to
log
back
in
with
our
new
user.
A
A
A
And
then,
when
we
try
out
this
interface,
what
we'll
see
is
that
it
works
just
like
expected.
Okay,
now,
one
key
difference,
because
this
is
this
user-
is
a
part
of
this
new
group
that
we
created
that
only
has
limited
request
access
to
the
api.
So
it
can
only
this
user
or
any
user
in
this
group
can
only
hit
this
api
three
times
per
minute,
and
then
we
should,
after
that
we
should
see
some
kind
of
error.
So
let's
go
back
over
here
to
to
our
terminal
and
let's
try
that
out.
A
So
we
have
our
user
two
api
key.
We
can
hit
it
a
couple
times.
Something
happened
there,
the
fourth
time
didn't
work,
and
so,
let's,
let's
take
a
look.
If
we
use
our
verbose
option,
you
can
see
that
would
get
a
429
error
that
there
were
too
many
requests,
and
you
can
also
see
this,
this
header
and
the
response
here
that
the
envoy
rate
limited
flag
is
set
to
true.
A
So
so
indeed,
we
have
set
this
up
where
we
have
both
individual
user
privileges
being
validated
by
the
external
off
service,
as
well
as
group
privileges
that
are
working
in
a
similar
way,
all
right.
So
what
have
we
accomplished
in
this
tutorial?
Well,
first,
we
use
the
istio
dev
portal
to
configure
the
istio
ingress
gateway
to
delegate
off
decisions
to
our
external
auth
servers.
Significantly,
we
did
this
using
standard,
kubernetes
objects
and
storing
them
using
standard
kubernetes
persistence
mechanisms.
A
Note
that
we
did
not
have
to
configure
an
external
database
to
manage
any
of
this.
Second,
we
configured
these
off
and
rate
limiting
policies
external
to
the
application
itself,
so
our
target
pet
store
application
that
we're
managing
access
to
doesn't
need
to
know
anything
about
these
policies
that
we've
applied
in
this
exercise.
A
Third,
we
used
the
dev
portal
user
and
group
abstractions
to
make
it
easier
for
administrators
to
efficiently
manage
these
authorization
policies.
And
finally,
we
produced
a
dynamically
generated
portal
that
allows
external
developers
to
provision
their
own
api
keys
and
also
provides
a
sandbox
to
test
them
out.
If
you'd,
like
more
information
on
istio
dev
portal,
I
invite
you
to
check
out
this
blog
post
from
our
cto.
That
goes
into
more
of
a
technical,
deep
dive
on
the
dev
portal.