Kinetic is a tool designed to seamlessly execute user-defined Python code on remote infrastructure (GCP/Kubernetes). Because its primary function is arbitrary code execution, understanding the security boundaries is critical.

Kinetic assumes that any user authorized to submit jobs is a trusted entity. If a user is granted the IAM permissions to upload to the Kinetic GCS buckets and the Kubernetes RBAC permissions to create Jobs/Pods, they have the ability to execute arbitrary code on the cluster.

Kinetic does not attempt to sandbox, restrict, or monitor the Python code written by authorized users. Securing the cluster against authorized users must be done at the infrastructure level (e.g., network policies, minimal IAM roles for the GKE nodes, namespace isolation).

1. Payload Tampering (Man-in-the-Middle): Kinetic relies on cloudpickle to serialize functions. Deserializing untrusted pickle data is dangerous (CWE-502). Kinetic protects against scenarios where an attacker gains write access to the GCS bucket but lacks K8s access.

   • Mitigation: The client computes a SHA-256 hash of the payload at submission time and embeds it immutably into the Kubernetes Pod Spec. The remote runner verifies the payload matches this hash before deserialization, ensuring the payload wasn't tampered with in transit or at rest in GCS.

2. Data Exfiltration via GCS: Kinetic provisions cluster-scoped GCS buckets.

   • Mitigation: Buckets should be locked down using IAM so that only authorized developers and the cluster's service account can read/write.

1. Malicious Insiders: Kinetic does not prevent an authorized user from writing malicious code inside their @kinetic.run() function.
2. Container Escapes: If a user exploits a container runtime vulnerability to escape the Pod, this is an infrastructure/GKE concern, not a Kinetic concern.
3. Compromised K8s Credentials: If an attacker compromises a user's kubeconfig or GCP credentials, they inherit that user's ability to run code.