solo.io Webinars, 15 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: What's New in Gloo API Gateway 1.5

Description

Gloo is a next generation API gateway built on Envoy Proxy designed to facilitate and secure application traffic at the edge.

Download the presentation
https://speakerdeck.com/soloio/whats-new-in-gloo-api-gateway-version-1-dot-5

In this webinar we will cover the latest 1.5 release
* Enhanced Multi-Cluster Failover in Gloo Federation
* Traffic Routing and Route Table Enhancements
* More Config Options for Gloo, Envoy, and a Dry-Run Validation API
* Security Improvements for External Authentication
* Improvements for Configuring and Enforcing Rate Limits
* Enhanced AWS Lambda Integration
* Developer and Operator Experience enhancements

Learn More:
https://www.solo.io/products/gloo
https://www.solo.io/blog/new-gloo-1-5/
https://www.solo.io/blog/updated-developer-portal-for-gloo-and-istio/
https://slack.solo.io

A

Hello: everyone thanks all for joining our latest webinar on the glue api gateway in this session, we're going to cover the latest enhancements in the 1.5 release a couple of housekeeping items. This session is being recorded so we'll send out the recording and the slides by by tomorrow, at the latest, everyone who's registered um and you're free to free to share that with your colleagues, we will be doing questions handling questions for the session, so please go ahead and type them into the q a window or the chat window.

A

As we go along, um you know, we've got. We got some slides for you today, as well as a couple of demos and then what we'll do is we'll answer those questions at the very end and we'll kind of so keep keep entering them and as we go for today, my name is betty jannat. You all have probably heard me on uh previous webinars. uh I run marketing here at solo and today we are joined by two of our leads from the engineering team.

A

We have kevin derose for glue api gateway and marco schmidt, who leads the development for the developer portal.

A

And to kick off a little bit about solo, we build api infrastructure to help handle the application network from the edge to the service mesh from the edge with glue gateway. That also includes federation and a developer portal from service mesh for service mesh hub and then to extend the application network with webassembly hub and today we're going to focus specifically on glue and why glue? Why do we need this?

A

um As we look at the migration from monolithic application architecture to microservices, the network between the services becomes even more critical, so uh you know instead of having one mega code base, we now have you know, potentially hundreds or thousands of little services and they're all connected and how they talk and communicate with each other is through um the apis and whether the apis are to expose them expose the services to each other, so they can communicate or expose them to the outside world, so that um people or other systems um outside of your environment can access those access.

A

Your um applications. Now, once you do that the question new questions arise, and you know how do you manage those apis? How do you enforce security as well as get observability into what's happening within the traffic and those connections?

A

That's really the purpose. Behind the glue glue, api gateway and ingus controller, it's it's a next generation gateway, and it's built with envoy proxy specifically to handle the communication at the edge. The communication coming in from outside of your environment envoy proxy is a popular cloud native proxy. That's been built for uh that's popular with distributed environments.

A

um This is uh we and the way that we have built it is that so it can be highly uh performant and scalable, or the data plane with envoy is separated from the control plane so that you can scale them independently, based on the needs of the application, it is designed to route traffic into a variety of application services, whether they be monoliths, microservices or serverless, make making it ideal to help incrementally mike modernize, your environment, to more cloud-native architecture, and this works on cloud and on-premise environments.

A

Glue is available open source and enterprise. The as you can see here, this the items in the light blue are in the are the enterprise functionality.

A

The open source open source glue has lots of robust features from networking and custom security capabilities that you can work on and then from an enterprise side. We add additional functionality for security and management, specifically to help in scaling out the environment across multiple clusters. Multiple environments add more enterprise, security integrations to things like authentication systems and also have like developer portal access to expose apis externally.

A

And glue is used across many different companies specifically to handle their edge communication from you know: small startups to large enterprises to help them modernize their environment.

A

And with that, I'd like to hand it over to kevin who's, going to give a little deeper dive into what's new, with the latest release.

B

Sure, thanks betty for the introduction um kevin here very excited to have so many of you joining us today, um so for what's new in glue, um so many things we're really just covering a highlight here: we've done tons of new feature work using experience, improvements, enhancements and some bug fixes as well, but some of the highlights here we can talk about them and then we'll do a quick demo um so glue first off uh glue federation updates for multi-cluster failover glue federation built on top of glue to run multiple clusters and multi glue and we've added some enhancements there with related to multi-cluster fill over and dns, which we'll talk about later.

