CAST AI Least-Privilege Review
Overview
Review permissions against the components actually enabled. Distinguish observation, optimization, operator lifecycle, Kvisor telemetry, optional cluster proxy, and cloud-provider access instead of labeling the entire installation read-only or full-access.
Prerequisites
- Selected umbrella-chart mode and optional features
- Rendered Helm resources, service accounts, RBAC, cloud IAM, and secret references
- Organization roles, API-key inventory, network policy, and data-classification rules
Instructions
Step 1: Establish feature scope
Use Read and Grep to map read-only, Workload Autoscaler, Node Autoscaler, full, Kvisor options, reliability metrics, GPU or storage telemetry, operator management, and cluster proxy. Flag enabled components that lack a named business owner.
Step 2: Review identity boundaries
Separate human castctl login from service API keys. Verify organization role bindings, region, enterprise child targeting, storage, rotation, and revocation. Reject keys in values, URLs, Terraform output, logs, or support artifacts.
Step 3: Review Kubernetes permissions
Use Bash(helm:) to render the pinned installation and Bash(kubectl:) for bounded RBAC inspection. Compare each service account to current documented permissions. Account for agent deployment patching, operator lifecycle permissions, Kvisor cluster reads, optional scan jobs, and feature-gated token or pod-resize permissions.
Step 4: Review cloud permissions
Map each AWS, GCP, Azure, or other permission to monitoring, onboarding, automation, discovery, commitments, or storage telemetry. Do not reuse an automation role for read-only monitoring when the provider supports narrower access.
Step 5: Review network and data paths
Document regional egress, private connectivity, webhook destinations, telemetry classes, retention, and support-transfer controls. Do not invent a static IP allowlist or a broad 0.0.0.0/0 policy under the label of least privilege.
Step 6: Record disposition
Use Write or Edit to mark every finding KEEP, NARROW, REMOVE, or INVESTIGATE with owner, evidence, risk, and rollback. Treat Kvisor security documentation as evolving and verify current product scope before enabling a feature.
Tool Discipline
Use Read and Grep for configuration and permission mapping. Use Write and Edit for the review record. Use Bash(helm:) and Bash(kubectl:) only for rendered and effective RBAC inspection; never retrieve Secret data or mutate access.
Output
- Enabled-feature and component inventory
- Human, service, Kubernetes, and cloud identity matrix
- Network, telemetry, and retention boundary
- Evidence-linked permission dispositions
Examples
A read-only deployment retains agent snapshot reads but rejects node-provisioning cloud actions. Kvisor storage telemetry is held until its provider permissions and data audience are explicitly approved.
Error Handling
| Failure | Response |
|---|---|
| Feature mode is unknown | Inspect the release before judging permissions |
| Permission has no documented feature owner | Mark it INVESTIGATE, not safe |
| A key is exposed | Revoke, rotate, and remove the exposure |
| Current Kvisor behavior is ambiguous | Hold the feature and verify current documentation/support guidance |