1 of 1

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.

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.

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.

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

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

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

Scoped explicit deny
Scoped explicit allow
Scoped wildcarded deny
Scoped wildcarded allow

Examples

Scenario 1 (Global Explicit Allow):

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

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

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

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}

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)

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}

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.