B

We have traffic routing and route table enhancements, so our route table api, which we have you know created to help separate uh like routing configuration from you, know virtual service owners and allow maybe platform teams to control the routing to their individual services without having to control. um I see a question coming in. We just talk about those at the end, uh so it'll separate your platform, team's routing configuration from like any glue. Admins um we've added some enhancements there to support more flexible route table.

B

Matchers so before you had restrictions on the kinds of prefix matchers, and now you can do things with query and method. Matchers talk about that further. We have expanded configuration options in glue and envoy some validation, api enhancements, so handling lists uh large lists of proposed resources, much better, so user experience improvements as well security enhancements to external auth. We have added new features like access, token validation, where you do only partial legs of the oidc flow.

B

It improves some security there with respect to the cookies and id tokens returned um automated some routing developer portal, which uh mark o'shea, will talk about and some developer portal single sign-on and customization options as well jump to the next slide, great. So for glue federation. um This again, this is multi bill. You know product built on top of glue, multi-cluster multi-glue, some of the new improvements here, our dns resolution for failover to end points.

B

We have home chart values for proxy config secrets for downstream ssl, optional, node ports, a better bootstrap demo, detect and register on register clusters. Over here on the left. You can see our little diagram of glue federation and how it might work. So here we have two clusters: a cluster on the left here with one glue installation cluster on the right with another glue installation um each running. You know the envoys ingress.

B

If, for whatever reason, service, foo and cluster one failed health checks, you could do failover to service food in another cluster um with glue federation.

B

uh So the this is the one that we'll be demoing as well. I know it's not a lot of text here, but uh we've we've added new feature uh functionality to glue for uh more flexible grpc to json transcoding, so you're behind the scenes. After behind your api gateway behind glue, you might want to run a bunch of grpc microservices but then expose that outside the cluster as an http rest service.

B

We've had similar functionality uh inglewood before, but it was very, it was inflexible. It didn't allow a lot of customization options, so we've we've created a more flexible way of doing uh something similar uh we've it exposed the you know the more raw envoy api. uh The demonstration demo later will make this a little bit clearer exactly how this works.

B

And then, like we had mentioned before, we have some route table enhancements, so route tables again separate the virtual service and actual routing config. So you can have glue admins control, the virtual service, while you know application developers and owners can own the routes to their actual applications again prior you had to have the prefix matchers match all the way and you couldn't have anything other than a prefix matcher like naked or raw as a parent of a route table, but we've added support for complex matches, so you can do headers quality parameters and methods.

B

Any children will have to have the superset of the parents, headers, query, parameters or methods, as well as some improvements to reporting errors on route tables, user experience.

B

B

uh Another thing: a bigger change for glue, is we've added. The new rate limit, config crd, so glue has had rate limiting uh similar to x-stop uh for a while. Now um before you had to define all of your rate limit settings uh configuration inline on the settings resource. So if and as well, you also have to define them in line on your virtual services.

B

We had similar problems, or you know. A similar problem we want to tackle in the past is with external authentication and the auth config crd. We did a very similar thing here with the rate limit, config crd. So now you can configure your rate limits in a single crd and then reference them from your virtual services. um This provides flexibility for reusing config. It allows you to sort of templatize config, which should improve the user experience of deploying glue and operationalize it much more easily.

B

And then for the validation api, we had a couple of improvements here so, for example, list handling allowing you to propose a you know: a long list of resources, rather than one at a time and validate them all together, as well as uh supporting drive runs. So when you hit the validation service, it'll do some internal caching, and then your next proposed resource might have applied the resource in memory, but we allow for dry runs to control that behavior as well as uh returning.

B

You know the if the, if you propose a list of resources or not a list of resources to our validation api. This is for validating config, that you would propose, like virtual services, route tables gateways to to glue to make sure that they are valid before you apply them to your cluster.

B

We can take those and translate them and return the proxy that would have been generated, which can be useful for for diffing between you know in ci, cd setups that are built into the validation api, um as well as for user experience, supporting email, admission requests as well, which will be a little more human, readable and familiar if you're, using kubernetes.

