Spyderbat
Book a DemoStart FreeContact Us
  • Spyderbat Product Docs
  • Getting Started
    • Create an Organization
    • Install the Nano Agent
    • Three Things to Try with Spyderbat Community Edition
    • Manage Users and Roles
  • Installation
    • Spyderbat Nano Agent
      • Kubernetes
        • Pre Deployment Environment Data Collection Script
      • Linux Standalone
      • AWS Unattended Install
        • Secure your Registration Code with AWS Secrets Manager
      • Create a Golden Image with the Nano Agent Pre-Installed
    • Spyderbat AWS Agent
      • AWS Linux VM
      • Kubernetes
      • Configuration Guide - AWS Linux VM
      • Configuration Guide - Kubernetes
    • Install Spyctl CLI
      • Initial Configuration
    • Install Spydertop CLI
    • Install the Spyderbat Event Forwarder
      • Helm Chart
      • Traditional Installer
  • Concepts
    • Guardian & Interceptor
      • Ruleset Policies
      • Workload Policies
    • Flashback (Go Back In Time)
      • Investigations
    • Search
      • Saved Searches
    • Summarize
      • Spydertrace Summarize
    • Dashboards
      • Dashboard Categories
    • Reports
    • Notifications
      • Notification Targets
      • Notification Templates
    • Actions
    • Integrations
      • AWS Integration
      • Spyderbat Event Forwarder
    • Suppression & Tuning
    • Scout (Detections)
      • Custom Flags
  • Tutorials
    • Flashback
      • How to Use the Investigations Feature in Spyderbat
    • Guardian
      • How to Lock Down Your Workloads With Guardian Policies Using Spyctl
      • How to Put Guardrails Around Your K8s Clusters Using Spyctl
    • Integrations
      • How to Configure Event Forwarder Webhook for Panther
      • How to Set Up Spyderbat to Ingest Falco Alerts
      • How to Create and Use a Spyderbat API Key
    • Notifications
      • How to Set Up Notifications Using Spyctl
      • How to Set up Agent-Health Notifications Using Spyctl
    • Dashboards
    • Miscellaneous
      • How to Set Up Spyderbat to Monitor Systems From vulnhub.com
    • Scout (Detections)
      • How to Set Up Custom Flags Using Spyctl CLI
  • Reference
    • Policies
      • Response Actions
    • Rulesets
    • Selectors
    • Notifications
    • Spyctl CLI
      • Spyctl Commands
      • Guardian Policy Management using Spyctl
      • Notification Template Management using Spyctl
      • Notification Target Management using Spyctl
    • Search
      • All Operators
      • All Fields
      • All Related Objects
  • Quick Links
    • Contact Us
    • Try Spyderbat for Free
    • Book a Demo
Powered by GitBook

© SPYDERBAT, Inc., All Rights Reserved

On this page
  • What are Workload Policies?
  • Using Workload Policies

Was this helpful?

Export as PDF
  1. Concepts
  2. Guardian & Interceptor

Workload Policies

Published: April 29, 2024

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. Currently, policies are supported for the following workload types:

  • Containers

  • Kubernetes Pod Containers

  • Linux Services

Workload policies shine when you have a relatively stable set of activity. For example, if your organization uses third party or custom containerized applications, each container will typically run a few processes and make a few network connections. This activity can be whitelisted and the policy should stabilize in a short amount of time.

Workload policy do not perform as well for dynamic, constantly changing activity. A development container is a good example of this. When engineers are constantly logging in and running unique and varied commands it becomes impractical to whitelist activity in this way. There will be constant upkeep.

Using Workload Policies

As soon as the Spyderbat Nano Agent is installed on a machine it automatically gathers information of the workload running on it. Spyderbat compiles Fingerprints for each Linux Service and Container it sees. You can think of a Fingerprint as the observed process and network activity for a single workload. Fingerprints are used to build Workload Policies.

Note: While it is technically possible to define your own Workload Policies it is not advisable to do so. In general, it is best to leverage Spyderbat's assisted creation and update features using Fingerprints and Deviations.

Here is an example of a Fingerprint for a single Container:

apiVersion: spyderbat/v1
kind: SpyderbatFingerprint
metadata:
  name: docker.io/library/nginx:latest
  type: container
  cluster_name: demo_cluster
  containerName: latencytest2
  namespace: default
spec:
  containerSelector:
    image: docker.io/library/nginx:latest
    imageID: sha256:10d1f5b58f74683ad34eb29287e07dab1e90f10af243f151bb50aa5dbb4d62ee
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: default
  podSelector:
    matchLabels:
      run: latencytest2
  processPolicy:
  - name: nginx
    exe:
    - /usr/sbin/nginx
    euser:
    - root
    id: nginx_0
    children:
    - name: nginx
      exe:
      - /usr/sbin/nginx
      euser:
      - systemd-resolve
      id: nginx_1
  networkPolicy:
    egress: []
    ingress:
    - from:
      - ipBlock:
          cidr: 192.168.29.43/32
      - ipBlock:
          cidr: 192.168.43.168/32
      - ipBlock:
          cidr: 192.168.92.6/32
      ports:
      - port: 443
        protocol: TCP
      processes:
      - nginx_1

By default, a Workload Policy is generated by combining all related Fingerprints into a single document. In the image above you can see that this specific container image has 14 instances deployed in our organization. So if one container has network connections that the others do not, the created policy will contain that extra activity.

containerSelector:
  image: docker.io/library/nginx:latest
mode: enforce
enabled: true
processPolicy:
  - name: nginx
    exe:
    - /usr/sbin/nginx
    euser:
    - root
    id: nginx_0
    children:
    - name: nginx
      exe:
      - /usr/sbin/nginx
      euser:
      - systemd-resolve
      id: nginx_1
  networkPolicy:
    egress: []
    ingress:
    - from:
      - ipBlock:
          cidr: 192.168.29.43/32
      - ipBlock:
          cidr: 192.168.43.168/32
      - ipBlock:
          cidr: 192.168.92.6/32
      - ipBlock:
          cidr: 192.168.92.7/32
      - ipBlock:
          cidr: 192.168.92.8/32
      ports:
      - port: 443
        protocol: TCP
      processes:
      - nginx_1
response:
  default:
    - makeRedFlag:
        severity: high
  actions: []

Once applied, a policy will constantly monitor for deviant activity within the policy's selector scope. In the policy above, that means any container using the docker.io/library/nginx:latest image will be evaluated against this policy.

When deviant activity is detected, multiple things can occur. First, the policy will generate a Deviation. This is a record that contains all of the information required to update the policy with this new activity. Secondly, the policy will take any configured response actions. By default, the policy will generate a Red Flag which is part of Spyderbat's Scout feature. These red flags will become part of Spydertraces that are viewable on your dashboards. Other actions include killing the deviant process, or in Kubernetes you can kill the entire pod.

Last updated 12 months ago

Was this helpful?

Fingerprints Page
Policy Creation