> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open-cluster.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Credentials and data access

> Review how credentials are stored, what each integration can read, and what is sent to model providers.

OpenCluster stores each credential in the minimum form needed for its job. Stored
credentials are never returned by an API.

## Credential handling

| Credential                  | Storage and use                                                                                                         |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Alertmanager webhook secret | Shown once, then stored as a SHA-256 digest. It authenticates inbound deliveries.                                       |
| Slack token                 | Verified with Slack before storage, then encrypted with AES-256-GCM under the deployment sealing key.                   |
| GitHub App private key      | Read from a deployment file. It is not stored on an integration; short-lived installation tokens are created in memory. |
| Kubernetes credential       | Not held by OpenCluster. The in-cluster Relay uses its service account.                                                 |
| Model-provider API key      | Read from a deployment file and sent only to the configured provider endpoint.                                          |
| Database credential         | Read from a deployment file named by the placement configuration.                                                       |
| Sessions and API tokens     | Stored as digests, not plaintext.                                                                                       |

Deployment environment variables name secret files; they do not contain secret values.
Credential-shaped fields are excluded from logs and audit details.

## Integration access

* **Slack:** access follows the token type and granted OAuth scopes. Bot-token channel
  reads are limited to public channels available to the app. User-token search can
  return public or private conversations visible to that user. All Slack access is
  read-only. See [Slack scopes](/integrations/collaboration/slack#scopes).
* **GitHub:** access follows the repositories and read permissions selected for one
  GitHub App installation. See [GitHub App permissions](/integrations/source-control/github#github-app-permissions).
* **Kubernetes:** access cannot exceed the Relay service account. A namespace allow-list
  can narrow it. ConfigMap and Secret contents are not sent through inventory sync.
* **Alertmanager:** the webhook secret allows its holder to submit alert payloads. It is
  authentication, not a body signature.

## Data sent to the model provider

For each investigation, the configured model provider can receive:

* system instructions that define the investigation task and boundaries;
* the question, time window, and triggering alert, including labels, annotations, and
  source URLs;
* names and available read operations for enabled, verified integrations that can
  supply investigation reads;
* a bounded current Kubernetes workload inventory when available;
* bounded content returned by Slack or GitHub reads;
* the investigation conversation needed to select later reads and produce a conclusion.

Integration credentials, webhook secrets, deployment keys, and database credentials are
not included. Source content can itself contain sensitive operational data; grant only
the integration access you are prepared to send to the configured provider.

OpenCluster stores read summaries and provenance after a run. The model provider sees
the bounded returned content needed for reasoning, which can be more detailed than the
stored summary.

## Provider consent

Investigations start only when the configured provider is also listed in
`OC_MODEL_CONSENTED_PROVIDERS`. In a self-hosted deployment, provider selection and
consent apply to the deployment, not separately to each organization it serves. Do not
place organizations with different model-subprocessor requirements on the same
deployment.

See [Self-hosted configuration](/self-hosted/configuration#investigations) for the model
settings.

## Rotation and removal

* Rotate an Alertmanager secret from the integration. The old secret stops working
  immediately.
* Replace a Slack token by pasting a new token; it must pass live verification first.
* Rotating the sealing key makes existing encrypted credentials unreadable. Paste each
  affected credential again.
* Disable an integration to stop future use while retaining operational history.
  Deletion is refused when retained records depend on it.