B

uh And with that, we can jump into a quick demo I'll take over the screen share and we can show you a little bit about the grpc to json transcoding.

C

B

So can everyone see my screen here? I believe so. We've got this demo terminal fantastic. So here I've got a couple of files here. I've got it completely. You know empty naked.

B

The first thing we're going to do is set up a kind cluster, so uh this is what we're going to do just moving this out of the way, uh so we're going to create a new kind, cluster kind, being kubernetes and docker if you're not familiar to create a local cluster kind of, like mini cube, uh I'm just adding these extra settings to expose these ports uh onto the local host, so we can hit these later at the end of the demo. This will make a little more sense.

B

This is just um boilerplate that makes uh easier to run glue and kind on a local machine. It's really just a demo. So with that we'll create the cluster demo again we're just exposing ports, 31 500 and 32 500. If I remember correctly to localhost.

B

And then from here we can go ahead and install glue and we'll look at the bookstore service. So this is the grpc service we're going to be working with um and exposing as a rest api locally. uh Even though it's a grp service itself.

B

So there we have our kubernetes cluster live I'll, stop using shorthand cubesatl get pods.

B

We can see that my kubernetes contacts is set up properly, we've installed, kubernetes they've got the controller manager core dns and the like uh so from here, we'll install the gateway um so glue, ctl, install gateway, we're installing version 1.5 we're showing off new functionality added in glue 1.5 and similarly I'll show you the values. These are some helm. Values overrides for this particular for this.

B

Installation, so these helm values when we take a look at these are, are really just going to match the cluster configuration that we had for kind itself. We created the kind cluster and exposed ports. um These are used to make sure that the services that expose our our ingress match those ports.

B

Well, I see so it finished. So if we were doing pods and glue system, we should see that we have our envoy gateway proxy, the gateway glue itself serving xds config and discovery uh discovering upstreams for us. So the values that I installed with here just tell us to do a node port service type on the on the envoy and to use the same ports that we uh defined in kind to expose them on localhost, just demo setup.

B

You wouldn't do this in a real environment, and so the effect of this is that, if you were to get the service, um it makes sure that the gateway proxy service envoy is exposed on those ports instead of just picking any arbitrary, open ones. um So, moving from there we've got our cluster set up. We've installed glue.

B

Now we can take a look at the bookstore grpc service.

B

So here in the bookstore we have I'm going to remove the descriptors. This was not cleaned up from prior.

B

So here the the relevant things are: let's start with the uh the bookstore proto. This is the api that our grpc service is implementing.

B

So nothing too complex. Here um we have our our grp service. With you know, rpcs we can list shelves get the response, which is just a list of shelves, create shelves. It's just a library, a bookstore.

B

The the important or relevant thing here is that we're taking advantage of the google api uh http transcoding annotations in our proto, so here we're defining uh when I, when I make this grpc call, and I want to map uh an http column this way and then envoy can take we'll be able to take care of this with glue in 1.5.

B

So for here we're saying if someone were making an http rest call with the path dash shelves will return the list shelves response, which is just the list of shelves and then similarly, if we want to create a shelf, if the, if someone posts, makes an http post request on the path shelf, then take the request body and put it uh like under shelf into a shelf.

B

um Similarly, we can take a look briefly at the uh the server code, but here it's really quite simple: um we implement the bookstore server. We implement. You know list shelves create shelf. um This is just again standard grpc service. So what we need to do here to expose this as a rest, api in glue is, we need to uh generate proto-descriptors.

B

That envoy can then use uh to decode uh http calls and then turn them into the appropriate grpc information. So we've got built into here um and I believe main.go are. We have our go generate. We can describe generate our protodescriptors using this call, so here we're going to uh create the descriptors proto. You know dot pv the binary for decoding those http rest calls so the the command that we need to do I'll just run this real quickly and I'll. Explain what it's doing so.

B

First, we're going to change into temp directory and clone protobuf and google apis. These are the uh these are necessary source for generating the correct protobuf um and then we're going to export the location of where these are stored and then change directories back to where we are and run go generate. So we're really just doing some setup running go generate.

B

This is specific to the demo, but we just need to generate this descriptor's file this. This set created this descriptors directory and there's this descriptor's protobuf, and this is the binary that we need to provide for envoy.

