The articles in this chapter cover Microgateway CNI DaemonSet, Microgateway CNI plugin and the Microgateway Network Validator issues and help with troubleshooting.
Routing configuration schematics
Routing all traffic through the Microgateway Engine is crucial for application security. The following drawing is a simplified schematic of the components working together for routing configuration and the initial routing sanity check.
- The Microgateway CNI DaemonSet installs the Microgateway CNI plugin on each node (except the
nodeAffinity
ornodeSelector
settings are configured otherwise). - Annotated web applications are deployed with a Microgateway Engine and a Microgateway Network Validator. The Microgateway CNI plugin configures the routing within these web application Pods.
- The Microgateway Network Validator initContainer performs a sanity check that fails if the Microgateway CNI plugin is not working/installed or is not ready when the web application pod is deployed and running.
Network routing can fail for different reasons, mainly configuration issues. A good starting point is to check the basic configuration requirements as listed below.
Basic requirements
Check the following basic configuration requirements, depending on your deployment.
- Web application Pod:
- For application Pods
hostNetwork: false
must be configured. Otherwise, the Microgateway CNI plugin is not executed.
ThehostNetwork: true
configuration option is currently unsupported by Airlock Microgateway. - Install the web application pod only on nodes that have the Microgateway CNI plugin installed. Check the
nodeAffinity
andnodeSelector
of the Airlock Microgateway CNI and your application.
- Microgateway Network Validator:
- The image registry can be misconfigured, e.g., with an unsupported netcat image (see
networkValidator.image
in the Operator Helm chart). Refer to the example configuration in section How to use your custom image registry. - Port
19003
must be reserved in the web application Pod for the Network Validator initContainer. The port is required for the initial sanity check of the routing in the web application Pod.
- Microgateway CNI plugin:
- The Microgateway CNI plugin must be installed on the node and be in working order before the web application Pod is deployed.
- Optional: A
nodeAffinity
and/or anodeSelector
can be configured in the CNI Helm chart so that the Microgateway CNI plugin is only installed on nodes with matchinglabels
. See official Kubernetes node affinity documentation for more information.
Recommended quick check sequence
The following list is logically ordered for fast fault finding if you encounter Microgateway CNI or routing problems.
- As part of each Airlock Microgateway installation, ensure the Microgateway CNI DaemonSet is properly installed and running.
- Before installation:
- Ensure the chosen
<environment>-values.yaml
preset (GKE, OpenShift, ..) is correct for your cluster type. - Ensure the version of the Microgateway CNI DaemonSet and the Microgateway Operator match to avoid incompatibilities (e.g., with updated routing configuration).
- Ensure the Microgateway CNI plugin is installed on the target node when the web application with the Microgateway Engine is deployed, as described chapter Installation.
- Check the state of the Microgateway Network Validator container inside the web application Pod.