Security
Last updated: September 2026
TERAKUBE is built to run in production Kubernetes clusters with least-privilege access. This page summarizes our security approach; specifics can be shared under NDA during procurement.
Least-privilege access
On EKS, TERAKUBE uses IRSA with a scoped IAM policy — including iam:PassRolerestricted to exactly the node role(s) your cluster uses (managed nodegroups and/or Karpenter). In-cluster RBAC grants only the permissions optimization needs.
No application code changes
TERAKUBE optimizes workloads and infrastructure without modifying your application code or container images.
Authenticated core ↔ ML
Communication between the core and the ML service uses short-lived, signed tokens carrying cluster identity and license validity, cross-checked server-side. Traffic is served over HTTPS.
Model & data handling
Models can run entirely in your cluster, or centrally in your own cloud account. When hosted centrally, encrypted model artifacts are pulled into memory rather than written to disk, and every request is verified against your license registry.
Controlled, transparent automation
Automation is opt-in. You can start in observe-only, scope exactly which workloads are eligible, and every optimization action is transparent and reversible — with safe scaling that restores workloads on demand and manages PodDisruptionBudgets.
Data in transit & at rest
Traffic is encrypted in transit. Persistent data uses encrypted storage. Access is limited on a need-to-know basis.
Reporting a vulnerability
Found an issue? Please email security@terakube.com. We appreciate responsible disclosure and will acknowledge reports promptly.