Custom System Packages
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:
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 describes its purpose (for example,
production
), contracts (for example,pci-compliant
), lifecycle (for example,release
), and other characteristics.monitor: A package that defines the results displayed in the Compliance pane for your System and in the Validate results pane. For more information on package monitor, see Compliance.
rules: A package where you write your policies.
system.log: A package where you specify the policy to remove any sensitive data before uploading the decision to the
package system.log
.test: A package used to write OPA unit tests. Run the unit tests with the Validate button in the Policy Editor.
dataset: A Data Source where you can create dynamic or static JSON data for your policies.
The Data Sources and packages provide a starting point for new users. You can delete these resources from your Custom System.
Reserved Packages
Styra DAS reserves a small number of package paths.
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
: Stock packages includerules
,test
, andmonitor
.
Limitations
With OPA, you can put any Rego package into any file in the file system, irrespective of the directory path. With Styra 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 example.
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
.- You 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`- You are not allowed to create a package
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