B

uh So again, we've we've cloned the protobuf directory the google apis directory and then set the locations here and then run go generate from the current directory, where we are right now and just go generate, and this proto-c command that took use of google produce home protobuf home, including the source information from these repos that we cloned and then we're outputting it as these protobuf descriptors. This this is going to turn into binary. We can send to envoy.

B

So another thing that we have here is these are descriptors for the service, but we need to actually deploy the service to our cluster. So if we want to take a look at bookstore.yaml, this is just a simple deployment service that deploys the bookstore the grpc service.

B

Nothing too fancy here just applying this. This is the source code for the service that we're going to be applying.

B

So, just as a reminder, we've, you know now applied the service, so we should see we still have glue installed. If we look in default, we should now see the bookstore. Similarly, because we have glue's discovery service running, we should now have an upstream discovered for that uh service.

B

System, so we now have the bookstore service, where this was created. 28 seconds ago, when I deployed the bookstore service now we can apply moving back down we're going to actually route to the service, so the steps we've looked at the source code generated a scripter for doing the trans transcoding from grpc to rest, we've installed glue, we've got the bookstore upstream running, so now we just need to create a way to route to it.

B

So first we can apply the virtual service and let's take a look at what this is simply this virtual service, we're just taking requests at foodexample.com, matching everything and sending it to the bookstore. We're not doing anything fancy here.

B

uh So the only other thing we need to do now is update the gateway so to enable the this grpc transcoding in the gateway. This is what we're going to be applying uh the only real changes here. Are these so here we're going to apply options for the jrpc jstron transcoder, which was added in glue 1.5, we're working with the main.bookstore server package and then uh of this bookstore service, uh and then we need to include pro descriptor bin. So this is the binary for the pro descriptor.

B

uh This will be very long and I'll we're about to get this and fill this in and that's all we need to do um so. Let's, let's do that, but if, when it's very long- and we could do this as a file instead, so to get that binary, we need to, uh let's see go to the bookstore again. The binary is is in this file that we generate from descriptors with proto-c. So if I want to take a look at this, we can look at the file and put it into base64.

B

This would just be binary. Very very big, like we might have seen before, um begins with the same couple: characters crt, I'm not gonna keep scrolling up. um Instead, we can just put it on our clipboard.

B

And update the uh the gateway, so here we have, this is the configuration we want to add we're just going to fill in the rest of this from the from my clipboard.

B

And now, if we just apply, qctl apply the gateway.

B

Then we should be in business, we have configured our gateway to do the grpc transcoding we've configured our virtual service to route to an upstream, that's been discovered, we've applied the bookstore, um so we should be able to route now.

B

If we want to get a list of shelves we're looking here, we can make a request to food.example.com matching our virtual service at localhost. Localhost is working because we've set up this port forwarding on 31500 will be installed, glue and set up kind. uh So now it knows how to handle this rest of quest to our grpc service.

B

Similarly, if we wanted to add a shelf, we could uh then provide the post request uh with the cropper body and we've added a new book shelf uh to our bookshelf, and then we can retrieve it. So here's a little quick little demo of the the advanced europa c transcoding. This gives you a lot more flexibility um than the sort of auto discovering that we had before in glue and allows you to do more flexible things like uh you know.

B

Instead of providing this is the body you can grab it from query parameters and and all the other options that the google http transcoding, uh you know protobuf options allow with that. I can hand it off to marco.

C

B

Oh, we are scared betty. Can you share your screen again.

D

Oh, I think I think I can share the slides on my side. The.

A

Ones that would be great marco yeah.

D

All right thanks, kevin.

C

And yeah thanks.

D

Everyone for joining I'm going to share my screen. Can you see the screen.

A

Yes looks great.

C

D

Perfect, so I'm going to talk about the updates that we applied to the developer portal for glue, and so just a quick history here. The first version of the developer portal that we released was at the end of march and since then, we've added a lot of new features. The first version was mainly focused on publishing open api specifications to a portal application that we could automatically generate for you and expose some simple customizations to adapt the look and feel of the portal to your organizational needs.

D

With the most recent version of the developer portal that we released together with 1.5, we made several changes to both of these aspects.

D

