All pages
Powered by GitBook
1 of 3

Guardian & Interceptor

The Spyderbat Guardian Feature is designed to enhance security within your Spyderbat environment. It provides a robust framework for defining and enforcing expected behavior through Guardian Policies. These policies are crucial for maintaining the integrity of your systems and ensuring that only authorized activities are permitted.

Guardian Policies

Guardian Policies are the cornerstone of Guardian, serving as the rulebook for allowed and prohibited activity within your environment. They come in two primary forms:

Workload Policies

Workload Policies are tailored to containers and Linux services, specifying a whitelist of permitted activities. This ensures that only known, safe operations are allowed to execute, providing a first line of defense against unauthorized or malicious behavior.

Read more about Workload Policies here.

Key Components:

  • A comprehensive list allowed process and network activity.

  • Scope: The selectors detailing the specific containers or services to which the policy applies.

  • Response: The mechanism by which the policy take actions.

Ruleset Policies

Ruleset Policies offer a more flexible approach, supporting policy-agnostic rulesets that can be applied across different environments. These rulesets contain both allow and deny rules, providing a granular level of control over the behavior within your systems.

Read more about Ruleset Policies here.

Key Components:

  • Allow Rules: Explicitly permit certain actions, overriding any broader deny rules that may be in place.

  • Deny Rules: Define actions that are explicitly prohibited, regardless of other allow rules.

  • Reusability

Interceptor

The Interceptor feature set allows Guardian to take response actions based on policy violations. When a policy violation occurs, Interceptor Response Actions can trigger actions such as generating alerts, or blocking the offending activity.

More details on response actions can be found here.

Tutorials

Tutorials detailing the creation of the various policy types can be found in the tutorials section of this documentation.

Conclusion

The Spyderbat Guardian Feature is a powerful tool for maintaining security and compliance in containerized and Linux service environments. By effectively utilizing Guardian Policies, you can ensure that your systems operate within the defined parameters of expected behavior, safeguarding against potential threats.

For more detailed information and advanced configurations, please refer to the policy reference guide.

Ruleset Policies

Published: April 29, 2024

What are Ruleset Policies

Ruleset Policies are a way of defining a set of allow or deny rules for a given scope. Currently, ruleset policies are supported for the following scope(s):

  • Kubernetes Clusters

Ruleset Policies, themselves are very simple. They define a scope with a selector, and they contain a list of pointers to reusable rulesets. And they also define a set of response actions when deviations occur.

apiVersion: spyderbat/v1
kind: SpyderbatPolicy
metadata:
  createdBy: demo.user@spyderbat.com
  creationTimestamp: 1712787973
  lastUpdatedBy: demo.user@spyderbat.com
  lastUpdatedTimestamp: 1714417836
  name: demo-cluster-policy
  selectorHash: 66e45259eba6ed4365e28e7e673a18cf
  type: cluster
  uid: pol:xxxxxxxxxxxxxxxxxxxx
  version: 1
spec:
  clusterSelector:
    matchFields:
      name: demo-cluster
  enabled: true
  mode: audit
  rulesets:
  - demo-cluster-ruleset
  response:
    default:
    - makeRedFlag:
        severity: high
    actions: []

The Rulesets used by a Ruleset Policy are policy-agnostic and as such can be defined once and used across multiple policies. Rulesets contain a set of allow or deny rules. Each rule contains a target, verb, list of values, and optional selectors (for additional scoping).

  • Target: what the rule is referring to within the scope of the policy.

    • ex. container::image this means that we are allowing or denying containers using images specified in the values field.

  • Verb: The currently available verbs for ruleset rules are allow or deny. Any object matching a deny rule will generate a Deviation.

  • Values: This is the set of values that are allowed or denied. If the target is container::image then the values should be container images that are either allowed or denied.

  • Selectors: Optional selectors that further define the scope of a single rule. For instance you may want a rule that defines allowed activity in a specific namespace within a cluster.

The following is an example rule that allows containers with the images docker.io/guyduchatelet/spyderbat-demo:1 and docker.io/library/mongo:latest in the namespaces rsvp-svc-dev and rsvp-svc-prod.

namespaceSelector:
  matchExpressions:
  - {key: kubernetes.io/metadata.name, operator: In, values: [rsvp-svc-dev, rsvp-svc-prod]}
target: container::image
values:
- docker.io/guyduchatelet/spyderbat-demo:1
- docker.io/library/mongo:latest
verb: allow

The following rule denies the image docker.io/guyduchatelet/spyderbat-demo:2 globally.

target: container::image
values:
- docker.io/guyduchatelet/spyderbat-demo:2
verb: deny

The following is an example ruleset automatically generated from a demo cluster:

apiVersion: spyderbat/v1
kind: SpyderbatRuleset
metadata:
  createdBy: demo.user@spyderbat.com
  creationTimestamp: 1712787972
  lastUpdatedBy: demo.user@spyderbat.com
  lastUpdatedTimestamp: 1714162618
  name: demo-cluster-ruleset
  type: cluster
  uid: rs:xxxxxxxxxxxxxxxxxxxx
  version: 1
