GeneralCodeStructure

Upon start, cloud active defense will perform two types of operations:

config update

Every second, Envoy will send a GET /CHANGE/ME request to configmanager (in docker-compose). Configmanager expects a path in the form /namespace/application. This path is properly specified when deploying to kubernetes.

• configmanager will return cad-namespace-application.json or, if not found, cad-default.json. This means that the default config file will always be returned if you're running in docker-compose.
• configmanager will append to the returned decoy config the content of config-namespace-application.json or, if not found, config-default.json. This means that the default config file will always be returned if you're running in docker-compose.

If the config content is different from what was last read, Envoy will load the new config and print on the console 'read new config'.

request processing

Every time a request is received, Envoy will call several events, in this order. The standard flow is highlighted in bold:

1. onHttpRequestHeaders:

   • saves some details (url path, cookies) in the global context
   • verifies 'inRequest' detect rules for http request header decoys (headers, url, getParams)
   • injects 'inRequest' header decoys

2. onHttpRequestBody (if exists):

   • verifies 'inRequest' detect rules for http request body decoys (postParams, payload)
   • injects 'inRequest' body decoys

3. onHttpResponseHeaders:

   • uses global context to verify 'inResponse' detect rules for http response headers
   • used global context to inject 'inResponse' header decoys

4. onHttpResponseBody (if exists):

   • uses global context to verify 'inResponse' detect rules for http response body
   • used global context to inject 'inResponse' body decoys

5. onHttpStreamDone:

   • for all decoys that triggered detection, send the related alerts.

going further

Proxywasm sdk Documentation about proxywasm