> ## 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.

# Configuration clusters

> Declare KAOP resources from your own cluster's manifests, and see which cluster owns what — including when an edit here will be reverted.

A platform team can declare Komodor Agentic Operation Platform (KAOP) configuration — MCP servers,
credentials, workflows and fifteen other kinds — as resources in their own cluster, kept in git. An
operator you install reconciles them through the ordinary product API. This page covers connecting a
cluster, the three states an install can be in, and what the **Cluster-managed** badge does and does
not promise about an edit made here.

## Connecting a cluster

<Steps>
  <Step title="Add the cluster">
    Adding a cluster mints its credential and **reveals it once**. Store it before you leave the
    screen.
  </Step>

  <Step title="Create the secret">
    The screen renders a `kubectl create secret` command. The credential is never written into the
    command itself — you put it into a Secret you create, because passing it as a Helm value would
    leave it in your shell history and readable from the release's stored values.
  </Step>

  <Step title="Install the operator">
    A `helm upgrade --install` command comes pre-filled with this deployment's URL and the chart's
    Secret name. Both commands stay readable from the row afterwards — they carry no secret and are
    the same every time.
  </Step>
</Steps>

## Three states, not two

Each row reports whether the install is **reconciling**, **paused**, or **not connected yet**, along
with its namespace, operator version, how many resources it declares, and when it last synced.

The third state earns its place. An install you created but never deployed against is configured and
has never called in — describing that as reconciling would contradict its own last-sync column,
which reads *Never*.

## What "Cluster-managed" tells you about an edit

Declarable resources carry a **Cluster-managed** badge wherever they are listed. Provenance alone
cannot answer the question you actually have — *will my edit stick?* — so the badge distinguishes
three situations:

| State                                                         | What happens if you edit it here                                                                                              |
| ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Declared **and** enforced                                     | The write is **refused**, and the row's own edit controls are inactive. Change the manifest in the declaring cluster instead. |
| Declared, install running, enforcement not switched on        | The edit **succeeds, then the next reconcile reverts it**.                                                                    |
| **Cluster-managed, not enforced** — install paused or removed | The edit **holds** until the install resumes.                                                                                 |

<Warning>
  Enforcement is off by default. So "a cluster declares this" and "your edit will be refused" are
  routinely different answers — which is exactly why the badge reports the combination rather than
  just ownership.
</Warning>

## Pausing, and removing

**Pause and resume** are per row. Resuming reverts whatever was edited while the install was paused,
so the confirmation says so before you agree to it.

**Removing** an install is per row too, and its confirmation names all three consequences at once:

* The resources it declares **stop being managed** and become editable here — they are **not**
  deleted.
* Its credential is **revoked**, so an operator still running in that cluster is locked out.
* Unlike a pause, **nothing reverses it.**

The dialog states the same count the *Declares* column shows, because once ownership records are
gone that count survives only in the audit record.

<Note>
  Rotating a credential is deliberately not on this screen. Rotation locks the install out until
  someone redeploys it with the new value, and nothing here can carry that value into your cluster.
</Note>

## Next steps

<CardGroup cols={2}>
  <Card title="Audit log" href="/security-and-governance/controls/audit-log">
    Where adding, pausing, and removing an install are recorded.
  </Card>

  <Card title="Roles & permissions" href="/security-and-governance/identity-and-access/roles-permissions">
    Seeing installs, and seeing what they declare, is its own capability.
  </Card>

  <Card title="Credentials & secrets" href="/manage-your-agents/build/credentials-secrets">
    One of the kinds a cluster can declare.
  </Card>

  <Card title="MCP Gateway" href="/manage-your-agents/build/mcp-gateway">
    MCP servers are declarable too, in both shapes they take.
  </Card>
</CardGroup>


## Related topics

- [Go SDK](/developer-tools/go-sdk.md)
- [Cluster Investigator](/manage-your-agents/build/catalog/cluster-investigator.md)
- [Manage a deployed agent](/manage-your-agents/build/manage-a-deployed-agent.md)
- [Build from scratch](/manage-your-agents/build/build-from-scratch.md)
- [Klaudia Investigator](/manage-your-agents/build/catalog/klaudia-investigator.md)