spec:
  rules:
  - namespaceSelector:
      matchExpressions:
      - {key: kubernetes.io/metadata.name, operator: In, values: [rsvp-svc-dev, rsvp-svc-prod]}
    target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:1
    - docker.io/library/mongo:latest
    verb: allow
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
    target: container::image
    values:
    - 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni-init:v1.10.1-eksbuild.1
    - 602401143452.dkr.ecr.us-west-2.amazonaws.com/amazon-k8s-cni:v1.10.1-eksbuild.1
    - 602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/coredns:v1.8.7-eksbuild.1
    - 602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/kube-proxy:v1.22.6-eksbuild.1
    - public.ecr.aws/aws-secrets-manager/secrets-store-csi-driver-provider-aws:1.0.r2-58-g4ddce6a-2024.01.31.21.42
    - registry.k8s.io/csi-secrets-store/driver:v1.4.2
    - registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.10.0
    - registry.k8s.io/sig-storage/livenessprobe:v2.12.0
    verb: allow
  - target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:2
    verb: deny
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: prometheus
    target: container::image
    values:
    - quay.io/prometheus/node-exporter:v1.7.0
    - quay.io/prometheus/pushgateway:v1.7.0
    - registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.10.1
    verb: allow
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: spyderbat
    target: container::image
    values:
    - public.ecr.aws/a6j2k0g1/aws-agent:latest
    - public.ecr.aws/a6j2k0g1/nano-agent:latest
    verb: allow

How rules are evaluated

Rules are evaluated based on a specific hierarchy. Scoped rules take precedence over global rules, explicit rules take precedence over wildcarded rules, deny rules are evaluated first, and anything that matches no rules is denied by default.

Evaluation Order

  1. Scoped explicit deny

  2. Scoped explicit allow

  3. Scoped wildcarded deny

  4. Scoped wildcarded allow

  5. Global explicit deny

  6. Global explicit allow

  7. Global wildcarded deny

  8. Global wildcarded allow

  9. Default deny

*Scoped

the rule contains a selector

*Explicit

the matched value contains no wildcard characters

*Wildcarded

the matched value contains a wildcard character *

Examples

Scenario 1 (Global Explicit Allow):

Image: docker.io/guyduchatelet/spyderbat-demo:1

spec:
  rules:
  - target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:1
    verb: allow

A container with the image docker.io/guyduchatelet/spyderbat-demo:1 would be allowed globally.

Scenario 2 (Default Deny)

Image: docker.io/guyduchatelet/spyderbat-demo:bad-tag

spec:
  rules:
  - target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:1
    verb: allow

A container with the image docker.io/guyduchatelet/spyderbat-demo:bad-tag would be denied by default.

Scenario 3 (Global Explicit Allow with Global Wildcard Deny):

Image 1: docker.io/guyduchatelet/spyderbat-demo:1 Image 2: docker.io/guyduchatelet/spyderbat-demo:bad-tag

spec:
  rules:
  - target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:1
    verb: allow
  - target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:*
    verb: deny

Global explicit allow is evaluated before global wildcarded deny so Image 1 is allowed. Image 2 is denied by the global wildcarded deny.

Scenario 3 (Scoped Wildcarded Allow with Global Explicit Deny):

Image 1: docker.io/guyduchatelet/spyderbat-demo:1 Namespace labels: {kubernetes.io/metadata.name: rsvp-demo-prod} Image 2: docker.io/guyduchatelet/spyderbat-demo:bad-tag Namespace labels: {kubernetes.io/metadata.name: rsvp-demo-prod} Image 3: docker.io/guyduchatelet/spyderbat-demo:bad-tag Namespace labels: {kubernetes.io/metadata.name: rsvp-demo-dev}

spec:
  rules:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: rsvp-demo-prod
    target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:*
    verb: allow
  - target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:bad-tag
    verb: deny

Since the first rule has a namespace selector, that rule is scoped. Scoped wildcarded allow rules are evaluated before global explicit deny rules so Image 1 and Image 2 are allowed. Image 3 is denied by the global explicit deny rule.

Scenario 4 (Scoped Explicit Allow with Scoped Wildcarded Deny)

Image 1: docker.io/guyduchatelet/spyderbat-demo:1 Namespace labels: {kubernetes.io/metadata.name: rsvp-demo-prod} Image 2: docker.io/guyduchatelet/spyderbat-demo:bad-tag Namespace labels: {kubernetes.io/metadata.name: rsvp-demo-prod} Image 3: docker.io/guyduchatelet/spyderbat-demo:bad-tag Namespace labels: {kubernetes.io/metadata.name: rsvp-demo-dev}

spec:
  rules:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: rsvp-demo-prod
    target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:1
    verb: allow
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: rsvp-demo-prod
    target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:*
    verb: deny

Both rules are scoped because they have a namespace selector. Scoped explicit allow rules are evaluated before scoped wildcarded deny rules so Image 1 is allowed. Image 2 is denied by the scope wildcarded deny rule. Image 3 does not match the scope of any rule so it is denied by default.

Scenario 5 (Scoped Explicit Allow with Scoped Explicit Deny)

Image: docker.io/guyduchatelet/spyderbat-demo:1 Namespace labels: {kubernetes.io/metadata.name: rsvp-demo-prod}

spec:
  rules:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: rsvp-demo-prod
    target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:1
    verb: allow
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: rsvp-demo-prod
    target: container::image
    values:
    - docker.io/guyduchatelet/spyderbat-demo:1
    verb: deny

Scoped explicit deny rules are evaluated before scope explicit allow rules, so the image is denied by scoped explicit allow.

Quick Start Tutorial

To quickly get started using using Cluster Ruleset Policies follow our tutorial using spyctl.

How to Put Guardrails Around Your K8s Cluster

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
Fingerprints Page

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.

Policy Creation

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.