Rule ordering and pattern matching
Pattern matching
All rules in Prisma Cloud have resource filters that let you precisely target specific parts of your environment.
These fields let you apply rules based on container name, image name, host name, Docker labels, Kubernetes Pod template labels, Kubernetes Namespace labels, and Kubernetes Deployment labels. To use Kubernetes Namespace and Deployment labels, you must deploy defenders with the following setting enabled:
Manage > Defenders > Deploy > DaemonSet > Collect Deployment and Namespace labels
.
By default, they’re populated with wildcards, which applies the rule to all objects.You can customize how rules are applied with string matching.
When Prisma Cloud encounters a wildcard in a resource name, it evaluates the resource name according to the position of the wildcard.
- If the string starts with a wildcard, it’s evaluated as string-starts-with.
- If the string terminates with a wildcard, it’s evaluated as string-ends-with.
- If a string is starts and terminates with a wildcard, it’s evaluated as string-contains.
For example, if you specify a resource filter of *foo-resource*, Prisma Cloud matches that resource to any value that contains the string, such as example-foo-resource and foo-resource-1.
Matching logic is case insensitive.
Individual fields are combined using
AND
logic.
For example, if a rule is configured to apply to hosts called foo-hosts* and images called foo-images*, it will apply only to images with names starting with foo-images on hosts with names starting with foo-hosts.Wildcards apply rules to all objects of a given type.
Constrain the scope of the rule by specifying filters.
In the following example, there are no filters for containers or labels (they’re wildcards).
But there are filters for hosts named foo-hosts* and images named foo-images*.
The effective result is
apply this rule anytime the host name starts with foo-hosts and image name starts with foo-images, regardless of the container name or label
.
If strings have no wildcards, Prisma Cloud exactly matches the value you enter against the resource string.
This gives you precise control over which values match.
For example:
- If you want to explicitly target just ubuntu:latest from Docker Hub, use docker.io/library/ubuntu:latest. Because the value you provide is the complete name of the resource, Prisma Cloud matches it exactly.
For DNS filtering, Prisma Cloud doesn’t prevent you from entering multiple wildcards per string, but it’s treated the same as if you simply entered the right-most wildcard.
The following patterns are equivalent:
*.*.b.a == *.b.a
Exemptions
While basic string matching makes it easy to manage rules for most scenarios, you sometimes need more sophisticated logic.
Prisma Cloud lets you exempt objects from a rule with the minus (-) sign (the NOT operator).
From example, if you want a rule to apply to all hosts starting with foo-hosts*, except those starting with foo-hosts-exempt*, then you could create the following rule:
When Prisma Cloud evaluates an object against a rule with a NOT operator, it first skips any object for which there is a match with the exempted object.
So, from our example:
- If the host name starts with foo-hosts-exempt, skip the rule.
- If the host name starts with foo-hosts AND the image name starts with foo-images, apply the rule.
All scope fields, in both policy rules and collection specs, support the NOT operator.
When using the NOT operator, remember that what’s being excluded can’t be broader than what’s included.
For example, the following expression for scoping images is illogical:
-ngnix*, ngnix:latest
The following expression, however, is valid.
It sets the scope to all NGINX images, and then excludes nginx:latest from the set.
ngnix*, -ngnix:latest
To exclude just a single image from the universe, set the include scope with a wildcard, and then use the NOT operator to omit the image.
*, -mongo:latest
Rule ordering
The entire set of rules in a given feature area is called the policy.
The rules in the policy are evaluated from top to bottom, making it easy to understand how policy is applied.
When evaluating whether to apply a rule to a given object, Prisma Cloud uses the following logic:
- Does rule 1 apply to object? If yes, apply action(s) defined in rule and stop. If no, go to 2.
- Does rule 2 apply to object? If yes, apply action(s) defined in rule and stop. If no, go to 3.
- …
- Apply the built-in Default rule (unless it was removed or modified).
Prisma Cloud evaluates the rule list from top to bottom until it finds a match based on the object filters.
When a match is found, it applies the actions in the rule and stops processing further rules.
If no match is found, then no action is applied.
Sometimes this could mean that an attempted action is blocked (e.g. if no access control rule is matched that allows a user to run a container).
To reorder rules, click on a rule’s hamburger button and drag it to a new position in the list.
Disabling rules
If you want to test how the system behaves without a particular rule, you can temporarily disable it.
Disabling a rule gives you a way to preserve the rule and its configuration, but take it out of service, so that it’s ignored when Prisma Cloud evaluates events against your policy.
To disable a rule, click
Actions > Disable
.
Image names
The canonical name of an image is it’s
full name
in a format like registry/repo/image-name.
For example: 1234.dkr.ecr.us-east-1.amazonaws.com/morello:foo-images.
Within Docker itself, these canonical names can be seen by inspecting any given image, like this:$ sudo docker inspect morello/foo-images | grep Repo -A 3 "RepoTags": [ "1234.dkr.ecr.us-east-1.amazonaws.com/morello:foo-images",
However, there’s a special case to be aware of with images sourced from Docker Hub.
For those images, the Docker Engine and client do not show the full path in the canonical name; instead it only shows the ‘short name’ that can be used with Docker Hub and the full name is implied.
For example, compare the previous example of an image on AWS ECR, with this image on Docker Hub:
$ sudo docker inspect morello/docker-whale | grep Repo -A 3 "RepoTags": [ "morello/docker-whale:latest",
Note that when the image is from Hub, the canonical name is listed as just the short name (the same name you could use with the Docker client to issue a command like ‘docker run morello/docker-whale’).
For images like this, Prisma Cloud automatically prepends the actual address of the Docker Hub registry (docker.io) and, if necessary, the library repo name as well, even though these values are not shown by Docker itself.
For example, you can run the Alpine image from Docker Hub simply by issuing a Docker client command like ‘docker run -ti alpine /bin/sh’.
The Docker client automatically knows that this means to pull and run the image that has a canonical name of docker.io/library/alpine:latest.
However, this full canonical name is not exposed by the Docker client when inspecting the image:
$ sudo docker inspect alpine | grep Repo -A 2 "RepoTags": [ "alpine:latest" ], "RepoDigests": [ "alpine@sha256:1354db23ff5478120c980eca1611a51c9f2b88b61f24283ee8200bf9a54f2e5c" ],
But because Prisma Cloud automatically prepends the proper values to compose the canonical name, a rule like this blocks images from Hub from running:
$ docker -H :9998 --tls run -ti alpine /bin/sh docker: Error response from daemon: [Prisma Cloud] The command container_create denied for user admin by rule Deny - deny all docker.io images.
Most Popular