So on one hand, we enhance the api to give you uh more freedom in deciding how you want to structure the apis that you want to expose to your users and also which policies you want to apply to the apis that you expose to whoever wants to consume them, and also we expanded the possibilities of how you can customize the look and feel of the portals that your users will log into to consume. Your apis in particular, and we'll see this like in a demo shortly.

D

I want to just uh go through the the highlights here. um We now allow users to provide their own css style sheets to customize the styling of the portal, and we also added support for adding dynamic pages to the portal. We, the portal, already supported, adding static, markdown content.

D

What we did um with the latest release is allowing you to embed your own application into the portal and to access the context of the portal to display, whatever you know, to implement whatever behavior you need for your particular use case, and another core new feature is that we now allow you to integrate with your openid connect provider, to authenticate users to the portal.

D

So, in the first iteration of the portal, we relied on you creating your users as custom resources in your cluster and we implemented a basic authentication mechanism so that you could match some credentials to a particular crd. Now. This is okay for some simple use cases, but most organizations have a dedicated service that manages the identities and most likely that service implements oauth 2.0 and it's very likely that the service is also an open id connect identity provider.

D

So what we did is we built the integration point so that you can use the identity stored in your opinion, connected entity provider to authenticate users in your portal and yeah. So this was the quick overview of the new features.

D

One thing I also want to mention is that, while the first iteration of developer portal required you to write the gateway configuration that matches the open api definitions that you upload into the portal, the new developer portal that was released with group, one five is now able to automatically generate the virtual services rate image configurations: authentication configuration for your apis, exposing a much simpler and higher level api. So you do not need to maintain the resources yourself.

D

You have a single source of truth, which is the document that describes your api itself and you can drive both the gateway configuration and the documentation that you expose to your end. Users with this single object, so you have a single source of truth for both these um information.

D

Okay, so oops. Sorry, without further ado, now I'm going to jump right into the demo and a lot of these this will make more sense.

D

I have a cluster running and I have a blue enterprise installed, so you can see that I have all the pods are running. So the developer portal is an enterprise only feature, and it consists. I have the developer portal installed here as well.

D

It consists of two pods, so one the dev portal pod is just the controller that processes the the resources um that make up the configure the developer portal and also implements the web server that serves the portal applications.

D

The admin server is what packs the admin ui and, as you can see here like for this, like simple demo, I just port forwarded the admin server pod, and this is what the landing page of the ui looks like now. I want to start by showing how the new api allows greater flexibility and new features uh for you when you want to expose your apis. So the starting point for an api is an api dock and an api dock is a concept you might be familiar with.

D

If you use the first version of the developer portal, it's just an open api specification that describes your service.

C

D

Have some files here that I can ready to use? So I also want to mention that I have uh a simple service deployed to my default namespace, so it's pet store service that we use for a lot of demos, and here I'm going to upload the openh api specification that describes that service.

D

So I can upload it into the ui and basically start building the catalog of all the services that you have running in your back end, and you can see that the system was able to parse the open api certificate. Specification derive information from it, so you can see the different operations, the paths and the methods associated with with these operations.

D

Now an api dock is a description of the structure of a service. What is missing from an open api dock and a piece of information you might want to provide separately is where should? Where does the service live? Where do you want to route the traffic to, and you could have the same definition of an api dock?

D

You could have an api definition and but you want to send the service the traffic to a service in the development environment in one case, but you want to send the same traffic uh to a production service in your production environment.

D

So you have this one-to-many relationship between back-ends and api definitions, so a missing piece, the second piece that we need to actually generate the configuration and complete the api definition is what we call a route. So a route is really just a routing destination for traffic. So here you can see that I'm going to add a simple route to my headstore service.

D

uh You could do traffic splits, you can do header manipulations there. There are different advanced configurations, but for our use case we just want to send basically to to represent our kubernetes service.

D

So now that I have both of these objects in place, I can create what we call an api product and an api product is the central object that drives both that can be published to portal and that drives the configuration of your glue api gateway. So I'm going to call this api product.

C

D

I need to fill.

C

D

The required fields I need to associate the domain with the api product. This is the domain. Users will be able to query it. So I provisioned some dns records here that that map to my blue gateway proxy.

D

