Kong APISecOps ROSA and Kong Konnect in the Red Hat Openshift, 31 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Part 6/8 - Operations: 8-Part APISecOps Tutorial ROSA and Kong Konnect in the Red Hat Openshift

Description

APISecOps - Insomnia, Kong Konnect, Tekton - on ROSA

Part 6 of 8 Kong Partner Engineering's APISecOps Tutorial ROSA and Kong Konnect in the Red Hat Openshift Ecosystem: Operations.

In part 6 we continue to step 3 of our DevOps procedures, moving into governance and operations pipelines.

Follow along in GitHub: https://github.com/Kong/kong-apisecops-redhat#introduction

3. Governance Review and Publish API to Konnect-Sandbox Gateway Environment
Publish API to Sandbox Gateway Env

This step is for the Governance and Operations Personas

Now that PR is open on the apiops-gateway gitea repo, the sandbox pipeline can be executed. This pipeline will:

Execute standard OAS linting.
Execute custom governance linting rules.
Create the deck config from the apispec.
Add the mocking plugin to the apispec.
Deck sync to the Konnect Control Plane.

Once this Pipeline has run, navigate to the apiops-gateway gitea repo, and approve the pr opened on the sandbox branch.

Validation

Now that the API spec has been synced/published to the Konnect control plane you can validate via Insomnia that the gateway is exposing the API's correctly.

For the sandbox environment, keep in mind the mocking plugin was used so all data being return is not hitting an actual backend service. This was done intentionally to showcase how even in the case of APIops we can support external teams to testdrive new or updating APIs while the development teams build out the backend service.

Open the disputes design document in Insomnia.
In the bottom right corner select Generate Request Collection. This will drop you into the Debug Tab where you can execute API Requests.
Add the Konnect-Sandbox and Konnect-Dev Environment Details inorder to properly reach the API Gateways.
In the top left tab select the dropdown menu where it says OpenAPI env sandbox:8080
Select Manage Environments
Create a new Sub-Environment, Konnect-Sandbox
Paste in the konnect sandbox details, located in the ansible/demo_facts.json file.

Find all the resources you need in our self-paced demo on GitHub: https://github.com/Kong/kong-apisecops-redhat#introduction

A

Okay, so in this video we can see that the first pipeline that disputes API, spec pipeline has just finished and all the tasks were successful. So let's go ahead and see what the output was I'm going to go up to giti and I'm, going to change over to the API Ops Gateway repo, and we can see that we have a pull request.

A

Open uh disputes, API version, 1.1.0 cool, got one commit in there and let's take a look at the files that have been changed, so we can see that we just opened up PR and the only thing in this PR is the API spec for the disputes microservice, and we can in fact see that it also does have a new commits. So that's great make sure we're not crazy okay. So, but at this point we still haven't any, we haven't uh done any governance, validation or uh you know any of the operations access.

A

So this API spec has not been deployed to the connect sandbox runtime group, which is the objective of our second pipeline.

A

So if we go to step three, if you're, following along with the git repo, is where we're going to do the governance review and actually publish this API to the connect, sandbox, Gateway environment, slash runtime group, what's going to happen in this pipeline is the following: it's this pipeline is called API, op, sandbox, more or less. What's going to happen is we're going to fetch the security Repository, we're still going to do our standard linting we're also going to do our custom governance. Linting is going to be done in there.

A

We then need to take that spec and start the conversion into what connect can understand. So that's a deck. So this this is the third step is convert this into a deck configuration convert the apis back to a deck, we're going to actually do some updates to the deck. So we're going to add the mocking plug-in so that we don't actually have a formal back end for where a microservice is deployed and then we're going to execute deck.

A

Sync and deck sync is where we we publish the deck configuration up to connect and then it uh you know and then we'll be able to access the microservices or I'll, be able to access the Gateway service, and that's what's gonna happen.

A

Okay, so in order to execute the second pipeline, go ahead and copy this uh command rate, this pipeline run command down here and we'll navigate back to our terminal and go ahead and run it.

A

Paste that in and let's go.

A

