Security and data handling

Everything carries the label app.kubernetes.io/part-of=zoorik-agent. The agent updates itself to each Zoorik release and rolls back a failed update. It can’t widen its own permissions: a release that needs more shows “Re-run connect”. If Argo CD, Flux or Helm manages the agent, it doesn’t update itself.

In Kubernetes

The agent can’t read your Secrets or ConfigMaps, and has no pods/log, pods/exec or pods/portforward permission. It holds get on nodes/proxy to read kubelet metrics. That permission can also reach the kubelet’s log and exec endpoints, which Coral never calls.

On AKS

Connect creates a managed identity, zoorik-agent-<cluster>, with the role “Zoorik Node Removal v1” on that cluster only. The role can read the cluster, its pools and machines, and delete machines. Connect also turns on workload identity and the OIDC issuer if they are off. The OIDC issuer can’t be turned off again.

On EKS

Connect creates an IAM role bound with EKS Pod Identity that can only terminate instances in this cluster’s Auto Scaling groups. On a cluster that uses only aws-auth, installing Karpenter switches authentication to API_AND_CONFIG_MAP for good.

Connect

zoorikctl lists every cloud change and asks once. --dry-run prints everything and changes nothing. If you decline, the agent still installs, and fixed-size pools wait until you run zoorikctl cluster grant-node-deletion. A connect token works once and expires after 60 minutes. A cluster credential lasts 90 days and is replaced automatically. Both are stored only as SHA-256 fingerprints.

What connect asks to change

• Per-container usage summaries: CPU, memory, OOM kills, probe failures and CPU pressure, read every 30 seconds and sent in 5-minute windows.
• An inventory every 5 minutes: nodes, namespaces, workloads with requests and limits, autoscalers, PodDisruptionBudgets, quotas, and up to 64 labels per workload and namespace.
• Events, with pod and node names. A heartbeat every 60 seconds. At registration, the cloud account.
• If Zoorik can’t be reached, the agent buffers up to 1 GiB inside its own pod.

What never leaves

• Env var values, commands, image names and request payloads.
• Event text, except the message when a pod can’t be created because of a quota, a limit range or an admission policy.
• Pod memory. A live-migration checkpoint stays inside the cluster, moves between two nodes over mutual TLS and is deleted when the move ends.

The agent opens every connection itself over HTTPS and accepts none from outside the cluster.

• One agent per onboarded VM: amoeba-agent.service, running as root from /opt/amoeba-agent on Java 17 or later. It opens no port and connects out only to Zoorik.
• It sends its reports, and keeps a command channel and a governance channel open, over WebSocket (wss), all with its own key. Zoorik signs every command with that key (HMAC-SHA256), and the agent checks the signature before it acts. A key from another VM can’t act for this one.
• The key never travels in a cloud command. The install command carries a single-use bootstrap token, which the installer exchanges with Zoorik for the agent’s key. The key sits in /etc/amoeba-agent.env, readable by root only. A reinstall replaces it.
• Zoorik reaches the VM in one of two ways. Azure Run Command keeps a copy of each command under /var/lib/waagent and logs each run in the activity log. AWS Systems Manager keeps the command history in your account.

On Azure

Zoorik acts only through the custom role “Zoorik Storage Operator”, assigned to Zoorik’s app on each subscription you connect. You set it up by running the connect script with your own Azure sign-in. Zoorik never receives your Azure password or a token for you. An action added later reaches your subscription only when you run the script again.

On AWS

Zoorik acts only through the IAM role ZoorikStorageOperator, which a script you run in AWS CloudShell creates. The role trusts Zoorik’s AWS account only with your organisation’s external ID. Zoorik’s own AWS identity may only assume roles with that name and read AWS prices.

Encryption

New pool disks take the encryption key of the first encrypted source disk: your customer-managed KMS key on AWS, or your disk encryption set on Azure. Encryption at rest carries over.

• Every 15 seconds: each mount’s path, filesystem type and ID, its used and total size, the devices and cloud disk IDs behind it, and the name of the systemd service holding it open.
• Disk activity per device, the pool’s sizes and btrfs error counters, and host facts: kernel version, OS family, btrfs availability, sector sizes and encryption state.
• Copy progress during a move, and, if an install fails, the last log lines, with secrets removed.
• Never: file contents, hostnames, IP addresses, user names or process lists. The copy runs inside the VM, from your disks to the pool’s disks.

• Only these: an elastic disk a shrink emptied; a disk an expand created and gave up on; the pool’s disks after you go back; a source disk after the 48-hour soak, once its snapshot is complete; and a safety snapshot when its 7 days end.
• It never removes a disk that still holds data, never deletes a source disk before its snapshot is complete, and never looks inside a VM you haven’t onboarded.

• Sign in with Microsoft or Google. Zoorik never sees your password. Sign-in uses OpenID Connect with PKCE and a nonce, Secure and HttpOnly cookies, and anti-forgery tokens. A session ends after 30 minutes idle or 12 hours.
• Row-level security in the database keeps each Coral organisation’s data apart, and every agent upload is tied to the organisation of its credential.
• Only a small number of people at Zoorik, and the automated tools that build and deploy our products, can access or change the systems that run them.

• Coral’s and Amoeba’s databases, backups, key vault and container registry are in Microsoft Azure, Central India. Backups are kept for 7 days and are not copied to another region.
• Every connection from the internet uses HTTPS, with HSTS. Cloudflare re-encrypts traffic to our servers, and our gateway accepts connections only from Cloudflare. Coral reaches its database over TLS 1.2 or later. Azure encrypts the database and disks at rest.
• Cluster data is kept while the cluster reports, then for 30 days. Amoeba’s agent reports sit in a cache for up to 72 hours.

Every retention period

These two handle the cluster and VM data we process for you. The full list is in the privacy policy.

• Email founders@zoorik.com.
• Please don’t test Zoorik’s security without our written permission.
• If a breach affects your personal data, we tell you, and the authorities the law requires.
• If we process personal data for you, we answer your reasonable written security questions once a year.

Privacy policyTerms of use