Airlock Microgateway opens up new ways to establish a DevSecOps process in your company, integrating security into your development pipeline across all stages. For you as a developer, this means you can (and should) use Microgateways already at an early stage for local deployment and testing. When Microgateways accompany your services from the beginning, it increases the security level throughout the whole development process while minimizing most of the potential risks, costs, and difficulties that often come with dealing with security issues at a nearly completed stage of development.
Let Airlock Microgateway handle the DevOps security and integration aspects and moving your service to production should come with no surprises, even better if it is deployed behind a central Airlock Gateway for the first time.
The previously outlined benefits only exist if Microgateway is used across all stages - from development to production environment. If e.g. Airlock Microgateway is solely used during development, but the final production environment will be protected by an Airlock Gateway appliance, your service must be re-integrated in the Gateway appliance.
- Reasons for that are:
- Airlock Gateway and Airlock Microgateway have different defaults which fit best for their individual use case.
- Global settings on Airlock Gateway, which are required for other applications, might affect the service you want to bring into production.
- DSL configurations for Airlock Microgateway cannot be read by Airlock Gateway. While there is a correspondence of features and rule sets, there is no automated way of importing DSL snippets.
- Although both products share the same core filtering components, there are subtle differences that could cause problems.
A long story short: Use the same setup/architecture in all stages to eliminate any additional risks and efforts to integrate a service.