Kong / APISecOps ROSA and Kong Konnect in the Red Hat Openshift

APISecOps - Insomnia, Kong Konnect, Tekton - on ROSA

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

In part 8 we wrap up this tutorial we search for, test and clean up documentation in Service Hub.

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

Cleanup
Kongratulations on completing the workshop! Now its time to delete the infrastructure you’ve created in order to work through the material.

Delete Konnect Gateways

Run the unistall playbook to tear down the konnect gateways deployed on the cluster:

Delete ROSA Cluster

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

APISecOps - Insomnia, Kong Konnect, Tekton - on ROSA

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

In part 1, we focus on an overview of Design, Governance and Centralization and introduce APISecOps.

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

Introduction
APISecOps stands for API design, security, and operations. Here at Kong APISecOps centers around four core fundamentals:

Centralization - Centralize API Management to a single control plane. Irrespective of cloud provider, or platform, all APIs can be managed from the same control plane.

Governance - A governance team should be able to easily customize API linting for security concerns and quickly validate.

API Design First - Development Teams should design and document the API upfront to validate they are up-to-date with current governance requirements, and accurate documentation.

GitOps - The API Spec, supporting documentation, governance, and API administration should all be handled via gitops best practices for speed, resilience, and reliablity in the process.

The objective of this demo is to showcase how to streamline Kong API management with the above APISecOps best practices in mind with Kong in the Red Hat Openshift Ecosystem. We will step through the responsibilities of the three personas, Development, Governance and Operations Teams, and the automation of these personas with Openshift Pipelines - Red Hat’s cloud-native CI/CD solution.

Development Team - The responsiblity of the Development Team is to Design the API in Insomnia Desktop Application upfront taking into account both the product requirements and governance requirements. With the inso cli tooling, the team can also lint the spec before committing the spec to source control.

Governance Team - The responsibility of the Governance Team is to build out custom security rules that align with the organizations standards. These rules are then executed during the CI/CD pipeline to evaluate if new or updating APIs comply.

Operations Team - The operations team will have tasks in the CI/CD pipeline to convert the APISpec to a kong deck configuration file (inso cli), validate that the deck meets their operational requirements, and sync the deck configuration (deck cli) to the Konnect control plane.

These three activities as shown in the diagram above will be automated end-2-end through gitops and CI/CD best practices.

Infrastructure
Konnect

Two Runtime Groups will be either created or at least checked that it exists - Default, and Dev.

Each runtime group will be provisioned 1 runtime instance (also referred to as a Gateway, Dataplane, or Proxy), each one will be in their own namespace, kong-sandbox, and kong-dev. These Gateways are exposed via loadbalancers, and are where API Consumers will call the protected backend services.

Openshift Pipelines/Tekton

The three pipelines to be executed will be in the namespaces disputes-apispec and apiops-gateway. The separation between namespaces is to demonstrate how pipelines belonging to different personas (Dev Teams vs. Governance and API Operator teams) can be managed in a more secure fashion.

Gitea (Self-hosted Git service)

Gitea is a self-hosted Git service. It is stood up in the cluster in the gitea namespace. The two git repos required to run the demo are imported, and any dummy passwords needed for the demo are seeded in the projects and provided to the user. Details on the two repositories:

acmebank-disputes-apispec: Contains the .insomnia design disputes API Design doc.
acmebank-apiops-gateway: Contains the governance rules, deck and apispec files version controlled.

Tutorial Overview
AcmeBank Disputes APISpec
For this tutorial you will be working on the Acmebank Disputes APISpec.

First, you will get hands-on-experiences with Insomnia. The Disputes APISpec will be imported, updated, and the changes commited to source control all from Insomnia.

Second, once the APISpec has been commited to source control, you will execute three tekton CI/CD pipelines sequentially, to review and publish the API to the appropriate Gateway Environment.

disputes-apispec-review pipeline - will open a pr to push the APISpec to the konnect-sandbox runtime group.
api-gateway-sandbox-pipeline - will review open prs to konnect-sandbox: execute custom governance linting of the APISpec, validate the deck transformation, and finally deck sync to administer the API to to the konnect-sandbox runtime group.
api-gatway-dev-pipeline - will publish the APISpec to konnect-dev runtime group and Konnect Service Hub for Dev Portal Integration.

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

APISecOps - Insomnia, Kong Konnect, Tekton - on ROSA

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

In part 2 we walk through the tools, technology, clusters, run-time groups and other prerequisites you need to get started.

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

Getting Started

Prequisites

1. Openshift Cluster - This demo will step through the rosa cli command to create a ROSA cluster but any OpenShift cluster will suffice. This demo has been tested on OCP 4.11.

