Airlock Microgateway DSL

Airlock Microgateway uses a domain-specific language (DSL) for the settings in the config.yaml file. The DSL is human-readable, descriptive, and can easily be stored in an SCM (source code management) such as Git.

Airlock Microgateway expects some files at a certain location without explicitly configure them. The files used implicitly are described in External files in dedicated folders.

• From a high-level overview, the DSL is split into the following parts:
• global settings, which are applied to the whole configuration. These settings are directly under the root node. Examples are:
• expert_settings
• license
• log
• metrics
• session
• listener settings, which defines the certificates, ports, names, etc. for which the Microgateway receives traffic. These settings are configured under apps[].virtual_host.
• security and integration settings such as filtering, authentication enforcement, or rewrite settings, which are applied to the traffic passed to the back-end. These settings are configured under apps[].mappings[].
• back-end settings, which define the back-end services that should receive the traffic. These settings are configured under apps[].mappings[].backend.

To track available options and to reduce possible editing errors, we have developed a JSON schema for automatic YAML for editing support, see Automatic YAML validation during editing.

All available DSL settings including all available configuration fields along with their default values and types are listed in the DSL reference table.

• The notation in the field column follows a special syntax:
• Arrays are denoted by [] (square brackets).
• The parent nodes of a field in the object structure are separated by dots.
• If allowed values for a field are limited, the options are listed in the description column.
• Allowed values are case-insensitive.

Example:
The field apps[].mappings[].threat_handling has three allowed values: "block", "terminate_session", and "notify". The default value is "block". That is, if the field threat_handling is not provided in the YAML file, the threat handling mode is set to "block" for the corresponding mapping. Configuring the field with a complete object structure could look like this:

apps:
  - virtual_host:
      name: webapp
    mappings:
      - name: webapp_public
        threat_handling: notify

The name attribute of virtual hosts, mappings, and back-end groups must be unique. If not specified, they are generated. Otherwise, ensure that the names are unique.

The fields in the DSL reflect features available in the Airlock Gateway appliance. Thus, if you need further documentation about the semantics of a specific option, also check the latest Gateway manual.