You can upload an image we'll see later that this will be shown in the portal ui, and then you can select the operations that you want to expose on your api product. So this is a level of interaction between what your actual apis are and what you want to expose to your consumers.

D

I have only one api dock here, so I can only choose between operations on that one api dock, but if I had more than one, I could basically just choose the operations that I want to be exposed in this api product. So let's say that I want to only select read operations so the to get endpoints. I can select only those I'm going to create an api product and.

D

Now you can see that all the information that I've inputted is available here and what I need to do is I need to specify the route that that is going to apply to this api product. You can specify a default route for the whole object or you can specify different routes for different operations in this case, I'm going to keep it simple and just set the default route.

D

Now that I have all objects, you can see that the status is green and we have our api definition now, as I mentioned earlier, we can use this object to actually generate configuration for the glue gateway, so you can see that I don't have any virtual services and if I flip this switch here, this will instruct the developer portal to actually generate a routing configuration for the gateway.

D

So now, if I come to this screen, you can see that the developer portal generated a virtual service for my domain, with all the operations that I defined in my api product, and so we basically we're able to ensure that uh all the routing rules are in place to route to my service, based on my service definition and some simple uh customization that I can apply to this api product object now.

D

This is only one part of what the developer portal does so generate a configuration for glue, exposing this higher level api. I want also to show how, like the new portal features that I mentioned earlier. So to that end, I'm going to create a pet store portal and I need to provide a domain here as well. This is the domain users will reach.

D

The api will will reach to open the portal. um I can provide some customizing information like I can customize the background. I can customize the logo. You might be familiar with this, but I'm going to fill this information out just for whoever is seeing this for the first time- and here I can decide to publish my to publish my api to the portal and I'm just going to click through here, and here we go so now. You.

C

If we oops, I need to, I don't think.

D

Yes, I need to enable ingress to my router, so similarly, we can generate a virtual service to expose your portal application.

D

So now that I flip the switch, we can see that we have a portal um virtual service and, if I go to this address, we should be able to see that the dev portal was gener able to generate this web application dynamically. Using all the information that I provided now, the in the first iteration we were on the developer portal. We were only able to set some primer in secondary colors and just the logo and fab icon in the background.

D

So what I mentioned earlier is that now we allow you to provide your own css. So let's say that, for example, you want to modify the color of the title of the portal, so what I can do is I can inspect the page to find what css class is associated with that element, and by opening this advanced portal customization dialog, I can provide some custom css for that element. So, for example, let's just say that I I want to make the color of the text orange. So if I save this, I come back here.

D

You'll see that the text is now orange and you can using this mechanism. You can really modify any element present on the portal. You can provide your own style sheet to change. Not only do you know the color, but also the spacing, and you know whatever you can control your css, which is a lot.

D

So the other new feature I mentioned is the ability to define um dynamic pages. So what we had in the first version of the developer portal was the ability to define static content. So I'm going to create a static page here, and this is basically just markdown, so you can define your page and then add some markdown content.

C

Let's keep the typos and.

D

This would generate an additional section in the ui, where you can visualize, whatever content you define in the static page, which could be uh some instructions to get started or whatever other documentation you want to provide, and the new feature that was released with the latest version is the ability to actually define dynamic pages and, as I said, dynamic pages are really applications that we render inside the portal.

D

So to this end, I wrote a very simple html file, which consists of just a body and a script that accesses the context of the portal to display the currently logged in user and the api product that the user has access to.

D

So I'm going to upload this file, you can also just provide a url to the to the entry point of your application, so it doesn't have to be just a simple uh html file. It can really be. You know a react app and you just have to provide the address of the index html file. That is an entry point to that app.

D

C

I'm going to.

D

Information here dynamic page- and hopefully yes- it it's available now, I'm not logged in so this will show nothing right now, um because the user is not logged in, but this is just to show that we're able to display that that page and now, once once we're will be able to log in, I can show you that we can show that information associated with the user and what the user has access to. So this leads me to the next feature that I want to show, which is the oidc authentication for the portal.

D

So, as I mentioned, we can integrate the server and we can do that by providing some information. So I'm going to use google as an identity provider, so I have set up the developer portal as a client for our solo. I o application. uh Sorry a solo, I o organization, so I'm going to use google as an issuer. I have a client id here that I registered with google.

D

