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.


There are different tools available to work with templates.

  • Some ideas are:
  • Copy the templates files and modify them (no real templating).
  • Use kustomize to use the template files and patch the desired settings.
  • Use yq and generate the new Kubernetes manifest files.
  • Create a helm chart for the templates.
  • Templating Kubernetes resources with code (Java, Go, Python, Node.js, C#).

The following website describes very well different options for templating and might be a help for making a decision: Templating YAML in Kubernetes with real code

From our point of view, kustomize is the easiest way to do templating and has a low entry barrier. This is why the example illustrates how such a solution could look with kustomize.

General tips for working with CRs

  • CLI:
  • Use kubectl explain <replace with CRD name> --recursive to list all available options and the YAML structure.
  • Check the CRD description texts with kubectl explain <replace with CRD name and path> of the available options for more details.
  • API Reference documentation:
  • Click on the link to open the CR-related documentation in a new browser tab or window: CRD Reference documentation. See also the API Reference documentation links at the end article.


We made a configuration example available on GitHub which can be used as a starting point for templating with kustomize. See (Github) Airlock Microgateway - Examples in the folder configurations/templating.

The example templates contains information on the project owner, project contact and the template version. This allows you to search for old template versions still in productive use and get in contact with the responsible project team if required.