Skip to main content

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.

note

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 include rules, test, and monitor.

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.

note

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.

  1. The package api.retail must exist in a file located under the directory api/retail.

    ├── Your Custom System
    ...
        ├── api
            ├── retail
                ├── retail_rules.rego //must declare `package api.retail`

  2. The package common must exist in a file located under the top-level directory common.

    • You are not allowed to create a package common in the directory api.
    • 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 with package 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`

  3. 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