Rule ordering and 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.
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:
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
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. 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 that uses a minus sign, it first skips any object for which there is a match with the exempted object. So, from our example:
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.
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.
The canonical name of an image is it’s
full namein 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.
Recommended For You
Recommended videos not found.