»Imports

Imports enable a Sentinel policy to access reusable libraries and external data and functions. Anyone can write their own custom import. Imports are what enable Sentinel policies to do more than look at only local context for making policy decisions.

Sentinel also comes with a set of standard imports. Standard imports are available to every Sentinel policy to help policy writers with common tasks such as working with the time, network addresses, and more.

»Using Imports

To use an import, you use the import keyword at the top of your policy. This specifies the name of the import you want to use. The application you're writing the policy for must already be configured to provide that import.

Details on imports can be found in the import section in the language reference.

In the example below, we use the time import:

import "time"

is_weekday = rule { time.now.weekday_name not in ["Saturday", "Sunday"] }
is_open_hours = rule { time.now.hour > 8 and time.now.hour < 17 }
main = rule { is_open_hours and is_weekday }

There are two options to develop a policy locally when using imports: configure Sentinel to launch the import on apply, or mock the import using mock. The former requires access to the import plugin while the latter is faster (doesn't have to launch a process) and doesn't require the plugin.

»Mocking Imports

The first option to developing policies locally is to mock the import values. When mocking an import, you don't need the import plugin available. This can be useful since some imports may not be available as a plugin and may only be available to the application the policy runs in.

Mocks are specified via the configuration file. Mocks can also be used for testing.

You can supply mock configuration one of two ways, depending on your use case:

• Using static data: Use this method when you can accurately represent your mock data in JSON and do not need to mock complex Sentinel features such as functions.
• Using Sentinel code: Use this method when using a static JSON object is insufficient, such as when you need to mock functions or other complex Sentinel features.

Our example does not require complex data to be mocked, so a static JSON object is sufficient:

{
  "mock": {
    "time": {
      "now": {
        "hour": 12,
        "weekday_name": "Tuesday"
      }
    }
  }
}

This can be used via the CLI:

$ sentinel apply -config=config.json policy.sentinel
Pass

»Launching Imports

If you have access to the plugin binary, you can launch the import. The benefit of this is that it is really using the import to test your policy. If the import changes, your policies may start failing. If you only use mock data and the import changes, your policies will still appear to work.

Imports are configured in the configuration file:

{
  "imports": {
    "time": {
      "path": "/path/to/sentinel-time-import"
    }
  }
}

This would require the sentinel-time-import binary. For this example this doesn't currently exist. We plan on writing one to provide for this section of the documentation.

»Custom Imports

You can also create your own imports.

If your policy decisions could benefit from accessing external information, then you can use custom imports as a way to do this.