A2. Addendum: Google Cloud Functions Specificities

Due to Google Cloud Functions concept of ephemeral containers, pyrasp behavior is slighlty different and has a few limitations compared to other platforms. Specific settings must also be applied in the Google function configuration.

Settings

Machine Learning engines are quite resource intensive and require specific configuration settings

Memory

pyrasp requires additional memory to run with the lambda function. This is mostly due to the machine learning engines (and related libraries) used for XSS and SQL Injection detection. If XSS or SQL Injection detections are enabled, it is recommended to consider additional 140MB of memory function configuration.

Timeout

The pyrasp XSS and SQL Injection machine learning engines are loaded at the function startup, noticeably increasing the overall startup time (~5 seconds). If XSS or SQL Injection detections are enabled, the function timeout must be increased by minimum 5 seconds

Limitations

Beacons

Beacon is implemented in a different way for in pyrasp as containers are ephemeral.

Consequently beacons are sent in 2 specific cases:

• At agent startup

• When a request is received and the last beacon was sent in a time period greater than the value specified in the BEACON_DELAY parameter

Therefore, on low traffic functions, monitoring may report agents as down while they remain active (but didn't process any request in the BEACON_DELAY timeframe).

Latency

With all security modules enabled, the processing of a request doesn't add noticeable latency. However, when the instance is in "cold" state (meaning the container needs to be restarted), the processing of the request requires restart of the pyrasp module. This adds about 5 seconds latency to the global processing if the request.

Logs

Country of source IP is not resolved in security logs, this prevents from additional latency in the requests processing. The field in logs is set to an empty string.