Okay, so that was created, let's go navigate up to the openshift console and see what's going on, so this pipeline is located in the apiops Gateway namespace. We can see, we've got pipeline, this pipeline run, it's called API Gateway sandbox, and it's currently running. So it's fetching the repository. It's actually doing both linting tasks at the same time. You know we don't need, it doesn't need to be linear. We can do some stuff in parallel uh and then we've got the generation task we actually have because we're on connect three.

A

We actually have to do a debt conversion from uh version two to version three. So that's the objective of this task, adding the mark and public plugin doing some additional prep work and syncing it up to connect.

A

So it's almost done so we'll just go ahead and let this finish.

A

Great now, it's updating the pr.

A

Ok Okay, so if we navigate back up to the git repository what we should see the pr still going to be open, but we can see there's more file changes. So let's go see what those are. So now you can see this was the original spec we uh that we submitted in the first PR and then it was updated with all right. This is our deck configuration.

A

This is actually what we synced up into connect and down. Here we have the mocking plug-in. It has been enabled, and you can see- we've actually also inserted the API spec as well great, um so we're gonna go ahead and close this PR ize. Let me back or let's go ahead and approve it so I'll, just close those create a merge, commits delete the branch create the merge, commit lovely, that's great. Now we're actually going to navigate into connect and go see what happened.

A

A

Okay, so defaults and sandbox for us are synonymous, so we're going to click on the default runtime group and we're actually going to go and look at Gateway services. So now you can see we have a Gateway service. Then the host is sandbox because we don't actually have a back end. So we made something up: let's go ahead and look at our routes and we have two routes in there. So the deck took our apis back, which had two endpoints two rest endpoints defined and converted them into two routes respectively.

A

One four to retrieve that list and one to retrieve a particular dispute.

A

If we look at the plugins, we can see that we've also got more plugins. We've got the mock and plug-in is configured on the Gateway service and then we've got key authentication required on the route.

A

So what we can do now is navigate into insomnia and see if we can hit this Gateway first. In order to do that, we need some facts, so open up your demo facts file and grab the Kong sandbox Json data and then navigate into insomnia and in the bottom right of insomnia.

A

I want you to select, generate request, collection and that will actually deposit you into the debug tab, but we need to set up our environments in insomnia, so in the top left, where it says open, API, sandbox, 8080 I want you to select that drop down and navigate into manage environments and we're just going to blow away this current environment. We're going to if you double click on the title, we're just going to change this. To we'll call it connect sandbox.

A

And we're gonna change out these variables for the ones that we have in our demo. Facts.

A

And then I'm actually going to duplicate this and we're going to do connective at the same time. So we want to come back in here here. Dev I need to go, grab those facts so I'm going to grab, you can now call them. Dev ones see those and paste them paste them in as well.

A

Okay, close that so make sure you've got in the for an environment, make sure you've got connect. Sandbox selected select. This first request get disputes and we should be able to well. Let's take a look at there's. Nobody. uh If you look at the header, you can see it's deposited the key. We need the connect key for Jane and consumer, so we can go ahead and send this and you see we're getting data back. But what is this data?

A

This is actually the data defined from the mocking plugin, so we had two examples defined in the API spec I'm, going to go over to the side so for the disputes path. Where we retrieve the list, you can see in the examples section, we actually created a list, and this is the data being returned by the mocking plugin right there same thing. If we go to the next endpoint, it's also got the header set, there's nobody, because it's a get request and this data. What is this data same thing?

A

If we go back to our API spec, we did set an example, and that is the data being returned.

A

So that's it for this video. So just just to summarize what we've done in this third step, we executed the second pipeline that did the governance review. So actually there was a review custom review of that API spec and then it published it to the connect sandbox runtime group and what is really cool is we actually were able to Leverage The mocking plug-in from connects, and so we didn't have a formal. uh We don't have a formal micro service running in kubernetes for the sandbox environment.

A

At the moment in the next video we'll go ahead and see how we can promote this execute a pipeline that will promote Our, Deck configuration and API spec up to the dev runtime group. I will see you up there.