> ## Documentation Index > Fetch the complete documentation index at: https://docs.komodor.com/llms.txt > Use this file to discover all available pages before exploring further. # Built-in integrations > The catalog of ready-made connections — cloud, observability, source control, ticketing, chat — with the credentials each needs and how to test one. A built-in integration is a connection the Komodor Agentic Operation Platform (KAOP) already knows how to make. You supply credentials once; the tools, the auth handling, and the connection health come with it. This page lists what is in the catalog, what each provider asks for, and how connecting, testing, and reconnecting work. ## Where the catalog lives Everything on this page lives under **Integrations**. The section rail splits it into: | Section | What it holds | | ----------------------- | ------------------------------------------------------------------------------------------------------------- | | **Integrations** | The provider catalog and your live connections | | **Integration groups** | Named bundles you attach to an agent — see [Integration groups](/manage-your-agents/build/integration-groups) | | **Endpoints (inbound)** | URLs external systems post to in order to start work | | **Webhooks (outbound)** | KAOP posting events to an endpoint of yours | | **Channels** | Slack surfaces where people invoke agents | ## The catalog | Provider | Category | How it authenticates | | -------------------- | ------------------- | ---------------------------------------- | | **AWS** | Cloud | Access keys, or a cross-account IAM role | | **Azure** | Cloud | Application credentials | | **Google Cloud** | Cloud | Service account key | | **Datadog** | Observability | API key | | **Dynatrace** | Observability | API tokens | | **New Relic** | Observability | API key | | **Grafana Cloud** | Observability | Service account token | | **GitHub** | Source control | App install | | **GitLab** | Source control | OAuth | | **Buildkite** | CI/CD | API key | | **PagerDuty** | Incident management | OAuth | | **Opsgenie** | Incident management | API key | | **Jira** | Ticketing | OAuth | | **Linear** | Ticketing | OAuth | | **Sentry** | Error tracking | OAuth | | **LaunchDarkly** | Feature flags | API key | | **Slack** | Communication | OAuth | | **Google Workspace** | Productivity | OAuth | | **Komodor** | Kubernetes | OAuth | Some providers are unavailable until this deployment has the corresponding OAuth or app registration configured. The catalog says so on the tile rather than letting you start a connect that cannot finish. ### Providers with sub-selections Two providers let you narrow what the connection covers, so an agent is not handed more surface than it needs: * **Google Cloud** — choose the products to include: Cloud Logging, Cloud Monitoring, Error Reporting, Cloud Trace, Service Health, Cloud Quotas, Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Billing, Recommender, Cloud Asset Inventory, Network Management, and Policy Troubleshooter. * **Google Workspace** — choose from Drive, Docs, Sheets, Slides, Calendar, Chat, Contacts, and Gmail. Because each product is its own connection, one organization legitimately has several Google Workspace connections. ## The auth modes Four shapes of connection exist, and which one you get is decided by the provider, not by you. You paste the provider's key or token into the connect dialog and press **Connect**. For API-key providers the credential is checked as part of connecting: an authentication failure refuses the create outright, so you never end up with a connection that was never going to work. You press **Authorize with \** and complete the provider's own sign-in in a popup. KAOP stores the resulting tokens and refreshes them as needed — there is nothing for you to rotate by hand. GitHub connects by installing a GitHub App: press **Install GitHub** and choose which organization and repositories it covers. The permissions the app requests are shown before you install, and recorded on the connection afterwards. AWS also offers an IAM-role variant instead of long-lived keys. You deploy a CloudFormation stack that creates a role KAOP may assume, then paste the created role back to complete the connection. The external id used in the trust policy is derived from your account and cannot be supplied by the caller, which is what stops one account naming another's role. Prefer the AWS IAM-role variant over access keys. It avoids storing long-lived credentials, and the role can be scoped read-only at creation time. ## Connect one Go to **Integrations** and press **Add integration**. Search or browse by category. Press **Connect** on its tile. If you already have a connection to that provider, the tile reads **Add another** instead — connecting twice is normal when you have two accounts or two regions. AWS asks whether to authenticate with access keys or an IAM role. The choice decides what the connection can do, so make it deliberately. A display name is required and must be unique for that provider — it is how you tell two connections apart everywhere else in the product. Fill in the provider's fields, then complete the connect, authorize, or install. Use **Test connection** from the connection's menu. See [Test and reconnect](#test-and-reconnect) for how to read the result. A connection existing does not give any agent access to it. Attach it on the agent — directly, or as part of an [integration group](/manage-your-agents/build/integration-groups). ## What each provider asks for Field labels are the provider's own vocabulary, which is what you will see in the dialog. | Provider | Required | Optional | | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | ----------------- | | **AWS** (access keys) | Access key ID · Secret access key | AWS region | | **AWS** (IAM role) | AWS account ID | Role name | | **Azure** | Client secret · Application (client) ID · Directory (tenant) ID · Subscription ID | — | | **Google Cloud** | Service account key (base64) | Products | | **Datadog** | API key · Application key · Datadog site | Toolsets | | **Dynatrace** | Platform token · Environment URL | Classic API token | | **New Relic** | User API key | New Relic region | | **Grafana Cloud** | Service account token · Grafana URL | — | | **Buildkite** | API Access Token | — | | **LaunchDarkly** | API access token | — | | **Opsgenie** | API key | — | | **GitHub** | Nothing to paste — the app install carries the grant | — | | **Slack** · **PagerDuty** · **Jira** · **Linear** · **Sentry** · **GitLab** · **Google Workspace** · **Komodor** | Nothing to paste — OAuth carries the grant | — | The **Datadog site** and the **Dynatrace environment URL** are not cosmetic — they select which regional endpoint the connection talks to. Getting them wrong produces authentication failures that look like a bad key. ## One connection per real account An account holds one connection per thing on the provider's side: one per Slack workspace, one per GitHub App installation, and a single AWS connection at a time. Connecting the same Slack workspace again does not create a second row — depending on the state of the existing one, KAOP either adopts it or tells you it is already connected and which workspace it belongs to. What you *can* have is several connections to the same **provider** for different accounts or regions, told apart by display name. Anything that consumes an integration is bound to a specific connection, not to "whichever Datadog". When only a provider is named and you hold more than one connection to it, the most recently created active connection is used. If that matters for your case, bind the connection explicitly rather than relying on the default. ## Test and reconnect A connection carries two independent pieces of state, and reading them as one is the most common source of confusion. | State | Question it answers | Values | | -------------- | ----------------------------------------------------- | --------------------------------------------- | | **Status** | Did someone finish connecting this, and is it paused? | Pending · Active · Error · Revoked · Disabled | | **Last check** | Do the credentials actually work? | Passed · Failed · Skipped | **Skipped is not a pass.** Not every provider has a check KAOP can make, and for those the result is skipped rather than a green tick you should not trust. A failure is additionally classified so you know where to look: authentication, network, timeout, a tool error, a missing credential, or no available check. ### Testing Use **Test connection** from the connection's menu. The test makes one real call to the provider — an identity or a light read — and records the verdict on the connection. Testing runs when you ask for it. Nothing re-checks a connection in the background, so a credential that expires after a passing test keeps reading as passed until someone tests again. A result older than a day is shown as verified earlier rather than as current — treat that as a prompt to re-test before relying on it. ### Reconnecting When a connection's last check has failed, a **Reconnect** button appears directly on the row. When it is not failing, the same action lives in the menu as **Re-authorize** — use it to replace an expired credential or extend a grant. * Reconnecting an OAuth connection is pinned to the account it already serves. Authorizing a different workspace is refused rather than silently repointing the connection. * Replacing a credential clears the previous verdict, so test again afterwards. ### The other actions | Action | What it does | | -------------------------------- | ------------------------------------------------------- | | **Test connection** | Run the check and record the verdict | | **View details** | Inspect the connection, including its id | | **Add server** | Expose the provider's MCP tools through this connection | | **Re-authorize** / **Reconnect** | Replace or refresh the credential | | **Disconnect** | Remove the connection | Disconnecting is refused while something still depends on the connection, and the refusal names what depends on it. Detach or repoint those first rather than forcing it — an agent left pointing at a removed connection loses the tools it was relying on. ## Exposing a provider's tools Connecting a provider stores a credential. For providers that ship an MCP surface, the setup wizard also stands up the tool server that uses it, in three steps — **Connect account**, **Expose tools**, and **Route**. On the way through you choose whether to expose every discovered tool and which integration group the result belongs to. Some providers instead authenticate against their MCP server's own authorization server, in which case signing in *is* the setup and no separate stored credential is involved. For your own tools rather than a provider's, see the [MCP Gateway](/manage-your-agents/build/mcp-gateway). ## Next steps Bundle connections and attach the set to an agent. How stored secrets reach a run without being exposed. The other connection path — your own tools. Endpoints, and why they are not triggers. ## Related topics - [Integrations overview](/manage-your-agents/build/integrations-overview.md) - [Integration groups](/manage-your-agents/build/integration-groups.md) - [Cloud Cost](/modules-and-workflows/cost-optimization/cloud-optimization.md) - [Kubernetes Cost](/modules-and-workflows/cost-optimization/k8s-cost.md) - [Incident management & troubleshooting](/modules-and-workflows/sre/incidents.md)