I I have a client secret that I have provisioned here in the cluster, so you can see that we have a portal or idc secret. This contains the client secret that the developer portal is going to use to authenticate with the google open id connect identity provider. So my secret is in the default namespace. The key that stores the data is client secrets.

D

I need to provide the prefix that will be used by google to call back to the portal. In this case it is just a url of our portal and I need to tell the system which claim, in the id token, that we will receive when a user successfully logs in contains uh the groups that the user is a member of that's how we model the permissions and, as I'll, show you in a second so to keep it simple.

D

I I'm just going to use the hosted domain name, which is, will always be solo.I o in my case and as um as the the element in the id token, the claim, in the d token, that contains the group membership information most likely in a real world use case. You'll have an actual groups claim which consists of a list of groups.

D

So once I have enabled this configuration, I need to actually go and create a second half of what we need to uh allow or you see, access, which is the name which is a no idc group. So we model permissions at the group level in the system and then we create a mapping between the id token and the group. So I'm going to you.

C

Call this whatever solo users.

D

And I need to provide the name of the group as it will appear in the id token. So on the portal page we configured which token to inspect for the group membership information, and here we need to specify what the name of the group as it appears. The token will be so whenever we receive an id token, which has a hosted domain of which a value of solo, I o. We will consider that id token part of this um of this of this uh you know group, so we give the group access to our api.

D

We don't have any usage plans I'll show that shortly. If I have time and we're going to give the group access to our portal and now once everything is in place, we should be ready to go. So if I click on the login button here, I can select to log in with open id connect and you see I'm redirected to the open id connect provider, so google, in this case I need to input my credentials and I'm using two factor authentication.

D

So I need to use my phone to allow myself to log in and, as you can see now, I am logged into the portal and if I come back to the dynamic page.

C

Let me refresh okay, this is, I would have expected this to.

D

Actually show the information- okay, I don't know what the why that didn't refresh immediately, but now you can see that the dynamic page of the script that I created here has actually access to the current user and to the apis that this user has access to. This is just to show how you can use information that are in the portal context in your own application to implement whatever behavior you want.

D

So if I have enough time, I think I might have a minute. I want to show another feature real quick, so I haven't really showed how you can really use the api. So you remember that when you enable the switch here oops we created a virtual service and if I try to curl the domain for api, you can see that we actually get back a response from our service. So in most cases you will not want to have your service just publicly exposed, but you want to secure it.

D

So we have this concept that we introduced with the new api of a usage plan and a usage plan is a set of it's. Basically, an authentication policy and a rate limit policy, so you can create a usage plan in this case, we're using api keys as an authentication mechanism and we're going to define a rate limit of three requests per minute for users of this basic plan. You can have multiple access plans on this portal, so now access will be secured.

D

So if I oops, if I try to create api again, you'll see that uh the access is now um I'm getting a 403 error because I'm not logged in. So what can I do as a user to provision credentials for this api? So first as an administrator, I need to update the group, so so it has access to the basic plan we just created and now once I am, I have that permission.

D

I can access the authentication section of my profile and I can request an api key for the basic plan for the pet store application. So the system is able to automatically generate a configuration so that this api key is valid.

D

And if I now go to my api, which is available here in the api section of my portal- and I well first, let's show again that if I try it out, you will get a for an unauthorized error and if I use my api key here to and send it along with the request, you'll see that now I get the 200 and after three requests two three on the fourth one. I get a 429 error, because I've been rate limited according to the usage plan that is linked to my user, so just to recap.

D

So what I showed here is how you can configure open8d connect to as a source of identity informations for users for the developer portal. I showed how you can customize the look and feel of your portal using custom, css, implement custom behavior using dynamic pages and how you can add, authentication and rate limit policies to your apis via the usage plan. Abstraction, and this is really everything I have so with that. I'm I'm happy to hand it back to betty for the qa.

A

Yeah, marco, could you actually just show that last slide um and then we have a couple of questions here, specifically um following your demo, um could you have multiple oidc providers integrated into the portal flow, or is it just one.

D

So it is one per portal, so each portal application could use a different one, but currently you can have only one for a portal application.

A

Great um and then there was um do we support import api uh in an open api format or swagger. How do you define the catalog categories for the apis.

D

