Troubleshooting for network routing issues in the application pod

The articles in this chapter cover Microgateway CNI DaemonSet, Microgateway CNI plugin and the Microgateway Network Validator issues and help with troubleshooting.

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.

1. The Microgateway CNI DaemonSet installs the Microgateway CNI plugin on each node (except the nodeAffinity or nodeSelector settings are configured otherwise).
2. 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.
3. 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.

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.
  The hostNetwork: 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 and nodeSelector of the Airlock Microgateway CNI and your application.

• Microgateway Network Validator:
• The image registry can be misconfigured, e.g., with an unsupported busybox 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 a nodeSelector can be configured in the CNI Helm chart so that the Microgateway CNI plugin is only installed on nodes with matching labels. See official Kubernetes node affinity documentation for more information.

The following list is logically ordered for fast fault finding if you encounter Microgateway CNI or routing problems.

1. 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).
2. 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.
3. Check the state of the Microgateway Network Validator container inside the web application Pod.