Sentinel
Override Files
As outlined in the configuration overview,
the normal behavior of Sentinel is to load all .hcl
files into a single
configuration object.
In addition to appending multiple configuration files, Sentinel allows for the
rare case of overriding configuration through override files. Override files
are any files that match either _override.{hcl,json}
or override.{hcl,json}
.
Sentinel will parse override files after it has loaded the primary configuration, and then process each override file in turn (in lexicographical order). All top level blocks other than test require the block to already be defined in the primary configuration. It will then attempt to merge the override block into the existing configuration.
Example
If you had a Sentinel configuration sentinel.hcl
that contained the following:
policy "main" {
source = "./main.sentinel"
enforcement_level = "advisory"
}
And you created a file override.hcl
that contained the following:
policy "main" {
enforcement_level = "soft-mandatory"
}
Sentinel will merge the contents of the override into the former, providing the following configuration:
policy "main" {
source = "./main.sentinel"
enforcement_level = "soft-mandatory"
}
Merging Behavior
The general rule, which applies in most cases, is:
- A top-level block in an override file merges with a block in a normal configuration file that has the same block header. The block header is the block type and any quoted labels that follow it.
- Within a top-level block, an attribute argument within an override block replaces any argument of the same name in the original block.
- Within a top-level block, any nested blocks within an override block replace all blocks of the same type in the original block. Any block types that do not appear in the override block remain from the original block.
- The contents of nested configuration blocks are not merged.
- The resulting merged block must still comply with any validation rules that apply to the given block type.
If more than one override file defines the same top-level block, the overriding effect is compounded, with later blocks taking precedence over earlier blocks. Overrides are processed in order first by filename (in lexicographical order) and then by position in each file.
Required Attributes
It is important to note that all attributes inside an override file are considered to be optional, meaning that an override file can itself fail validation rules for block types.