Network Validator sanity check

The Microgateway Network Validator is a busybox initContainer deployed in the web application container alongside the Microgateway Engine sidecar. 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.

  1. Status verification of the Microgateway Network Validator:
  2. On the application namespace, run kubectl describe pod ....
    Example output of a failed sanity check:
    3. copy
    ...
Init Containers:
  airlock-microgateway-network-validator:
    Container ID:    containerd://47190516e4378b982f3ee854b60c3c95d933c1882b83bda246fa0352006e453e
    Image:           busybox:1.36.1-musl@sha256:f553b7484625f0c73bfa3888e013e70e99ec6ae1c424ee0e8a85052bd135a28a
    ...
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Message:      Traffic redirection to Airlock Microgateway Engine is not working.
Restart the pod after ensuring that hostNetwork is disabled and a compatible Airlock Microgateway CNI version is installed on the node.
Certain environments may also require additional configuration (see docs.airlock.com for more information).
      Exit Code:    1
      Started:      Fri, 03 Nov 2023 12:23:13 +0100
      Finished:     Fri, 03 Nov 2023 12:23:13 +0100
    Ready:          False 
...
  3. 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.
  4. 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.

  1. Secure a web application with Airlock Microgateway.
  2. 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.
    copy
    kubectl logs <POD> -c airlock-microgateway-engine

    Example output:

    details...
    { 
  "@timestamp": "2023-09-26T07:30:33.653+0000", 
  "ecs": { 
    "version": "8.5" 
  }, 
  "observer": { 
    "version": "4.0.2", 
    "product": "Airlock Microgateway", 
    "type": "waap", 
    "vendor": "Ergon Informatik AG" 
  }, 
  "log": { 
    "logger": "access", 
    "level": "info" 
  }, 
  "http": { 
    "version": "1.1", 
    "response": { 
      "status_code": 302, 
      "body": { 
        "bytes": 359 
      }, 
      "mime_type": "text/html", 
      "bytes": 1614 
    }, 
    "request": { 
      "id": "eaf65c64e9df3dbd07d32d211a58df71", 
      "bytes": 913, 
      "method": "GET", 
      "referrer": "https://myapp.com/", 
      "body": { 
        "bytes": 0 
      } 
    } 
  }, 
  "airlock": { 
    "response": { 
      "details": "ext_authz_denied", 
      "flags": "UAEX" 
    }, 
    "log_correlation": "[C1734][S14010283080019998636]", 
    "http": { 
      "response": { 
        "redirect_url": "" 
      }, 
      "request": { 
        "accept_language": "en-US,en;q=0.9,de-CH;q=0.8,de-DE;q=0.7,de;q=0.6" 
      } 
    } 
  }, 
  ...
  ...   
}