CR Limits

Airlock Microgateway performs various size checks on requests with a default configuration to repel denial of service (DoS) attacks. The CR Limits can be used to configure these limit checks on the root level. All limits are calculated in bytes.

This CR needs to be referenced in the CR ContentSecurity.

Example configuration

For the default and an example configuration, see the latest API Reference information in chapter Limits.

  • WebSocket and gRPC currently use an unlimited (hard-coded) body size.
  • The pathLength limit is a general type and applies for parsed and unparsed requests.
  • JSON limits will only be applied if the JSON parser in the CR Parser is enabled.
  • Body size limits are applied as general.bodySize for unparsed requests (e.g., requests with unknown content type) or as individual bodySize​ per feature (e.g., multipart or JSON bodies).
  • Other limits, such as parameter size, are counted in parsed form.

The maximum headersLength count includes Envoy pseudo headers and can be configured in the CR SidecarGateway as described here in the section Limiting request headers length.

Size limits like bodySize, nameLength , etc., can be specified in bytes or Kubernetes memory limit units.

  • Examples of Kubernetes memory limits:
  • 1k = 1'000 bytes
  • 1Ki = 1'024 bytes
  • 1M = 1'000'000 bytes
  • 1Mi = 1'048'576 bytes

Limits can be deactivated with unlimited {} if not hard-coded. Keep in mind that this disables the denial of service (DoS) protection and therefore is not recommended in production environments.

Threat handling mode settings

When a request causes a block due to reaching the request size limit in Block mode, it is possible that the total request size is not fully logged. For example, it can happen that the actual parameter name length is not part of the logging information because the request size limit has already been reached before and the request is already blocked. This behavior is to mitigate the risk of being vulnerable to DoS attacks.

Detailed limit violations can be logged with settings.threatHandlingMode: LogOnly. Keep in mind that this disables the denial of service (DoS) protection and therefore is not recommended in production environments.

Logging based on threat handling mode settings

The logs may vary depending on the settings.threatHandlingMode. In Block mode, only the available information is logged to still protect against denial of service attacks. This could lead to some information being missing whereas in LogOnly mode, all limits-related information is logged.

The following examples show two types of limit violations, body size and JSON key length, in both threat-handling modes.
As expected, the body.size value is not shown in Block mode in opposition to the JSON key.length value (which requires parsing the JSON body for length calculation).

Block mode

LogOnly mode

# body size, block 
 
    "limits": { 
      "matches": [ 
        { 
          "blocked_data": { 
            "body": {} 
          }, 
          "rule": "Built-in: Request body size", 
          "threat_handling_mode": "block" 
        } 
      ] 
    },
# body size, logOnly 
 
    "limits": { 
      "matches": [ 
        { 
          "blocked_data": { 
            "body": { 
              "size": 219 
            } 
          }, 
          "rule": "Built-in: Request body size", 
          "threat_handling_mode": "logOnly" 
        } 
      ] 
    },
# JSON key length, block 
 
    "limits": { 
      "matches": [ 
        { 
          "blocked_data": { 
            "json_key": { 
              "json_path": "$['username']", 
              "key": "username", 
              "length": 12 
            } 
          }, 
          "rule": "Built-in: JSON key length", 
          "threat_handling_mode": "block" 
        } 
      ] 
    },
# JSON key length, logOnly 
 
    "limits": { 
      "matches": [ 
        { 
          "blocked_data": { 
            "json_key": { 
              "json_path": "$['username']", 
              "key": "username", 
              "length": 12 
            } 
          }, 
          "rule": "Built-in: JSON key length", 
          "threat_handling_mode": "logOnly" 
        } 
      ] 
    },

The article Access log field reference provides additional information listing all log fields including short descriptions.

If the request's body is not in UTF8, the body-size calculation will fail due to an internal check. In this case, no information about the body size is available.

Limit-based block and attack types in logs and metrics

In addition to the obvious block type limits, limit-based blocks (or potential blocks in LogOnly mode) can occur based on other Microgateway features that also make use of the configured limits and appear in logs and metrics. All configured limit types can trigger a single request block or multiple potential blocks in LogOnly mode.

  • At the time of writing, limit-related block or log counts can also appear based on the block_type labels:
  • openapi
  • graphql

For example, Airlock Microgateway Engine metrics can contain the following metric labels:

microgateway_http_downstream_rq_threats_blocked_total{block_type="graphql", attack_type="parameter_body_size", envoy_cluster_name="YourClusterName"}

The metrics block count in the example above has been triggered by a graphql query in a JSON body exceeding the parameter_body_size limit. The label metrics naming is closely related to the CR Limits configuration for intuitive understanding. For example, if a request exceeds the request.limited.general.bodySize value, the corresponding metric label for attack types would be general_body_size.

All Airlock Microgateway Engine metrics are listed in the reference article Available metrics in Prometheus format.

For access logging, see the Access log field reference article.