So we support open api specification open api as a format for the specification of your api. So you can import your open api documents into the system and those become the basically your api catalog, and then you can choose how to expose those apis to the api products. You could have a one-to-one mapping. So if you just want to expose a whole open api document, you can just select only that one or you could merge two open api documents together, but we already support importing your open api definitions in the system.

D

um As I showed in the beginning, I can. I can show what the open api document that I uploaded looks like. So you can see it's a json, formatted open api specification, so it's it's a standard format and we can just import it in the system and the system will be able to interpret it. I hope this answers. The question.

A

Yeah, if there, if you need more clarification, please go ahead and type it into the chatter q. A um there was a question here, on rate limiting. um You know, we have basic rate limiting available in open source and then rate limiting in the enterprise edition as well kevin. Could you explain a little bit on the difference in how users can use rate limiting in those different editions.

B

In open source and enterprise sure so in open source, we expose the the envoy rate limit filter, which allows you to configure envoy to look towards any grpc service that implements the envoy rate limit api to make rate limiting decisions.

B

So the the simple explanation there is that in open source, you can provide your own implementation of the onboard grp service service and then use that with glue, um so in enterprise, the the add-on there is that we have our own implementation of the jrbc onboard rate limit service that has a functionality built in with the xerods and inline config.

B

You know very much so based on the the envoy implementation, but with add-ons on top for like weights rules where we're doing some new work right now with respect to handling sets, rather than great limit trees for a configuration, um but basically either you can use our implementation and provide your own. um It's enterprise versus open source.

A

And we had some recent um in the recent release. We had some enhancements um for rate limiting as well right.

B

Yes, that's correct with respect to the rate limit, crds.

A

Great and looks like one more question and another question here on: how does the api product object work with crds.

D

So yeah, that's that's a good question. Something I forgot to mention is all the objects that I um that I just demoed uh are kubernetes crds. So well, here, there's a bunch of them, but if you look at the dev portal ones, so users routes portals groups, api products, api docs. All of these are crds, so everything you see you saw me doing through a ui. You can actually do declaratively via yaml.

D

So if I try to look for api products, you can see that the api project is just defined via the ui is an actual crd.

D

So um the spec part is what you would specify if you wanted to write this on the command line- and you can see this. This contains all the information that I um that I set through the ui. So the source of the api is an api dock and these are the operations that I selected. This is the default route for the service.

D

This is some display information. These are the domains, the usage plans, so everything in the system is modeled as a crd, so you can describe your whole developer portal through yaml files that you can integrate in your github's workflow and basically provision all these resources without ever using the admin dashboard like I just did.

A

And that actually is one of the things when you look at how glue and you know the portal and glue federation, um the various capabilities is that we've architected around to be kubernetes native and be driven by crd um crds versus um you know some of the and using onboard proxy as the proxy inside of the gateway compare and that's a point of comparison against kind of many other. If you look at the landscape of you know: api management, vendors.

A

So one is you know, cloud native, so looking at you know, being kubernetes native using kubernetes architecture and some of the things that marco just talked about on how to drive configurations and designed to um handle distributed environments in a very um highly performant and scalable way. um So hopefully, that I saw some questions um asking about, like you know, differences between glue to like other api management providers. So that's at a high level.

A

um Those are kind of the big points um and then, if you have further further questions on that um hit us up on slack, just join uh slack.solo io and I think um it's it's it's a better kind of one-on-one discussion based on the use cases and the application environments you're trying to set up.

A

So we are just about out of time. So I want to thank kevin and marco for today's presentation and the demos for the folks that joined today. Thank you for joining. We have some links here, so you can go, learn more about glue, glue, open source and enterprise. If you're interested in getting involved in the open source site, we have a link to the repo there join the community, the slack community.

A

We've got lots of other end users in there, as well as our engineers, in their answering questions and links to the blog post, to get the full list of functionality that we released in the 1.5 release.

A

And if you would like to get hands-on with glue on october 29th, we are hosting a live online workshop, it'll be done all virtual, but we have um environments set up and then you'll actually be able to go through many of these um workflows, on routing security etc. For glue, we've got uh space is limited, but we still have some more seats available for um we're doing one session in european time and one session um for uh us time like pacific time 10 a.m, and with that we will see you all next time.

A

Thank you very much for joining.

A