Kong Service Manager Plugin

The Kong Service Manager plugin offers the facility to manipulate your service from different Kong environments, in your component, detailing information about the service, listing the routes it has and also offering the possibility of manipulating plugins without leaving the backstage.

Our community

💬 Join Us

Join our community to resolve questions about our Plugins. We look forward to welcoming you!

  Go to Community  🚀

🚀 Getting started:

Before installing the plugin, there are some prerequisites to ensure its functionality:

• Have a locally installed Backstage project, :heavy_check_mark: How to create a Backstage app :page_with_curl: .
• Have the Kong Service Manager Backend plugin installed on your Backstage, see how to install here.

If you are using yarn 3.x:

yarn workspace app add @veecode-platform/plugin-kong-service-manager

If you are using other versions:

yarn add --cwd packages/app @veecode-platform/plugin-kong-service-manager

Configuration ⚙️

1- Add Kong key in AppConfig

In the app-config.yaml file, add the configuration:

ℹ️ As instructed in the documentation for the backend plugin.

kong:
  instances:
    - id: kong-instance01
      apiBaseUrl: ${ KONG_HOST ]
      workspace: ${ KONG_WORKSPACE }  # optional "Only if your version is enterprise"
      auth:
        kongAdmin: ${ KONG_ADMIN_TOKEN } # optional if the instance is enterprise
        custom:  # optional if the kong is in community mode and depending on the authentication used
          header: ${ KONG_HEADER }  # Ex: Authorization or key-auth
          value: ${ KONG_AUTH } # Ex: Basic $your_token or how the token is added depending on the approach

2- Annotations

The plug-in recognizes 3 annotations for its operation, the first being kong-manager/service-name, which will identify the service that will be used as a parameter. In this annotation, you can enter the name of the service or its id, preferably the name. It is also important to note that each catalog-info.yaml can only receive one service.

The other annotation will be kong-manager/instance, which will receive the instances on which kong will make calls, and can receive more than one item, properly separated by commas and without spaces. It is important to note that the instances must be configured in app-config.yaml, as described in the previous section; if they have not been configured correctly, the calls will not be answered.

And finally, the annotation kong-manager/spec, where the open-api file that will serve as the spec for the project will be listed, it should be in root and by convention can be called openapi-swagger.yaml. Remember that this annotation is optional if you want to list the kongs specs in the Backstage component and assign plugins already associated with the service to the related spec.

Here's an example:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: "Component A"
  description: "An example"
  annotations:
    github.com/project-slug: test/ComponentA
    backstage.io/techdocs-ref: dir:.
+    kong-manager/service-name: nameservice_test_A01
+    kong-manager/instance: kongInstance1,kongInstance2
+    kong-manager/spec : openapi-swagger.yaml  #optional
   
spec:
  type: service
  lifecycle: prod
  owner: "devops"

UI 💻

Taking into account that the settings are ok, we now need to adjust our EntityPage.tsx to render the plugin correctly. To do this, we'll change the following file packages > app > src > components > catalog > EntityPage.tsx:

... 
+ import { KongServiceManagerContent, isKongServiceManagerAvailable } from '@veecode-platform/plugin-kong-service-manager';

...

const serviceEntityPage = (
  <EntityLayout>
    <EntityLayout.Route path="/" title="Overview">
      {overviewContent}
    </EntityLayout.Route>

    <EntityLayout.Route path="/ci-cd" title="CI/CD">
      {cicdContent}
    </EntityLayout.Route>

+    <EntityLayout.Route
+      if={isKongServiceManagerAvailable}
+      path="/kong-service-manager" title="Kong">
+      <KongServiceManagerContent/>
+    </EntityLayout.Route>

  </EntityLayout>
);

...

ℹ️ We've used the ServiceEntityPage component for the example, but it can be replicated for any of the existing types in the EntityPage.

Now that the plugin is properly configured, let's take a look at the screens it offers:

👉 About Page:

Here we've highlighted all the information about the service referenced in the component, note that in the top right corner we have a combobox where we can navigate between the available kong instances:

👉 All Routes:

• List of all routes for your Kong instance; ✅
• Create / Removing and Editing a route at your Service; ✅
• Filtering by the routes created in the service; ✅

On this screen, we list all the routes that the service has:

Also noteworthy is the behavior of the tags field, which expands when triggered:

In the actions column, you can edit a route or delete it. You can also create new routes with the “create” button:

👉 All Plugins:

The list of plugins:

• List of all plugins eligible for your Kong instance; ✅
• Installing / Removing and Editing a plugin at your Service; ✅
• Plugin search field; ✅
• Filtering by the plugins installed in the service; ✅

Listing of all plugins:

Installing a plugin

For the example, we'll use the rate limiting plugin:

When you install it, it will appear on the Associated Plugins tab:

From then on, the plugin will already be configured in your service:

👉 Specs:

Finally

• List of all specs available ✅
• The spec will list the plugins that are associated with the service ✅
• In the list of plugins, we can enable and remove them from the spec via a pull request to the repository ✅

ℹ️ To use the spec manipulation functionality, you'll need to configure the integration and authentication of the chosen git provider (At this point Gitlab or Github). See how to add authentication here and integration by clicking here

Permissions

See 👉Kong Service Manager Common

This plugin provides the following permissions:

• kongServiceReadPermission 👉 Allows service information to be read,
• kongReadAvailablePluginsPermission 👉 Allows you to read the plugins available for the service,
• kongRoutesReadPermission 👉 Allows you to read all service routes,
• kongApplyPluginToServicePermission 👉 Allows you to apply a plugin to the service,
• kongUpdateServicePluginPermission 👉 Allows you to edit a plugin already installed in the service,
• kongDisableServicePluginPermission 👉 Allows you to disable a service plugin,
• kongRouteCreatePermission 👉 Allows you to create a route for the service,
• kongUpdateRoutePermission 👉 Allows you to edit an existing route in the service,
• kongRouteDeletePermission 👉 Allows you to remove an existing route from the service,
• kongApplyPluginToRoutePermission 👉 Enable a plugin for a route,
• kongUpdateRoutePluginPermission 👉 Allows you to edit a plugin applied to a route,
• kongDisableRoutePluginPermission 👉 Allows you to remove a plugin from a route,
• kongReadSpecsPermission 👉 It allows you to read the specs of the source code, if they are properly pointed out,
• kongUpdateSpecPermission 👉 Allows project specs to be updated.

🚨 View Backstage docs to learn how to set up your instance of Backstage to use these permissions.

💡 See more about Kong:

Kong Docs: https://docs.konghq.com/