Worker security model

Restore Jobs process backup content and connect to customer systems. Treat the code and data inside each restore Pod as untrusted. The generated installation separates the long-lived worker identity from short-lived restore workloads and gives each component only the permissions it needs.

Security boundaries

Identity Secret

The identity Secret authenticates the agent as one project worker. Restore workloads never need it.

• Keep it only in the agent namespace.
• Restrict who can read Secrets in that namespace.
• Do not copy, rename, edit, or rotate the generated identity.json.
• Do not reference a Secret beginning with restoretrust-worker-identity from a source or schedule.
• Do not run two Pods or Deployments with the same identity.

Restore Job identity

The generated restoretrust-job ServiceAccount:

• does not receive a Kubernetes API token;
• has no RBAC binding;
• must not be annotated for AWS IAM roles, Google service accounts, Azure workload identity, or another cloud identity.

The agent checks this identity when it starts. A missing, unreadable, token-enabled, or cloud-bound ServiceAccount prevents the worker from accepting checks.

Do not use the job namespace for unrelated workloads. The generated egress floor selects every Pod in that namespace.

Agent permissions

The generated Role in the job namespace permits the agent to:

• create, observe, patch, and delete its Jobs;
• observe logs and manage its Pods;
• create and read execution NetworkPolicies;
• read the named restoretrust-job ServiceAccount.

It does not grant access to Secrets, token creation, Pod exec, or cluster-wide resources. In the agent namespace, the agent can only read Pods and Pod logs: its own Pod, to report which image it runs, and its own log, so the console can show it live.

Do not add patch or delete permission for NetworkPolicies. Those verbs would allow the agent to weaken the namespace egress floor.

Secret use inside restore Jobs

Create source credentials and backup-decryption Secrets in the job namespace. Kubernetes injects only the Secrets referenced by the selected source and schedule.

Decryption material is made available to the download stage, not to later restore and validation stages. The worker identity Secret is never made available to a restore Job.

Anyone with permission to create or mutate Pods in the job namespace can potentially consume local Secrets or widen workload behavior. Limit human, controller, and admission access to that namespace.

Pod and node controls

Restore containers run non-root with privilege escalation disabled, all capabilities dropped, and RuntimeDefault seccomp. Validator filesystems are read-only; database containers retain only the writable filesystem behavior required by their database image.

The generated install labels only the job namespace for restricted Pod Security.

NetworkPolicy does not replace node hardening. Depending on the CNI, node addresses can remain reachable, and DNS must remain open for source resolution. The restore Pod has no ServiceAccount token, but you should still:

• disable anonymous Kubernetes API access where practical;
• use CNI host or node policies for protected node ranges;
• monitor and filter DNS according to your threat model;
• isolate worker nodes when required by your data classification.

Data lifecycle

Scratch volumes can contain the original backup, decoded data, and a restored database. Use encryption at rest and reclaimPolicy: Delete. Completed data remains until the result is acknowledged and Kubernetes removes the Pod and its generic ephemeral PVC.

Retaining Jobs for debugging also retains their PVCs and customer data. Disable debug retention during normal operation and clean retained resources promptly.