Microgateway Network Manager

The Microgateway Network Manager is injected as initContainer into the protected Pod and reconfigures the Pod's network with iptables. This way it is ensured that all traffic is first routed to the Microgateway Engine container.

The Kubernetes manifest file used for the injection is referenced in the Microgateway Operator configuration file with the parameter deployment.sidecar.networkManagerContainerTemplate. Generally, the defaults in the container template file should suit all environments and do not need to be adjusted. Nevertheless, there might be reasons to modify them which are mentioned in this article.

The networkManagerContainerTemplate

  • ImagePullPolicy
  • The behavior, when kubelet should pull (download) an image can be controlled with the imagePullPolicy. See (Kubernetes) ImagePullPolicy.

  • Resource Quotas
  • The resource limits, that should be applied to the container, can be configured with resources.limits. See (Kubernetes) Resource Quotas.

  • Iptables
  • The Microgateway Network Manager must be configured to use the corresponding iptables variant installed on the Kubernetes node. The variant that should be used can be controlled with the env variable IPTABLES.

    copy
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: airlock-microgateway-operator-operator-config
      namespace: airlock-microgateway-system
    data: 
       network_manager_container_template.yaml: |- 
        name: "$(NETWORK_MANAGER_NAME)" 
        image: "$(NETWORK_MANAGER_IMAGE)" 
        ...
        env: 
          - name: IPTABLES 
            value: "legacy"

    Parameter

    Default value

    Possible value

    env['IPTABLES']

    legacy

    legacy, nft

  • A few examples to make this clear:
  • Istio is deployed with istio-init container. Since istio-init is using iptables-legacy, our default can be left untouched.
  • Istio CNI is used on a Kubernetes node with iptables-legacy. Our default can be left untouched.
  • Istio CNI is used on a Kubernetes node with iptables-nft. Change our default to nft.
  • Microgateway is running on a Kubernetes node that uses iptables-nft. Change our default to nft.
  • Possible issues misconfiguration might cause:
  • When the Microgateway Network Manager cannot initialize iptables, log messages like the following are logged:
  • Failed to configure redirections to the Airlock Microgateway Engine","error":"failed to create new iptables chain 'AIRLOCK_REDIRECT' in table 'nat': running [/sbin/iptables -t nat -N AIRLOCK_REDIRECT --wait]: exit status 3: iptables v1.8.8 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)\nPerhaps iptables or your kernel needs to be upgraded. 
  • In some cases, the log messages do not indicate a problem, but the traffic is still not forwarded through the Microgateway Engine container and, therefore, not filtered.

The configuration files in the Config Map airlock-microgateway-operator-operator-config are only read at startup.

  • The Microgateway Operator must be restarted once the file operator_config.yaml or the referenced template files has been changed.
  • The protected Pods must be restarted when the referenced template files have been changed.