How can we help?
Table of Contents
< All Topics


Concepts and Terminology

Asset Groups

Asset Groups (AG) are a powerful way to visualize compliance. You can create AGs by defining an asset matching criteria. AGs are dynamic in nature, if new resources are created, it will automatically show up in the AG if the newly created resource matches the AG criteria. You can create an AG with just one Ec2 instance, OR all resources in an account, OR All Clouds. During the creation of an AG you can specify resource matching condition based on the resource attributes. For example, you can add all EC2 instances with a particular tag name and value combination or you can create an asset group based on instance-state or AWS account number. Because of the ephemeral nature of the cloud, static AGs are not useful, dynamic AG criteria you can rest assured all matching resources that might be created in the future will be automatically added to the group. Asset groups will not include terminated/deleted resources.

Here are some useful examples, create AG for:

  • each Account (AWS), Subscription (Azure) or Project (GCP)
  • a specific Tag Name and Value combination to span multiple accounts
  • running compute instances across all accounts
  • each environment, e.g. Production (blue and green), QA, Dev

Compliance Domains

‘Compliance Domains’ allow you to view the compliance status by domain. It was created to simplify the compliance status view by grouping similar policies under one compliance domain. During policy and rule creation you could select the compliance domain. In the dashboard, you could switch the domain from the drop-down on the top right corner of the UI. There is an overall compliance summary page too to view your compliance across all compliance domains.

Think of this as grouping similar items into one list and measure how good are you against the list. Switching the compliance domain from the drop-down would change the background color of the UI as well to show the change is view scope.


Policies are codified versions of policies on paper. Each policy can have one or more rules. Each rule will evaluate a resource to check a specific condition. If all rule evaluations result in pass, the Asset is compliant against the policy. In case of failure, the resource is marked as non-compliant.


A rule is the actual codified version of what is being evaluate, e.g. Is port 22 open? Over 150 Default managed rules for AWS, Azure, and GCP, these are Java code bundled into a single jar. You can extend these managed rules in 3 ways:

  1. update the managed rule jar, this model is suggested if you are giving back to the community and it is accepted as a default rule. Obviously this requires rebuilding and updating the runtime
  2. create a federated rule, this model is suggested to create policy specific to your solutions. This will also require a rebuild.
  3. create an API rule, this model is very flexible allowing for private policy without recompiling. You can add more rules or host the rules elsewhere via API. The REST API that would take resource details as input and return whether the resource passed the check or not. Once the API is registered the policy engine invokes like any other rule. The API must adhere to the contract established by Paladin Cloud.

Target and Target Types

Target is the entity, or instance of the service, that is being evaluated by the rule. e.g all EC2 instances have are Target Type = EC2, a specific target will have a resourceID similar to I-1234. PacBot is built as a generic tool not just for the cloud. You could import all of your code repository information and write rules to gauge compliance.


There are cases where some resources should be exempted for a policy, use exception sparingly. You can add an exception to policy violation and the violation won’t show up in the reports and high-level aggregations.

Sticky Exception

Sticky exceptions are dynamic exceptions. Resource matching criteria are used to create an exception. Whenever a resource matching the exception criteria is launched the rule engine would not create a policy violation.


You can define roles to control access to resource groups and admin functionalities as well. By default, a User and Admin role exist.

Job Execution Manager

Job execution manager provides capabilities to manage data collection, enriching and synching jobs.