clu

Capabilities

Clu ships four capabilities. All are included at the single flat AWS Marketplace rate — the bill doesn't change based on which ones you have on. Turn each one on per cluster via Helm values.

CapabilityWhat it adds
CoreRead-only Kubernetes observability, knowledge graph, scheduled health reports, in-cluster chat UI
Core PlusApproval-gated write operations across Kubernetes and Helm
CloudRead-only AWS surface — IAM, RDS / ElastiCache, S3, ECR, Secrets Manager, EC2 networking, Cost Explorer, IRSA + Terraform scaffolding
Developer Platform (coming soon)Self-serve developer onboarding — golden-path scaffolding, manifest generation, IRSA + ExternalSecret + chart emission

Core

The read-only foundation. Enabled by default in the chart's values.

What operators use it for: troubleshooting ("why is this pod crashlooping?"), health dashboards, convention detection, policy drift, routing issues. The agent reads cluster state, infers patterns, and explains what's wrong without proposing any change that needs approval.

Capabilities at a glance:

  • Live Kubernetes reads — pod state, events, logs, rollouts, network policy, ingress, service endpoints, HPA / PDB status.
  • Helm release inspection — list deployed charts and read their effective values via the Kubernetes API. No helm binary on the pod.
  • Prometheus integration — auto-discovers an in-cluster Prometheus service; runs queries, surfaces alerts, exposes a curated set of presets. Falls back to CloudWatch metrics when Prometheus isn't installed.
  • Knowledge graph — startup scan that catalogs namespaces, workloads, CRDs, conventions, and detected integrations (Argo, Kyverno, external-secrets). Persisted across pod restarts; refreshed hourly.
  • Scheduled health reports — background rule set produces prioritized findings every 30 minutes by default; snooze any finding with a TTL.

Core Plus

Adds approval-gated write capability on top of Core.

What operators use it for: propose-and-apply workflows where the agent diagnoses, suggests a fix, and dispatches the write only after a human clicks Approve. The audit log records every approved (or rejected) change.

Write surface (all gated, dry-run-first, never target protected namespaces):

  • Apply, scale, restart-rollout, and cordon operations on Kubernetes workloads.
  • Helm install and upgrade against the curated public chart catalog or any registry registered via helm.repos[] in your values.
  • Approval-gated helm uninstall and Kubernetes delete, with a provenance check that prefers helm uninstall over raw deletes for resources owned by a chart so the chart manifest stays the source of truth.

Safety invariants (these are hard-coded; no Helm value overrides them):

  • No writes to kube-system, kube-public, kube-node-lease, or clu-ops.
  • No cluster-wide admin, no Secret value reads.
  • Every write dry-runs first; real apply only after explicit operator approval in the UI.
  • Every approved action is audit-logged with operator id, approval id, and payload hash.

See Write operations for the approval flow.

Cloud

Adds a read-only AWS surface plus IRSA and Terraform scaffolding.

AWS services covered (all read-only):

  • IAM — roles, attached policies, IRSA trust-policy verification.
  • RDS + ElastiCache — managed-database inventory.
  • S3 — bucket listing + metadata. Never reads object content.
  • ECR — repository inventory.
  • Secrets Manager — names + ARNs only. Never reads secret values.
  • EC2 networking — VPCs, subnets, security groups.
  • Cost Explorer — per-service cost summary.

Scaffolding output: Terraform for IRSA roles and trust policies, ExternalSecret manifests, full-stack IaC bundles when paired with Core Plus (Kubernetes manifests + IRSA Terraform + ExternalSecret as a single change set).

What operators use it for: "Which IAM role does this workload assume?" / "Does this ServiceAccount's trust policy actually accept the right federated identity?" / "What's driving this month's spend?" / "Scaffold the IRSA Terraform for a new service."

See IAM setup for the required IAM policies.

Developer Platform (coming soon)

Self-serve developer onboarding. Helps developers ship their first service into the cluster without waiting on the platform team.

What it'll cover: golden-path scaffolding (one command from "new service" to "manifests + IRSA + ExternalSecret + chart emitted"), an opinionated catalog of starter templates, and an approval-gated path for developer-initiated change sets.

Capability ships in a follow-up release. The Helm value (modules.developerPlatform.enabled) is reserved today; toggle has no effect until the capability lands.

Enabling or disabling capabilities

Each capability toggles via Helm values:

modules:
  core:
    enabled: true
  corePlus:
    enabled: true
    writeOperations:
      enabled: true
  cloud:
    enabled: true
  developerPlatform:
    enabled: false  # reserved; ships in a follow-up release

Apply the change with helm upgrade. Existing data (reports, approvals, audit log) survives — nothing in the backing stores is gated on which capability created it. The bill doesn't change based on which ones are on.

The chart and images live on the AWS Marketplace ECR registry only; your AWS credentials must resolve to a subscribed account for the pull to succeed. There's no public Helm repo.

Status in the UI

The dashboard's Capabilities panel shows each capability with one of:

  • ✅ Active — enabled in Helm, ready to use.
  • ❌ Inactive — disabled in Helm values, or capability not yet shipped (Developer Platform). Capabilities are independent — turning Cloud off doesn't block Core Plus, and vice versa.

The agent's system prompt carries the same capability state on every conversation turn, so it can answer "can I do X?" precisely without a tool call.

PreviousGetting startedNextArchitecture