# Workload Policies

## 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.

<figure><img src="https://4237643999-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBmf9RZ2wNSc4znG5gBc1%2Fuploads%2Fgit-blob-37472567e1ab20746b4dccbc1bc36802ec40e93e%2Fguardian-fingerprints-container-tab.png?alt=media" alt="Guardian Fingerprints page showing the Container tab with a list of container fingerprints, faceted filtering, and columns for image name, cluster, namespace, machines, policy coverage, and fingerprint count."><figcaption><p>The Guardian Fingerprints page displays all observed container fingerprints with filtering by cluster, namespace, machine, status, image, and pod labels.</p></figcaption></figure>

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:

```yaml
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:

```yaml
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.

{% hint style="info" %}
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.
{% endhint %}

### 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.

<figure><img src="https://4237643999-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBmf9RZ2wNSc4znG5gBc1%2Fuploads%2Fgit-blob-cc41efad632218b10d4c5a22e5cd96c200867bfb%2Fguardian-policies-list.png?alt=media" alt="Guardian Policies page showing a table of policies with columns for name, type, created date, latest timestamp, policy mode, status, unique deviations, and total deviations."><figcaption><p>The Guardian Policies page lists all workload policies with their mode, status, and recent deviation counts.</p></figcaption></figure>

### 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`.

{% hint style="warning" %}
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.
{% endhint %}

For full details on response action configuration, see the [Response Actions reference](https://docs.spyderbat.com/reference/policies/response-actions).

## 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](https://docs.spyderbat.com/reference/selectors).

## Related Pages

* [Guardian & Interceptor](https://docs.spyderbat.com/concepts/guardian) — Overview of Guardian policies and Interceptor response actions
* [Ruleset Policies](https://docs.spyderbat.com/concepts/guardian/ruleset_policies) — Cluster-level policies using reusable allow/deny rulesets
* [Response Actions](https://docs.spyderbat.com/reference/policies/response-actions) — Full reference for configuring policy response actions
* [Selectors](https://docs.spyderbat.com/reference/selectors) — Reference for policy selector types
* [How to Lock Down Your Workloads with Guardian Policies Using Spyctl](https://docs.spyderbat.com/tutorials/guardian/how-to-lock-down-your-critical-workloads-with-policies-spyctl) — Step-by-step tutorial