Client Discovery
The Corsha Gatekeeper's Standalone Mode allows customers to observe API client traffic passively while not enforcing Corsha MFA on downstream requests. This mode is useful for identifying clients accessing the proxied service and discovering any API credentials or secrets within client traffic's headers via access logging. We call this workflow "Client Discovery". For more information on the data points included in the Gatekeeper's standalone mode access logging, see the Client Discovery Logging section.
Docker Deployment Configuration
To enable Standalone Mode for a Docker deployment of the Gatekeeper, add the following values to the proxy-controller configuration file proxy-config.yaml at the top level. Then re-deploy the Gatekeeper container.
http:
standaloneMode:
enabled: true
Helm Deployment Configuration
To enable Standalone Mode for a Helm deployment of the Gatekeeper, add the following values to the Gatekeeper Helm values.yaml file at the top level. Then re-deploy the Gatekeeper Helm release.
http:
standaloneMode:
enabled: true
Client Discovery Access Logging
When enabled, the Gatekeeper access logging entries will follow the following format.
"CORSHA_PROXY_ACCESS_LOG:[startTime] "requestMethod path protocol" responseCode responseFlags downstreamBytesReceived downstreamBytesSent duration upstreamServiceTime "forwardedFor" "userAgent" "requestId" "authority" "downstreamRemoteAddress" "upstreamRemoteAddress" authorizationPresent corshaCredPresent"
The table below describes the fields of an access log entry. All fields are delimited by spaces. Un-populated fields will appear as "-".
| # | Field | Description |
|---|---|---|
| 1 | startTime | Request (HTTP) or downstream connection (TCP) start time including milliseconds |
| 2 | requestMethod | The HTTP request method |
| 3 | path | The HTTP request path |
| 4 | protocol | The HTTP request protocol. The proxy supports HTTP/1.1 and HTTP/2 by default. To enable HTTP/1.0 support, see the Docker Config Values or Helm Config Values |
| 5 | responseCode | The HTTP response code. In case of an unsuccessful response code (4XX,5XX,etc.), there may be responseFlags in the log that indicate that the Proxy has detected an issue. For example, a 403 response code with a UAEX response flag means the request has an invalid Corsha Cred and was stopped by the Corsha mIDP. If there is no response flag, then the response code is from the upstream service |
| 6 | responseFlags | Additional details about the response or connection, if any. The response flags are explained in the Envoy response flag documentation. For TCP connections, the response codes mentioned in the documentation do not apply |
| 7 | downstreamBytesReceived | The size of the response body received for HTTP requests or the number of downstream bytes received on TCP connections |
| 8 | downstreamBytesSent | The size of the request body sent for HTTP requests or the number of downstream bytes sent on TCP connections |
| 9 | duration | Total duration in milliseconds of the request from the start time to the last byte out (HTTP) or the end of the downstream connection (TCP) |
| 10 | upstreamServiceTime | Time in milliseconds spent by the upstream host processing the request and the network latency between the Gatekeeper and upstream host |
| 11 | forwardedFor | The HTTP request X-Forwarded-For header. This standard proxy header contains a list of the IP addresses through which the request flowed before reaching the proxy. For more information, see the Envoy X-Forwarded-For documentation |
| 12 | userAgent | The HTTP request User-Agent header. This header identifies the application, operating system, vendor, and/or version of the requesting user agent |
| 13 | requestId | The X-Request-Id header. This header is populated by the Gatekeeper with a UUID to allow tracing of the request. For more information, see the Envoy X-Request-Id documentation |
| 14 | authority | HTTP request Authority header (HTTP/2) or Host header (HTTP/1.x). This header specifies the host and port number of the server the request is being sent to. In this context, it typically matches an upstream host the Gatekeeper was configured for |
| 15 | downstreamRemoteAddress | Remote address of the downstream connection. If the address is an IP address it includes both address and port |
| 16 | upstreamRemoteAddress | Remote address of the upstream connection. If the address is an IP address it includes both address and port |
| 17 | authorizationPresent | Sanitized HTTP request Authorization header check. This will be 1 if there were authorization credentials provided in the request, 0 if it was not |
| 18 | corshaCredPresent | Sanitized HTTP request X-Corsha-Cred header check. This will be 1 if there was a Corsha-Cred provided in the request, 0 if it was not |
Example Standalone Mode Access Log Entry:
CORSHA_PROXY_ACCESS_LOG:[2023-10-16T13:39:16.075Z] "POST /api/proxy/valid-corsha HTTP/1.1" 200 - 21 407 33 12 "10.22.0.46" "Go-http-client/1.1" "90dccfb7971dabac83d5b7dcc00c17d5" "mock-api-service.kaspean.biz" "10.22.0.46:0" "34.123.178.84:443" 0 1