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.
This page is about writing policies that use imports. If you're interested in creating a new import, please see the section on extending Sentinel for information on how to write modules and import plugins.
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:
Sentinel Playground
Loading the playground...
Press "Run" to get policy output
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 while the
latter is faster (doesn't have to launch a process for plugins) and
doesn't require the import.
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 to be 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 object is sufficient:
This can be used via the CLI:
Launching Import Plugins
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:
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.