To reduce integration overhead and standardize secure configurations of the Airlock Microgateway across web applications we recommend defining configuration templates. Typically the security team is still responsible for the company's security which is why they should create and maintain the templates.
- From an organizational point of view, it is highly suggested to do the following:
- Define the responsible team to maintain the templates.
- Ensure that the templates are aligned with the guidelines.
- Ensure that the templates do not contain prohibited settings.
- The project teams know how who to contact in case they have issues with the templates.
- From a technical point of view, the templates could contain settings like this:
- Organization-specific security defaults which differ from the Airlock Microgateway defaults:
- Custom allow rules
- Custom deny rules
- Security headers
- ...
- Settings that can be reused because of architectural decisions:
- Send certain HTTP headers to the upstream service
- Exclude certain paths or ports from being filtered (e.g. metrics or probes endpoints)
- Send all requests to Open Policy Agent through ext_authz
- ...
- ...
This allows easier integration and would be a good starting point for the project teams.
Templates have their lifecycle. This is because suggested settings change over time or new features become available in Microgateway. Therefore, it is highly recommended to put the templates under version control and include a label containing the version. This way it is possible to see which web applications still use the old templates and update them.