How to Lock Down Your Workloads With Guardian Policies Using Spyctl
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.
Prerequisites
Have installed at least one Spyderbat Nano Agent installed on a machine of your choosing
What is a Guardian Workload Policy
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.
Retrieving Fingerprints
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.
Download Fingerprints to a File
To create a policy we must first download the fingerprints we wish to use to build the policy.
For example:
[Optional] Downloading Fingerprints from a K8s Namespace
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.
Create the Policy
Once you have the Fingerprints to create the policy from, issue the following command:
For example:
Running this command does not make any changes to your Spyderbat Environment. It is not until you have applied a Policy, that enforcement takes effect.
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:
Policies are created in audit mode by default. If you apply a Policy in audit mode it will not take response actions, but will log the activity it would have taken. You can use the command spyctl logs policy POLICY_UID to monitor those log.
Generalize the Policy
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.
Applying the Policy
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:
[Optional] Adding "Interceptor" Response Actions
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:
Summary and Next Steps
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.
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 Guardian Policy Management in Spyctl. It explains how to edit, update, and diff your policies. It will also explain when to graduate your policies from audit to enforce mode.
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.
Last updated
Was this helpful?