►
From YouTube: Gloo Portal
Description
SoloCon 2022:
Gloo Portal
Speakers:
Chris Gaun
Director of Product Management, Solo.io
Jim Barton
Field Engineer, Solo.io
Abstract:
In this session, learn more about Gloo Portal from Solo.io's Director of Product, Chris Gaun, and Field Engineer, Jim Barton.
Track:
Edge and API gateway
A
Hello,
my
name
is
chris
gone,
I'm
the
head
of
product
management
here
at
solo
ao
in
this
session.
I
want
to
talk
about
glue
portal,
give
you
an
introduction
on
what
we've
done
with
portal
and
where
we're
going
with
it
first,
I
want
to
give
you
a
sense
of
why
you
need
a
developer
portal
and
an
api
gateway.
A
In
recent
times,
we've
been
moving
from
monolith.
Applications
to
microservices
with
that
has
has
come
a
cambrian
explosion
of
the
number
of
pods
and
resources
and
services
that
you
need
to
manage,
as
we
all
know
since
you're
here,
what
we've
been
doing
is
moving
those
services,
those
microservices
to
kubernetes
the
clear
winner
in
the
container
orchestration
platform.
A
What
we
want
to
do
now
is
now
that
they're
on
kubernetes
is
expose
them
to
the
outside
world.
How
do
we
do
that?
It's
through
ingress,
that's
the
basic
concept
of
using
tls
routing
to
all
these
different
services,
but
then
the
problem
is:
how
do
I
connect?
How
do
I
secure?
How
do
I
expose
things
that
are
external
to
kubernetes?
A
You
can't
do
that
with
some
basic
ingress,
and
that
is
where
an
api
gateway
comes
in.
It
provides
all
the
building
blocks
and
pieces
that
you
need
in
order
to
route
your
traffic
to
whether
it's
lambda
or
vms,
or
ec2s
or
kubernetes
services,
to
add
rate,
limiting
external
authorization
and
authentication
the
ability
to
add
filters
like
data
loss
prevention
and
web
application
firewalls.
These
are
all
packaged
pre-packaged
into
an
api
gateway
like
blue
edge.
A
So
now
that
you
have
this
basic
setup
with
an
api
gateway,
the
question
becomes:
how
do
I
manage
my
apis
and
expose
them
to
other
developer
teams,
partners
or
even
customers?
You
do
that
through
a
a
developer
portal.
This
allows
you
to
catalog
your
apis,
secure
them
document
them
and
share
them
within
or
outside
of
your
organization.
A
A
A
As
you
see
here,
you
could
actually
document
all
your
apis.
You
see
your
common
swagger
interface,
where
you
have
all
your
api
definitions,
you
could
go
test
out
your
apis.
You
could
build
again
a
developer
portal.
You
could
brand
it
to
your
organization
and
your
logos
here
on
this
slide.
You
see
some
of
the
benefits
of
glue
portal,
I'm
not
going
to
go
through
them
all.
A
One
top
benefit
is
actually
the
self-service
aspects,
the
ability
to
actually
put
as
a
team
member
of
a
development
team,
your
own
apis
into
the
portal.
Another
key
aspect
is
the
authentication
which
comes
out
in
the
box
and
then
another
one
that
we
hear
a
lot
from
customers
is
that
it's
built
using
cloud
native
apis.
So
what
do
I
mean
by
that?
A
Well,
it's
built
using
crds,
so
it
works
well
with
your
git
ops
process.
It
works
well
with
argo
cd.
It
works
obviously
well
with
kubernetes.
So
this
is
one
of
the
top
features.
A
lot
of
our
users
are
looking
for
when
they're
developing
a
portal
when
they
want
to
expose
their
apis
for
their
services
that
are
running
on
kubernetes.
A
A
B
B
Are
you
working
primarily
in
a
kubernetes
environment
and
do
you
value
cloud-native
ways
of
doing
things?
Do
you
leverage
popular
interface
standards
in
your
application
like
open,
api,
swagger,
grpc
or
graphql?
B
And
finally,
is
it
valuable
to
you
to
provide
an
easy
onboarding
experience
for
outside
developers
who
may
be
using
these
systems,
for
example,
things
like
packaging
up
docs,
with
your
with
your
apis,
maybe
usage
instructions,
an
execution
sandbox
where
you
can
provision
apis
and
that
sort
of
thing?
B
Well,
if
you
answered
yes
to
some
of
those
questions,
then
this
demonstration
is
for
you
because
we're
going
to
be
showing
you
glue
portal
and
it
is
an
environment
that
allows
you
to
do
exactly
that
to
catalog,
manage
and
publish
your
system
apis
in
a
cloud
native
fashion.
So
we
only
have
a
few
minutes.
So,
let's
get
started
here.
What
you're
seeing
on
the
screen
here
is
is
the
glue
portal
administrative
console.
B
We
really
see
three
sets
of
personas
who
use
glue
portal,
so
administrators
are
certainly
one
of
those,
maybe
people
who
are
doing
things
like,
let's
say
providing
user
access,
provisioning
access
for
certain
users
to
certain
to
certain
sets
of
apis.
B
That
sort
of
thing
there's
also
really
strong
support
for
developers
so
being
able
to
pre
to
package
your
api
products
and
publish
those
out
in
a
way
that
that
fits
very
hand
in
glove
with
with
cloud
native
ways
of
doing
things,
so
very
strong,
get
op
support
that
sort
of
thing
and
then
finally,
support
for
outside
development
teams
who
may
be
on
boarding
to
your
system
so
that
they
can,
they
can
have
an
execution
sandbox.
They
can
see
documentation
for
how
to
get
started.
B
They
can
provision
their
own
credentials
that
sort
of
thing.
So,
let's,
let's
get
started
and
take
a
look
at
this
and
the
way
I
want
to
walk
through
it
is
to
show
you
to
show
you
some
of
the
key
abstractions
that
you
need
when
you're
building
with
blue
portal.
So
we
already
have
everything
installed
here
in
a
gke
cluster
and
we
are
deploying
this
in
conjunction
with,
with
all
with
one
of
solo's
gateway
technologies,
the
glue
edge
technology.
B
Also,
you
can
you
can
do
these
sorts
of
things
with
with
the
glue
mesh
product
line
as
well.
So
let's
get
started
with
portal
and
to
do
that,
let's
take
a
look
at
one
of
the
key
abstractions.
This
is
really
a
foundational
level,
and
that
is
this
notion
of
an
api
dock,
and
so
an
api
dock
is
a
very
thin
wrapper
around
a
an
interface
specification.
Maybe
it's
open
api,
maybe
it's
grpc
or
something
like
that.
B
B
It's
just
you
know
the
kind
of
document
you
may
already
be
creating
if
you're
doing,
if
you're
publishing
apis
based
on
based
on
swagger
docs,
and
so
what
we're
going
to
do
is
we're
going
to
create
one
of
these
cloud
native
custom
resources,
an
api
dock,
and
you
can
see
it's
just
a
very
thin
wrapper
around
the
url
that
points
to
this
to
this
swagger
dock,
and
so
we
will
just
use
in
this
case
we'll
use
standard.
You
know,
kubernetes
tooling,
could
see
gel
to
to
apply
this
to
our
environment.
B
So
this
is
a
standard
custom
resource,
there's
no
extra
database
or
anything
like
that.
We
need
to.
We
need
to
apply
to
our
environment,
it's
just
stored
in
the
native
kubernetes
lcd
storage
system.
So
in
fact
we
can
go
look
here
in
canines
and
you
can
see
here's
our
here's,
our
api
dock,
and
we
can,
you
know
we
can
drill
into
that.
B
You
can
see
you
can
see
the
specification
for
what
we
for
what
we
put
out
there,
and
then
you
can
see
that
glue
edge,
went
off
and
and
parsed
that
document
and
actually
discovered
hey
here
are.
The
here
are
the
end
points
that
are
available
as
part
of
this,
this
pet
store
that
we
we
can
use
to
package
and
publish
our
api.
So
you
can
see
there
are
the
there
are
the
operations.
B
So
so
that's
a
that's
a
very
simple
component,
that's
kind
of
where
we
get
started
and
then
we're
going
to
add
to
that
something
called
an
api
product.
Now
api
products
are
really
interesting
because
they
give
us
a
way
to
assemble
these
raw
interface
components
into
packaged
products
that
you
might
want
to
present
as
a
unit
to
connect
to
an
external
team
of
developers,
whether
that's
external,
you
know
within
your
enterprise,
within
your
organization,
perhaps
to
a
partner
organization
or
even
to
the
general
public.
B
B
So
you
know
as
you
as
you
evolve
a
system
over
time,
you're
of
course,
going
to
go
through
different
versions,
and
you
want
to
be
able
to
publish
you
know
perhaps
version
two
to
one
set
of
users
and
version
three
could
be
available
to
say
some.
You
know
more
advanced
users
who
need
some
some
new
functionality
that
you've
created
here
and
so
there's
full
support
for
for
versioning
and
be
able
being
able
to
model
that
as
part
of
your
api
publication
process,
you
can
also
see
there
is
an
api
doc.
B
The
one
we
just
created,
that's
going
to
be
part
of
this
product.
Now
there
are
a
couple
of
interesting
things
we
could
do
here.
We
could
package
multiple
api
documents
into
the
same
product.
We
could
also
pick
and
choose
what
elements
we
want
to
publish
from
a
particular
api
doc
as
part
of
this
product.
So
let's
say
we
didn't
need
all
four
of
those
endpoints.
We
only
only
wanted
to
publish
two
of
them
out.
We
could
make
those
sorts
of
selections
right
here
as
well
as
again
aggregating
multiple
docs
into
one
cohesive
product.
B
B
So
we'll
put
that
we'll
put
that
product
out
there
and
then
finally,
before
we
actually
get
to
run
something
here,
we're
going
to
create
one
more
abstraction
and
that's
called
an
environment.
So
we
have
api
docs,
api
products
and
environments.
Those
are
the
first
three
we're
looking
at,
and
the
environment
is
meant
to
basically
define
a
computing
context
if
you
will
in
which
a
set
of
api
products
are
going
to
be
deployed.
So
it's
very
easy
to
think
about
this.
In
terms
of
you
know,
your
enterprise's
deployment
chain
probably
has
a
development
stage.
B
It
probably
has
a
staging
or
qa
stage
and-
and
it
may
have
some
others
in
there
and
then
it
probably
has
a
a
production
stage
right
and
so
you'll
have
be
managing
different
versions
of
the
products
with
different
versions
with
different
apis.
You
want
to
publish
out
potentially
at
each
link
in
that
chain,
and
so
that's
what
this
environment
abstraction
represents.
So
you
can
see
here
is
this:
is
the
dev
environment
that
we're
going
to
create
here?
B
We've
defined
a
domain
that
it's
going
to
watch
for
requests
on,
and
then
the
key
bits
right
here
are
here
are
the
products
that
we're
going
to
publish
in
this
in
this
dev
environment.
So
in
this
case
it's
just
one.
It's
this.
It's
this
pet
store
product
we've
created
but,
as
I
said,
you
could
put
a
whole
list
of
of
products
in
here
and
manage
them
within
a
single
portal.
So
let's
go
and
apply
this
environment
to
our
to
our
cluster.
B
Now
at
this
point,
we
actually
have
enough
in
place
that
we
can
do
something
something
so
what's
happened
underneath
the
covers
is
blue
portal
has
has
taken
these
these
custom
resources
and
has
built
a
virtual
service.
That's
part
of
the
underlying
blue
edge
api
gateway
in
in
this
configuration,
and
we
can
now
access
these,
so
we
can
go
in,
for
example,
and
hit
hit
the
the
pets
endpoint
and
you
can
see
if
we,
if
we
curl
that
end
point,
we
get
back.
Here's
our
you
know
we
get
a
200.
B
Okay
message
here
is
our
you
know
here
are
our
results.
We
have
two
pets
in
inventory
right
now:
a
dog
and
a
cat.
So
but
you'll
notice
there's
some
some.
You
know
we're
still
very
far
from
being
complete
right.
One
thing:
you'll
notice
is
there's
no
security
model
here
right,
we're
just
hitting
this
we're
just
hitting
this.
You
know
out
there
in
the
wild,
and
so
that's
obviously
not
not
a
sustainable
practice,
not
a
good
practice.
B
B
So,
let's,
let's,
let's
go
about
fixing
that
here
and
the
way
we'll
do
that
is,
we
will
add
in
something
called
a
portal
all
right,
and
so
this
is
a
portal
abstraction,
and
this
portal,
abstraction
you'll,
see
begins
to
add
some
user
interface
components
to
this
so
you'll
see
here
are
some
here.
Are
some
urls
you'll
see
those
you'll
see
those
pop
up
in
just
a
minute
when
we,
when
we
actually
show
you
the
the
generated
portal
interface,
you
can
see,
there's
also
a
place.
B
We
can,
we
can
apply
some
pages
here,
so
if
you
want
to
attach
documentation
store
that
with
your
with
your
other,
you
know
the
rest
of
your
api
componentry.
You
can.
You
can
do
that
right
here.
You
can
also
do
if
you
value
things
like
being
able
to
do
detailed
custom,
styling,
say
even
down
to
the
level
of
custom
css
and
that
sort
of
thing
you
can
also.
B
You
can
apply
that
here
and
so
you
can
see
we're
going
to
publish
this
portal
on
a
particular
domain
and
then
we've
identified
here
are
the
environments
we
want
to
publish
with
this
portal.
So
in
this
case
we
just
have
the
single
dev
environment
that
we're
going
to
publish
and
that's
what
we're
going
to
put
here,
but
you
can
put
multiple.
You
can
associate
multiple
environments
with
a
with
a
single
portal.
Okay,
so
let's
do
that
and
see
what
that
gives
us.
So,
let's,
let's
apply
the
portal,
so
that's
out
there!
B
Now
again
you
can
see.
This
is
just
a
you
know:
yaml
file,
it's
just
packaged
up
and
we
can
take
this
yaml.
We
can
store,
we
can
manage
it
via.
You
know,
via
a
git
ops
platform
right.
We
can
use
this
with
technologies
like
like
flux
and
like
argo,
cd
and
a
variety
of
others,
so
it
fits
very
nicely
with
your
git
ops
strategy
that
you
may
be
adopting
in
your
organization
now
before
we
actually
take
a
look
at
the
generated
portal
interface.
B
B
You
can
hook
this
up
to
your
external
idp
provider
like
like
an
octa
or
an
off
zero
or
a
key
cloak
or
whatever
you
whatever
you
happen
to
be
using,
but
in
this
case
we're
just
going
to
use
the
internal
mechanism,
which
you
probably
don't
want
to
do
in
production,
but
we've
defined
a
group
and
a
user
and
we've
already
applied
this.
In
fact,
you
can
see
if
you
take
a
look
at
our
administrative
console
here
you
go
to
access
control.
You
can
see.
We
have
a.
B
We
have
a
group
that
we've
built
we
have
a
set
of.
We
have
a
set
of
users,
we
have
a
single
user
that
we've
built
and
we've
provisioned
some
we've
provisioned
some
access
to
this.
For
for
these
users
right,
so
here's
the
this
particular
group
has
access
to
the
pet
store
portal,
which
is
the
one
we
just
created,
which
will
which
will
come
in
really
handy.
You
can
see
other
things
you
can
do
in
the
in
the
administrative
interface
as
well.
You
can
actually
interact
with
the
portal
abstraction.
B
You
can
do
everything
we've
done
through
the
yaml
so
far.
You
can
actually
do
inside
this
inside
this
administrative
interface.
If
you
want,
you
know
what
we
find
for
a
lot
of
our
for
a
lot
of
our
customers
is
that
they
really
prefer.
You
know
they're
very
strong
in
terms
of
wanting
to
be
able
to
use
native
kubernetes
tools
being
able
to
use,
get
off
strategies,
and
so
a
lot
of
times.
B
We
find
them
not
using
this
administrative
interface
as
much
as
as
you
might
expect,
depending
on
your
background,
but
it
is
certainly
there
and
you
can
do
everything
that
you
can
do
from
the
from
the
api
from
from
yaml
configuration.
You
can
also
do
here
in
this
in
this
ui
environment,
okay,
so
so
we
have
a
set
of
users
in
groups
set
up.
We
have
a
portal
configured
on
top
of
our
environment
and
our
api
dock
and
api
product,
and
now,
let's
take
a
look
at
what's
been
generated.
B
So
here
is
our
here
is
our
automatically
generated
portal
interface
literally,
you
know
we
didn't
build
any
of
this
from
a
from
a
ui
standpoint.
We
simply
specified
you
know
in
the
portal
abstraction
what
we
wanted
to
what
we
wanted
this
to
look
like,
and
so
and
here
we
are-
and
so
you
can
see-
here's
our
we're
logged
in
as
our
is
our
dev1
user,
and
we
can
take
a
look
at
the
apis
that
we
have.
We
have
provisioned
here.
You
can
see.
This
is
an
open
api
pet
store
product.
B
You
can
see
here
the
four
endpoints
that
are
available
now
once
again.
This
is
just
one
of
the
interface
standards
that
is
supported,
so
you
could
also
have
grpc
interfaces
here
very
soon,
you'll
be
able
to
have
graphql
interfaces
here.
So
all
of
the
major
interface
specification
technologies
that
are
that
are
commonly
in
use
today
are
supported
via
glue
portal.
B
So
so
here's
the
pet
store
product-
and
you
can-
you
can
see
here-
here's
some
operation
here,
here's
an
operation
that
we
can
perform,
and
so
we
can
try
this
out
and
we
execute
that
there,
no
no
parameters
required
for
this
one.
So
you
can
see
here
we
get
back
our
our
response
with
our
dog
and
our
cat
that
are
available
and-
and
so
that's
all
good,
so
here's
our
little
execution
sandbox.
Now,
let's
say
we
wanted
to
secure
this
api
in
some
way.
Maybe
we
want
to.
B
Maybe
we
want
to
require
the
api
itself
to
have
to
have
say,
be
protected
with
an
api
mechanism.
You
can
see
here
with
this
curl
command,
we're
using
there's
still
no
there's
still
no
security
on
the
interface
itself,
there's
security
to
get
into
the
portal,
but
not
on
the
actual
api.
So
maybe
we
want
to
secure
that.
Maybe
we
want
to
apply
some
rate
limiting
rules,
something
like
that.
So
let's
take
a
look
at
how
we
can
expand
on
what
we've
done.
B
So
far
to
make
that
happen
now
I'm
showing
you
here
some
code
that
allows
us
to
expand
on
the
environment,
abstraction
that
we
talked
about
before
and
so
we're
going
to
add
something
here
called
a
usage
plan
to
our
to
our
dev
environment,
and
so
this
is
something
that
first
of
all
we're
going
to
specify
an
off
policy
with
this
we're
going
to
specify
api
key
authorization
as
being
required.
B
We're
also
going
to
apply
rate
limiting
to
this
api
and
we're
going
to
limit
that
to
three
requests
per
minute
into
this
into
this
api.
Okay.
So
let's
go
ahead
and
apply
that
that's
the
wrong
one.
B
So
here
is
our
we've
modified
our
environment
and
let's,
let's
let's
come
out
of
here-
and
we
will-
we
will
log
back
in
all
right.
Let's
take
a
look
at
our
apis,
let's
go
in
here.
Let's,
let's
try
to
hit
this
api
now
without
without
authenticating,
and
what
you're
going
to
see
is
in
fact
we
get
back
an
unauthorized
error
right,
because
now
we've
specified
a
usage
plan
that
says:
hey.
You
have
to
have
an
api
key
provisioned
to
access
this
all
right.
So
so
what
can
we
do
about
that?
B
Well,
one
of
the
things
that
portal
allows
us
to
do
is
to
give
users
the
ability
to
provision
their
own
credentials
all
right.
So
let's
say
we
want
to
authorize
here
and
then
the
way
we're
going
to
do
that
is
first,
we'll
have
the
user,
they
can
go
in
and
they
can
build
their
own
or
they
can
provision
their
own
api
key
for
any
plan
that
they've
been
authorized
to
use.
B
So,
let's
copy
that,
let's
go
back
to
our
api,
we'll
authorize
all
right,
we'll
add
this
key,
and
now
we
should
be
able
to
do
this
and
everything
will
work
just
as
you
would
expect
now.
You'll
notice
here
the
command,
we're
issuing
is
something
different
right.
It
has
an
api
key
associated
with
it.
So
in
this
case
you
know
the
security
is
being
applied.
B
If
you
don't
have
this
key,
then
it's
going
to
fail
now
you
remember
the
one
other,
the
one
other
security
provision
we
made
here
was
to
apply
rate
limiting
to
this
interface.
So
if
we,
if
we
hit
this,
if
we
hit
this
this
interface
more
than
once,
let
me
go
in
here
and
just
put
a
minus.
I
switch
on
this,
so
we
can
see
the
code
we
get
back,
so
you
can
see
right
now
we're
getting
200
okays.
B
But
if
we
hit
this
more
than
three
times
in
the
same
minute,
you'll
see
we
begin
to
get
back.
429
too
many
request
errors,
and
we
also
get
this
header
that
says
that
envoy
is
in
fact
rate
limiting
our
our
request.
Okay,
so
that's
a
very
quick
tour
of
of
blue
portal.
I
hope
you've
found
it
interesting
and
enlightening,
and
now
chris
and
I
will
be
happy
to
take
your
questions.