Skip to main content

Kong Konnect

Visualize your Kong Konnect API gateway estate in the JupiterOne graph — the Control Planes in your organization and the Gateway configuration each one owns: the Services traffic is proxied to, the Routes that match requests to them, the Consumers that call them, and the Plugins enforcing authentication, rate limiting and other policy. Plugins are linked to the Service, Route or Consumer they protect, so you can see which of your APIs are behind an auth plugin and which are exposed without one. TLS Certificates and Consumer Group membership are ingested alongside, letting you audit gateway policy coverage and monitor configuration changes through queries and alerts.

Installation​

This integration reads your Kong Konnect organization through the Konnect Control Planes and Control Planes Config v2 APIs — the Control Planes in your organization, and the Gateway configuration each one owns: Services, Routes, Consumers, Consumer Groups, Plugins and Certificates. It is read-only, issuing only GET requests, and never modifies your Gateway configuration.

Plugins are attached to the Service, Route or Consumer they are scoped to, and Routes to the Service they proxy to, so gateway policy coverage is queryable directly from the graph.

Prerequisites​

  • A Kong Konnect organization.
  • The geographic region your organization is hosted in. Konnect data is geo-scoped, so this determines which API host the integration reads from — see Choosing a region below.
  • A Konnect access token with read access to your Control Planes — see Creating an access token below.
  • Access to JupiterOne with permission to configure integrations.

Choosing a region​

Konnect runs in six geographic regions, and each one is served from its own API host:

RegionAPI host
United States (us)https://us.api.konghq.com
Europe (eu)https://eu.api.konghq.com
Australia (au)https://au.api.konghq.com
India (in)https://in.api.konghq.com
Middle East (me)https://me.api.konghq.com
Singapore (sg)https://sg.api.konghq.com
note

Konnect objects such as Control Planes, Services and Consumers are geo-specific — an object created in one region does not exist in another, and only authentication, billing and usage are shared between regions. An integration instance therefore sees exactly one region. If your organization operates in more than one, create one instance per region.

The Singapore region must be opted into by a Konnect org admin in the region picker before it can be used. See Geographic regions for the current list.

Creating an access token​

The integration authenticates with a bearer token, and accepts either kind of Konnect access token:

  • A Personal Access Token (PAT), prefixed kpat_, tied to a user account.
  • A System Account Access Token (SPAT), prefixed spat_, tied to a system account.

A system account is the better choice for an integration: it is not tied to a person, so the integration keeps working when that person's access changes or they leave the organization. System accounts cannot sign in to the Konnect UI and exist only for API use.

To create a personal access token, select your user icon in Konnect to open the context menu, click Personal access tokens, then click Generate token.

caution

The token is displayed only once, when it is generated. Record it before leaving the page — if you lose it, you must generate a new one.

Granting read access​

A Konnect token carries exactly the access of the identity it belongs to — Konnect has no separate scopes or permission strings for tokens, only the RBAC roles assigned to that user or system account.

Assign the Control Planes → Viewer role, which grants "read only access to all entities within a control plane" and covers everything this integration reads. Roles can be scoped to one Control Plane or to all Control Planes.

note

Scope the role to all Control Planes. GET /control-planes returns only the Control Planes the identity has a role on, so a token scoped to a subset silently ingests only that subset rather than reporting an error. If you intend to cover the whole organization, grant the role organization-wide — or use the predefined Organization Admin (Read Only) team, which can view all entities and configuration in the organization.

See Teams and roles for how roles are assigned to users, teams and system accounts.

Personal access tokens have a maximum lifetime of 12 months, are limited to 10 per user, and are revoked after 12 months of inactivity. Plan a rotation before the token expires, or the integration will begin failing authentication.

Configuration in JupiterOne​

To install the Kong Konnect integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Kong Konnect. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Kong Konnect account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • Your Personal Access Token — the kpat_ or spat_ token you created above.

  • Your Region — the geographic region your Konnect organization is hosted in, selected from the list.

Click Create once all values are provided to finalize the integration.

Data sources​

You can narrow what the integration collects from the instance's ingestion source settings. All sources are enabled by default.

Ingestion sourceDefaultData collected
Fetch Control PlanesEnabledThe Control Planes in your organization, with cluster type, data-plane auth type, and the Control Plane and telemetry endpoints.
Fetch ServicesEnabledGateway Services — the upstreams Kong proxies to — with the upstream address, protocol, timeouts, retries and TLS verification setting.
Fetch RoutesEnabledRoutes and their matching rules (protocols, methods, hosts, paths, SNIs or router expression), and the Service each one proxies to.
Fetch ConsumersEnabledConsumers — the clients of your proxied Services — with their username and custom ID.
Fetch Consumer GroupsEnabledConsumer Groups used to apply shared policy, and which Consumers belong to each.
Fetch PluginsEnabledPlugins, the policy they represent, whether they are enabled, and the Service, Route or Consumer each one is scoped to.
Fetch CertificatesEnabledTLS Certificate metadata and the SNI hostnames associated with each.

Sources build on one another, and disabling one also disables the sources that depend on it:

  • Fetch Control Planes underpins every other source — Gateway configuration is read per Control Plane, so disabling it disables all of them.
  • Fetch Routes depends on Fetch Services, so that each Route can be linked to the Service it proxies to.
  • Fetch Consumer Groups depends on Fetch Consumers, so that group membership can be resolved.
  • Fetch Plugins depends on Fetch Services, Fetch Routes and Fetch Consumers, so that each Plugin can be attached to what it protects. Because Plugins carry your authentication and rate-limiting policy, check this before turning any of those three off.
note

Certificate private keys are never ingested. The Konnect API returns the PEM cert and key material on every Certificate, and the integration discards it before anything is written to the graph — only the certificate ID, SNIs, tags and timestamps are kept. Plugin config blocks are discarded the same way, since they hold credentials for several plugin types.

note

Control Plane groups are ingested as Control Planes but their Gateway configuration is not read separately. A group is a read-only Control Plane that combines the configuration of its member Control Planes under the same entity IDs, so reading both would duplicate every Service, Route, Consumer, Plugin and Certificate. The members are ingested directly instead, and each skipped group is recorded in the job log.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​