Configuration management in Airlock IAM
This chapter describes the configuration management capabilities of Airlock IAM. The Config Editor, supported configuration management concepts, config formats, and features to support configuration automation.
Note that this chapter is only about the main IAM configuration, i.e., the XML or YAML configuration, or - covering the same - everything that can be configured using the Config Editor.
It does not cover Application parameters.
Configuration management concepts overview
The Airlock IAM configuration can become very complex and large. To make its maintenance more feasible in the long run, it is important to use supported configuration concepts correctly.
The following table gives a short overview of supported configuration concepts.
Concept | Description and usage |
|---|---|
Configuration environments allow centralized management of similar configurations. It is, for example, used to manage a configuration for multiple stages (test, acceptance, prod) or similar IAM instances. Environment-specific settings are defined at configuration time in the Config Editor. | |
Using configuration contexts, variants in the configuration can be chosen at runtime typically based on the properties of the HTTP request or session. It is used to model few and small differences within an IAM instance. Context-specific settings are defined at configuration time in the Config Editor. | |
Configuration variables allow outsourcing parts of the configuration to environment variables. Such variables can be used to model few and small differences of similar instances. The feature is used to account for values that are, for example, undefined until startup (e.g. container instantiation) or to keep differences between similar instances separate from the main IAM configuration. | |
Configuration automation features include the YAML file format, snippets, and command-line interfaces (CLIs). The features allow for automated configuration management outside Airlock IAM using scripts, config pipelines, or alike. The features may be used to support config as code and GitOps patterns to provision modern infrastructures. The snippet feature allows to modularize of the IAM configuration and may also be used with the Config Editor. | |
Storing sensitive configuration values in cryptographically protected files outside the main configuration. Use this feature to ensure that prod secrets are only on the prod environment. | |
The Config Editor is a web UI used to configure Airlock IAM. It provides strong guidance, configuration validation, and documentation. As IAM configurations are typically quite complex, it is recommended to put together the initial configuration and apply non-trivial modifications using the Config Editor. | |
Application parameters - also known as instance properties - are high-level settings that are not part of the main configuration. They are not addressed by the above-mentioned configuration management concepts. |
Configuration file formats (YAML, XML)
Airlock IAM supports multiple configuration formats for its main configuration: YAML and XML.
Format | Description |
|---|---|
XML | The XML format ( It is an internal format, i.e. not an API and not designed for manual or automated editing outside IAM components. |
YAML | The YAML format ( |
Recommendation: Use YAML instead of XML
Features supporting config automation (CLIs) and config modularization (snippets) only work with YAML. Upcoming config automation features are very likely to work only with YAML.
If using the XML format, it is recommended to migrate to the YAML format.