With the introduction of the YAML-based configuration format, new options have emerged to address previously challenging scenarios.
In line with goals for increased security operations efficiency, configuration management has garnered growing attention. Industry trends like declarative configuration, config-as-code, and GitOPs, to name a few, have gained significant traction and demand new configuration management capabilities:
- Automation
The functionality of central services, such as customer identity and access management, must adapt quickly and easily to changing application requirements. With today’s number of applications and their rate of change, manual configuration is both unable to keep up and too error-prone, especially under pressure.
The solution lies in automating simple, predictable and repetitive changes while reserving UI-based work to architectural decisions and solution design tasks.
- Config format as API
Automation depends on a standardised and stable configuration file format.
- Integration with external tooling
Products need additional tools to deliver on the promises of modern configuration management paradigms, as UI-based tools do not support the necessary operational workflows.
However, it is typically not in the customer’s best interest for a product to provide all tooling out-of-the-box. Tools often impose specific workflows that may or may not align with every environment’s requirements. Additionally, various products may use different, and potentially incompatible, configuration management approaches.
We believe it critical to provide only product-specific tools, for example to validate an automated configuration change before deployment, where such functionality cannot easily be handled by a more generic software.
For other needs, using prevalent standard tools is often the better choice.
Airlock IAM 8.4 introduces support for config automation, enabling customers to realise these benefits.
Challenging scenarios
Next to the above advantages, the new configuration model can help with solving two particularly difficult scenarios that Airlock IAM customers have faced:
- Concurrent configuration changes by multiple administrators
With the current Config Editor, an administrator loads the active configuration into their session and applies the changes based on their task. Once changes are complete, the configuration must be activated, becoming the new productive version and the base for future edits.
Unfortunately, due to the way the Config Editor operates, two administrators working in parallel (often on different configuration areas) can conflict: the latter activation may overwrite the earlier changes.
- Dedicated teams for specific configuration aspects
Some customers assign specific IAM configuration aspects to dedicated teams. A common example is key management, where a specialist team handles all encryption and signing keys in an infrastructure.
Currently, Airlock IAM does not enforce corresponding authorisations. It cannot prevent, for instance, a team managing user authentication and self-service flows from altering a token issuer signing key.
Let’s explore new ways to overcome these limitations.
Central config repository
To address the first scenario, we recommend using a central configuration repository, typically Git though other systems are also viable.
Each administrator works with their own, dedicated Config Editor. They retrieve the current configuration using standard mechanisms, e.g.
git clone https://repository.example.com/project/iam-configImagine Peter needs to adjust the configuration to support a new application. After finalising and validating the change, Peter pushes it to the repository. As no other administrator was active, there is no conflict. The automated deployment process takes the new version and distributes it to relevant Airlock IAM installations, which recognise and activate it.
Next, Sue is tasked to add a new option to the onboarding process. She does this by changing some steps in the self-registration flow. Simultaneously, Mary fixes an issue in user notification emails. As her change is very simple, Mary concludes her work in almost no time and pushes it to the repository.
When Sue later tries to tries to push hers, she is notified of the conflict. To resolve it, she simply pulls Mary’s version and merges the updates.
git pull
git merge
git pushThis is usually quick and non-interactive—unless they modified the same setting. In such cases, Git tools like WinMerge or Visual Studio Code offer user-friendly ways to resolve conflicts.
Splitting the configuration
Solving the second scenario requires a different strategy, still involving version control. Here, multiple repositories are used, one per configuration aspect.
Inherent authentication and access control allow to restrict different teams’ access to only their segments.
Two essential preconditions must be met:
- Validation of combined configuration
The deployment pipeline must validate the complete configuration after assembling from the individual parts from the different repositories. For one, it must verify that all references are available.
This functionality is included in the standard Airlock IAM delivery. Use the following command:
iam config validate -f <file>- Splitting the configuration by aspect: Initially, this requires manually dividing the main “iam-config.yaml” into several smaller files. Best practices on how to do this are beyond the scope of this article. A key challenge is that the Config Editor always outputs a single, merged configuration file, discarding any prior splits.
iam-split2files
While showcasing the capabilities of the new config model, the Airlock Pre-Sales team encountered the same challenge, namely to maintain configuration splits. To address this, we developed a lightweight tool that reconstructs a split configuration. It takes two inputs:
- A directory containing a previous version of the IAM configuration, split into files.
- A single file with the updated IAM configuration.
The tool updates the directory using the new configuration, preserving existing file assignments. The split is done so that concatenating the individual files reproduces the single configuration file exactly.
You can find iam-split2files in this repository on GitHub.
Airlock Consulting
If we have piqued your interest and you are interested in exploring the possibilities of the new config model and want tailored advice on how to adopt it in your environment, our consulting team is ready to assist you with your projects.