The articles in this chapter cover Microgateway CNI DaemonSet, Microgateway CNI plugin and the Microgateway Network Validator issues in a sidecar-based installation 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). - Labelled 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.
- Depending on the config.repairMode configured for the Airlock Microgateway CNI Helm chart, the CNI Installer will try to repair Pods with failing Network Validators.
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:
- 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 Sidecar-based preparations 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 section Sidecar-based preparations.
- Check the state of the Microgateway Network Validator container inside the web application Pod.
Network Validator sanity check
The Microgateway Network Validator is an initContainer deployed in the web application container. It uses the Microgateway Engine image with a different entrypoint. During the startup of the web application container, the initContainer generates a test request to verify that the Microgateway CNI plugin has configured the routing inside the application container.
- Status verification of the Microgateway Network Validator:
- On the application namespace, run
kubectl describe pod ...
.
Example output of a failed sanity check: - Check for the status (here: terminated with error) and the message text of the
airlock-microgateway-network-validator
container for more information. Note that the message depends on the problem detected and can differ from the example above. - If the web application Pod status fails due to a terminated Network Validator, this is a strong hint for a CNI plugin problem. We recommend checking the logs and installing the Microgateway CNI plugin before the web application Pod is deployed and running.
Testing a deployed web application
For more extensive testing of the deployment, routing and functionality of the Microgateway Engine, we recommend using test-requests to cover all three mentioned aspects.
- Secure a web application with Airlock Microgateway.
- Check the filtering and the traffic routing through the Microgateway Engine:
- Send one or more requests to the web application.
- Check the Microgateway logs to see whether the request has been logged.
Example output:
Further information and links
- Internal links:
- Pod is not ready
- Sidecar-based preparations