Workload Policies

Workload Policies define allowed process and network activity for containers and Linux services, alerting or blocking deviations from expected behavior.

What Are Workload Policies?

Workload Policies are the most granular form of Guardian Policy. They define the allowed process and network activity for well-defined workloads. Policies are supported for two workload types:

• Containers — including standalone Docker containers and Kubernetes pod containers

• Linux Services — systemd-managed services running on monitored machines

Workload policies work best when the workload has a relatively stable set of activity. A third-party containerized application that runs a few processes and makes a few network connections is a good candidate — the activity can be baselined and the policy should stabilize quickly.

Workload policies are less effective for dynamic, constantly changing activity. A development container where engineers run unique and varied commands is a poor fit because the policy would require constant updates.

How Workload Policies Work

Fingerprints

As soon as the Nano Agent is installed on a machine, Spyderbat automatically gathers information about workloads running on it. The platform compiles Fingerprints for each Linux service and container it sees. A Fingerprint represents the observed process and network activity for a single workload instance over a time window.

To view Fingerprints, navigate to Guardian > Fingerprints in the console. Use the Container and Linux-Service tabs to switch between workload types.

The Guardian Fingerprints page displays all observed container fingerprints with filtering by cluster, namespace, machine, status, image, and pod labels.

The Fingerprints page shows key information for each fingerprint group:

Column	Description
Image Name / Service Name	The container image or Linux service identifier
Cluster	The Kubernetes cluster (containers only)
Namespace	The Kubernetes namespace (containers only)
Machines	How many machines this workload runs on
Covered By Policy	Whether an existing policy covers this workload
Number of Fingerprints	How many individual fingerprint instances exist

Here is an example Fingerprint for a single container. It captures the observed process tree and network connections:

apiVersion: spyderbat/v1
kind: SpyderbatFingerprint
metadata:
  name: docker.io/library/nginx:latest
  type: container
  cluster_name: production-cluster
  containerName: web-proxy
  namespace: default
spec:
  containerSelector:
    image: docker.io/library/nginx:latest
    imageID: sha256:10d1f5b58f74...
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: default
  podSelector:
    matchLabels:
      app: web-proxy
  processPolicy:
  - name: nginx
    exe:
    - /usr/sbin/nginx
    euser:
    - root
    id: nginx_0
    children:
    - name: nginx
      exe:
      - /usr/sbin/nginx
      euser:
      - www-data
      id: nginx_1
  networkPolicy:
    ingress:
    - from:
      - ipBlock:
          cidr: 10.0.1.0/24
      ports:
      - port: 443
        protocol: TCP
      processes:
      - nginx_1
    egress: []

From Fingerprints to Policies

When you create a policy, Spyderbat combines all related Fingerprints into a single document. If the same container image runs across 14 instances and one instance has network connections the others do not, the resulting policy includes that extra activity — producing a union of all observed behavior.

The resulting Workload Policy looks like:

containerSelector:
  image: docker.io/library/nginx:latest
mode: audit
enabled: true
processPolicy:
- name: nginx
  exe:
  - /usr/sbin/nginx
  euser:
  - root
  id: nginx_0
  children:
  - name: nginx
    exe:
    - /usr/sbin/nginx
    euser:
    - www-data
    id: nginx_1
networkPolicy:
  ingress:
  - from:
    - ipBlock:
        cidr: 10.0.1.0/24
    - ipBlock:
        cidr: 10.0.2.0/24
    ports:
    - port: 443
      protocol: TCP
    processes:
    - nginx_1
  egress: []
response:
  default:
  - makeRedFlag:
      severity: high
  actions: []

Notice the key differences from the Fingerprint: the policy adds mode, enabled, and response fields, and the network policy now includes IP ranges from all instances.

Creating a Policy from Fingerprints

To create a Workload Policy:

1. On the Fingerprints page, select one or more fingerprints using the checkboxes.

2. Click Create Policy in the action bar that appears at the bottom of the page.

3. Step 1 — Baseline and Edit: Spyderbat combines the selected fingerprints into a single policy document. The policy editor shows the YAML on the left and a visual Policy Trace on the right. You can edit the policy to generalize selectors (such as namespaces or clusters) or adjust process and network rules.

4. Step 2 — Save Policy: Name the policy and save it.

While it is technically possible to define Workload Policies from scratch, it is best to use Spyderbat's assisted creation from Fingerprints. The platform handles the complex process and network tree structures automatically.

Policy Modes

Every Workload Policy operates in one of two modes:

Mode	Behavior
Audit	Monitors activity and records Deviations, but does not take enforcement actions. Use this mode when baselining a new policy.
Enforce	Records Deviations and executes configured Response Actions (such as killing a process or pod). Use this mode once the policy has stabilized.

New policies default to audit mode. Switch to enforce mode only after reviewing Deviations and confirming the policy accurately reflects expected behavior.

Deviations

Once applied, a policy continuously monitors all workloads matching its selectors. When activity occurs that falls outside the policy's allowed process or network rules, the platform generates a Deviation.

A Deviation is a record containing all the information needed to either:

• Update the policy to allow the new activity (if it is expected)

• Investigate the activity as a potential security concern

The Guardian Policies page shows deviation counts for each policy over the last 24 hours, including both unique and total deviation counts.

The Guardian Policies page lists all workload policies with their mode, status, and recent deviation counts.

Response Actions

When a Deviation occurs, the policy executes its configured response actions. The two categories are:

• Standard actions — Generate flags that appear in dashboards and can trigger notifications:

  • makeRedFlag — Creates a security-focused flag that can trigger Spydertraces

  • makeOpsFlag — Creates an operations-focused flag for infrastructure issues

• Agent actions — Direct the Nano Agent to take action on the machine:

  • agentKillProcess — Terminates the deviant process

  • agentKillProcessGroup — Terminates the deviant process and its process group

  • agentKillProcessTree — Terminates the deviant process and all descendants

  • agentKillPod — Terminates the entire Kubernetes pod (containers only)

  • agentReniceProcess — Adjusts the CPU priority of the deviant process

By default, new policies are configured with a single response action: makeRedFlag with severity: high.

Agent enforcement actions (agentKillProcess, agentKillPod, etc.) actively terminate workloads. Only enable these in enforce mode after the policy has been thoroughly validated in audit mode.

For full details on response action configuration, see the Response Actions reference.

Policy Structure

A Workload Policy defines three main sections:

Section	Purpose
Selectors	Define which workloads the policy applies to (by container image, namespace, pod labels, cluster, machine, or service name)
Process Policy	A tree of allowed processes, including executable paths, effective users, and parent-child relationships
Network Policy	Allowed ingress and egress network connections, including IP ranges, ports, protocols, and which processes may make the connections

For reference documentation on selectors, see the Selectors reference.

Related Pages

• Guardian & Interceptor — Overview of Guardian policies and Interceptor response actions

• Ruleset Policies — Cluster-level policies using reusable allow/deny rulesets

• Response Actions — Full reference for configuring policy response actions

• Selectors — Reference for policy selector types

• How to Lock Down Your Workloads with Guardian Policies Using Spyctl — Step-by-step tutorial