This page will teach you about Guardian Workload Policies. It will explain what they are, how to create them, how to apply them, and how to manage them.
Last updated
Was this helpful?
Have installed at least one installed on a machine of your choosing
Spyderbat's Guardian Workload Policy feature empowers users to define a known-good whitelist of process and network behavior for containers and Linux services. These policies serve as a proactive measure, enabling users to receive notifications when Spyderbat detects deviant activity within their workloads. Not only does the Guardian Workload Policy provide alerts, but it also offers the capability to take decisive actions by terminating deviant processes and Kubernetes pods. This comprehensive approach ensures a robust security framework, allowing users to maintain a vigilant stance against potential threats and unauthorized activities within their environments.
Workload Policies also serve as a way to tune out certain Red Flags & Spydertraces. Red Flags and Spydertraces that would have been generated by your workloads will be marked as exceptions and reduce clutter in your security dashboards.
Policies are created from Fingerprints. Fingerprints are auto-generated documents with the process and network activity for a single container instance or instance of a Linux Service.
To view all Fingerprints generated across your organization, issue the following command:
For example:
By default, Spyderbat queries for all Fingerprints in your organization for the last 1.5 hours. This means that it will retrieve Fingerprints for any container or Linux service instance running during that time window (Even if the instances started well before the time window). You can increase the time range with the -t option.
In this example organization we have 3 workloads running across multiple instances. Spyderbat has Fingerprints for two instances of mongo, 14 instances of nginx, and one instance of node that were online during the query's time window. None of these Fingerprints are covered by a policy as seen in the COVERED_BY_POLICY column.
To create a policy we must first download the fingerprints we wish to use to build the policy.
For example:
In certain instances you may have the same container image running in different Kubernetes namespaces with different allowed network activity. To separate allowed network activity by namespace you can use multiple policies for the same image. Using only Fingerprints from the same namespace will automatically scope the policy to that namespace.
for example:
This will only download Fingerprints tied to a the namespace specified in the command.
Once you have the Fingerprints to create the policy from, issue the following command:
For example:
The Policy file we just created policy.yaml now has a new resource, the kind field is now "SpyderbatPolicy". This document is a merged version of the Fingerprints that went into it:
In its current form, this policy will only apply to mongo containers with the latest tag and only with the image ID sha256:68248f2793e077e818710fc5d6f6f93f1ae5739b694d541b7e0cd114e064fa11
We can remove selector fields and wildcard values to broaden the Policy's scope.
Using the edit command will open your favorite text-editor and perform syntax checking when you save.
Then we can generalize the containerSelector and the IP blocks
In the above policy we removed the imageID field in the containerSelector we also increase the scope of the ipBlock in ingest from multiple /32 CIDRs to a single /16 CIDR.
To apply a Policy you must use the apply command:
The apply command will recognize the kind of the file, perform validation, and attempt to apply the resource to the policy database for the organization in your current Context. It accomplishes this via the Spyderbat API.
For example, to apply the Policy we created above:
This will apply the Policy to the organization in your current Context.
To view the applied Policies in your current Context you can use the get command:
For example:
To view the yaml of the Policy you just applied, issue the command:
The Policy will look something like this:
When a new Policy is created it will have a default Actions list, and an empty list of actions. The default Actions are taken when a policy is violated and no Actions of the same type in the actions list are taken.
By default, spyctl includes a makeRedFlag Action in the default section of the policy’s response field. This tells the Spyderbat backend to generate a redflag of high severity which will show up in the Spyderbat Console. The full list of redflag severities, in increasing severity, is as follows:
info
low
medium
high
critical
The Actions in the actions field are taken when certain criteria are met. Every Action in the actions field must include a Selector. Selectors are a way of limiting the scope of an Action. For example, you can tell Spyderbat to kill a bash process that deviates from the Policy by using the processSelector:
If you are in a Kubernetes environment you can also set up an Action to kill a pod when a Policy violation occurs. Let's say you want to kill a pod in your staging environment, the action would look like so:
To add a kill process action, edit your policy file. For example:
And add a kill process Action to the actions list.
Our Policy now looks like this:
At this point you should have an applied policy in audit mode. You'll find that if you run spyctl get fingerprints --type container or spyctl get fingerprints --type linux-service the fingerprints you included in the policy will now be covered.
When all of your policies are in enforce mode and every fingerprint is covered by a policy you will have locked down your environment using Guardian. You will have established a whitelist of activity for your all of your critical workloads which simultaneously allows you to quickly be notified when real threats occur, and reduce red flag and spydertrace noise in your Spyderbat Dashboards.
While in audit mode your policy will generate logs of the actions it would have taken, in addition to any deviations it detects. To learn how to manage and update your policies refer to . It explains how to edit, update, and diff your policies. It will also explain when to graduate your policies from audit to enforce mode.
