Packages ENTERPRISE
A Package is a collection of related policies consisting of Rego rules and helper functions. Each package has its unique name and organizes its policies.
The following data sources and packages are added by default when a new Custom system is created.
The data sources and packages provide a starting point for new users. Therefore, you can delete these resources from your Custom system when required.
features: A package that allows you to define rich data that a stack can use in its rule implementations.
labels: A package that identifies your system and describe its purpose (e.g.,
production
), contracts (e.g.,pci-compliant
), lifecycle (e.g.,release
), and other characteristics.monitor: A package that defines the results displayed in the Compliance pane for this system and in the Validate results pane. For more information on package monitor, see the Compliance section.
rules: A package that is intended to be the place where you write your policies.
system.log: A package that is intended to be the place where you specify the policy to remove any sensitive data before uploading the decision to the
package system.log
.test: A package that is used to write OPA unit tests. Run the unit tests with the Validate button in the policy editor.
dataset: A data source that is intended to be the place where you can create dynamic or static JSON data for your policies.
Reserved Packages
Another important concept about packages is that the DAS reserves a small number of package paths.
The following package names may not be used:
global
: References all of the Rego code in the Library.system
: Reserved by OPA for decision log (system.log) and authorization (system.authz).styra
: Reserved for future internal functionality.metadata
: Reserved for data about the system as a whole. For example,labels
.monitor
: Used for computing compliance violations.stock packages for a Custom System
: rules, test, monitor.
Limitations
With OPA, you can put any Rego package into any file in the file system, irrespective of the directory path. With the DAS, you have the following limitations to create packages under directories in a hierarchical form.
The file name of a package’s module file does not have to correspond to the last segment of the package name.
The directory path must match the package path as shown in the following examples.
The package
api.retail
must exist in a file located under the directoryapi/retail
.├── Your Custom System
...
├── api
├── retail
├── retail_rules.rego //must declare `package api.retail`The package
common
must exist in a file located under the top-level directorycommon
.cautionYou are not allowed to create a package
common
in the directoryapi
.No package may be a prefix of another package. For example, if you have one file with
package api.retail
, then you may not have a separate file withpackage api
.
├── Your Custom System
...
├── api
├── common_rules.rego //cannot have `package api` in `package api.retail`
├── retail
├── retail_rules.rego // package api.retail
├── common
├── common_rules.rego // must declare package `common`Packages can share a prefix like
package api.finance
,package api.retail
, and a package can have more than one module file.├── Your Custom System
...
├── api
├── finance
├── finance_rules.rego // must declare `package api.finance`
├── retail
├── retail_rules.rego
├── retail_more_rules.rego // must declare `package api.retail`
├── common
├── common_rules.rego
You cannot create a Rego file in any of the directories for a package, except the final directory containing the first Rego file for the package.
In the following hierarchy, the package common
is defined right at the top, so there is no top level package prefix that can be shared.
├── common
├── common_rules.rego