Microgateway 5.2
Airlock Microgateway 5.2 expands support for the Kubernetes Gateway API, introduces geolocation-aware logging and policies, and enables identity-aware access control with opaque tokens. The release also strengthens software supply chain transparency and makes the product documentation easier to use.
Gateway API: Extended features
Airlock Microgateway 5.2 supports all HTTPRoute features tracked in the Kubernetes Gateway API implementation comparison.
- Full HTTPRoute support: Use the full range of HTTPRoute features covered by the Gateway API implementation comparison, without needing to check whether individual features are supported by Microgateway.
- A standard we help shape: Airlock contributes directly to the development of the Gateway API alongside companies including Google, Microsoft, Red Hat and Isovalent. We actively help define the standard.
Existing Kubernetes Ingress configurations can be converted into Gateway API resources with the ingress2gateway tool. Its airlock-microgateway emitter generates the corresponding Airlock Microgateway resources, providing a practical migration path from Ingress-based environments.
With Ingress NGINX archived and security maintenance having ended in March 2026, organizations now need a clear path towards a maintained successor. All supported Gateway API features are included in the free Airlock Microgateway Community Edition, no license needed.
GeoIP support
Airlock Microgateway 5.2 includes a bundled GeoIP database that resolves the client IP address to a country for every request. This information is available locally, without a subscription or requests to an external geolocation service.
- Greater visibility: Add the country to ECS-structured logs, giving existing SIEM queries and the built-in Grafana dashboards an additional dimension without changing the log pipeline.
- Simple header forwarding: Forward the country to the backend in a request header, so application teams do not need to integrate a geolocation library themselves.
- Country-specific policies: Use the country code in filtering or authentication policy conditions to implement country-specific behavior.
- Flexible database options: Use the bundled database at no extra cost or replace it with a commercially licensed one if greater accuracy or more frequent updates are required.
This gives platform, application and security teams geolocation information for logging and policy enforcement without additional integration effort.
Opaque token support
Airlock Microgateway 5.2 can now use opaque access tokens for identity-aware access control. Because an opaque token does not expose readable claims, Microgateway sends it to an OAuth 2.0 Token Exchange server for verification and receives a JWT containing the identity information required for further processing.
- Transparent user activity: Read the identity from the returned JWT and write it to the logs, keeping who did what and when visible even when the client presented an opaque token.
- Access control: Use the identity from the returned JWT to enforce access control.
- Identity propagation: Forward the identity to the upstream service, so the application does not have to resolve the token itself.
This provides greater flexibility wherever authentication takes place before the request reaches Microgateway and enables new use cases.
JWT validation for Token Exchange
JWTs returned by an OAuth 2.0 Token Exchange (RFC 8693) can now be validated using JWKS. RFC 8693 deliberately leaves validation of the issued token to the implementation, so the component consuming the token must verify it.
- Stronger security: Validate the signature against the issuer’s published keys before acting on the claims, blocking alg: none and algorithm-confusion attacks described in RFC 8725.
- Reliable authentication: When an opaque token is received and exchanged for a JWT, the identity it carries can be treated as authenticated. This makes the logs a reliable record of who did what and when.
JWT validation strengthens the security of Token Exchange and adds value to use cases built on opaque tokens.
Software Bill of Materials (SBOM)
Airlock Microgateway 5.2 is the first release to include a Software Bill of Materials (SBOM). It gives customers greater transparency into the software components used in the product and supports vulnerability management, compliance and software supply chain governance.
- Greater transparency: Get a structured inventory of the software components used in Microgateway.
- Compliance readiness: Support increasing regulatory expectations, including the EU Cyber Resilience Act (CRA).
- Long-term continuity: SBOMs will also be provided with future Microgateway releases as part of our ongoing product security approach.
The SBOM strengthens Airlock Microgateway’s fit for customers with growing software supply chain and compliance requirements.
Unified product documentation
The Microgateway documentation and Custom Resource Definition (CRD) reference are now delivered as one coherent documentation set, making relevant information easier to find.
- No context switching: Use one navigation and one search across the Microgateway documentation and CRD reference.
- Consistent look and feel: Move seamlessly between product documentation and reference content within the same design.
- Improved structure: Find relevant information more easily in a structure designed around readers’ needs.
The unified documentation lays the foundation for more extensive use-case guidance and administrator-focused content in future releases.
News from the Airlock Academy
On-site training 2026: Find all upcoming on-site trainings here.
Self-study labs: In 7 hands-on labs, you can explore the features of Airlock Microgateway step by step. Start now!
This new release introduces numerous improvements for greater security, flexibility, and seamless integration. We look forward to your suggestions and feedback as we continue to improve Microgateway!
Release video
Airlock Microgateway 5.2Watch our release video to find out about all the new features of Airlock Microgateway 5.2.
