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.
• GitHub: access follows the repositories and read permissions selected for one GitHub App installation. See 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 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.