2. Ansible Core - The playbooks have been tested on 2.13.5 and python version 3.10.8. More information can be found at Installing Ansible.

3. Kong Konnect Plus Account - The demo requires an Konnect Plus grade account because 2 runtime groups and several enterprise grade plugins are used. For more information please review the Kong Konnect Pricing Plan and creation of a Personal Access Token in Konnect.

4. Insomnia - To download check out Insomnia Download.

5. oc cli - The binary download can be found in the openshift console, in the ? tab on the top right.

6. Helm 3 cli - Follow the helm documentation to install the binary Helm Install

ROSA and Konnect Configuration

Execute the install ansible playbook. The play will do the following:

Cert Manager Operator - install and create Konnect DP self-signed certs
Openshift Pipelines Operator - install
Gitea - install and configure
Konnect
create and/or configure runtime groups (Default and Dev)
create konnect gateways (runtime instances)
APIOps - create namespaces, install tekton pipelines and create tekton pipelineruns
Disputes Sample App - create namespace and deploy

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

APISecOps - Insomnia, Kong Konnect, Tekton - on ROSA

Part 3 of 8 Kong Partner Engineering's APISecOps Tutorial ROSA and Kong Konnect in the Red Hat Openshift Ecosystem: Getting Started p2 - Review of Sandboxes and Clusters + ROSA and Konnect Configuration

In part 3 we continue with Part 2 of "Getting Started" post Playbook completion, starting with collecting output information that will be used throughout the demo.

In in the following part of tutorial in part 4, we will begin diving into Insomnia and starting the first step in API design.

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

Getting Started

ROSA and Konnect Configuration

Execute the install ansible playbook. The play will do the following:

Cert Manager Operator - install and create Konnect DP self-signed certs
Openshift Pipelines Operator - install
Gitea - install and configure
Konnect
create and/or configure runtime groups (Default and Dev)
create konnect gateways (runtime instances)
APIOps - create namespaces, install tekton pipelines and create tekton pipelineruns
Disputes Sample App - create namespace and deploy

Infrastructure
Konnect

Two Runtime Groups will be either created or at least checked that it exists - Default, and Dev.

Each runtime group will be provisioned 1 runtime instance (also referred to as a Gateway, Dataplane, or Proxy), each one will be in their own namespace, kong-sandbox, and kong-dev. These Gateways are exposed via loadbalancers, and are where API Consumers will call the protected backend services.

Openshift Pipelines/Tekton

The three pipelines to be executed will be in the namespaces disputes-apispec and apiops-gateway. The separation between namespaces is to demonstrate how pipelines belonging to different personas (Dev Teams vs. Governance and API Operator teams) can be managed in a more secure fashion.

Gitea (Self-hosted Git service)

Gitea is a self-hosted Git service. It is stood up in the cluster in the gitea namespace. The two git repos required to run the demo are imported, and any dummy passwords needed for the demo are seeded in the projects and provided to the user. Details on the two repositories:

acmebank-disputes-apispec: Contains the .insomnia design disputes API Design doc.
acmebank-apiops-gateway: Contains the governance rules, deck and apispec files version controlled.
Disputes Sample Application

The sample application is deployed in disputes-dev namespace. It is a very small JBoss EAP application server.

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

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

APISecOps - Insomnia, Kong Konnect, Tekton - on ROSA

Part 7 of 8 Kong Partner Engineering's APISecOps Tutorial ROSA and Kong Konnect in the Red Hat Openshift Ecosystem: Publish API to Konnect-Dev Gateway Environment

In part 7 we execute the final pipeline and finish step 4 of our devops procedures.

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

4. Publish API to Konnect-Dev Gateway Environment
Publish API to Dev Gateway Env

This pipeline is for the Operations Personas

The development team has deployed the disputes microservice to its dev environment, and now ready to allow others to consume the API, this means publishing the API to the konnect dev gateway instances and document the API Service Hub. This pipeline will:

Prepare deck config for dev environment.
Add the Service Hub tag to the deck config.
Prepare a APISpec for the Dev Portal
Remove any plugin references
Correct the server reference to point at the konnect-dev gateway loadbalancer
Deck sync to the Konnect Control Plane.

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 dev environment, the gatey configuration has been setup to proxy requests to the dispute microservice running in the disputes-dev namespace.

Open the Debug Tab in Insomnia
Change to the Konnect-Dev Environment
Execute the disputes requests to validate the behavior. You should see new responses, and possibly a 404 on /disputes/{id} (because it's in Dev and still in testing 😆).

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