In Google Cloud Armor I have multiple rules (+50). Below is the one with lowest priority number. It is based on bad_path URI example in Cloud Armor documentation
request.path.startsWith('/api/foo')
Deny 403
Priority: 1
Activated 1st November
In Google cloud logging, I believe the rule can be bypassed:
resource.type:(http_load_balancer) AND
jsonPayload.enforcedSecurityPolicy.name:(rules) AND
log_name="projects/foo_bar/logs/requests" AND
httpRequest.requestUrl="https://foo.example.io/api/foo" AND
The request pattern is:
https://foo.example.io/api/foo
The data below are sampled from 2 minutes:
| Outcome | statusDetails | http status | Priority | requestMethod | RequestSize | timestamp | receiveTimestamp |
|---|---|---|---|---|---|---|---|
| Deny | denied_by_security_policy | 403 | 1 | POST | 1188 | 12:49:48.746858Z | 12:50:24 |
| Deny | denied_by_security_policy | 403 | 1 | POST | 1191 | 12:49:48.297242Z | 12:50:02 |
| Allow | response_sent_by_backend | 200 | 60000 | POST | 1189 | 12:49:48.924442Z | 12:50:36 |
| Deny | denied_by_security_policy | 403 | 1 | POST | 1189 | 12:49:48.924468Z | 12:50:29 |
| Deny | denied_by_security_policy | 403 | 1 | POST | 1184 | 12:49:48.990177Z | 12:49:50 |
The below fields are same for all requests:
backend_service_name: Same for all above
forwarding_rule_name: Sane for all above
url_map_name: Same for all above
Example of 403 httpRequest
httpRequest: {
latency: "0.1"
remoteIp: "x.x.x.x"
requestMethod: "POST"
Requestsize: "1200"
requestUrl: https://foo.example.io/api/foo
responsesize: "315"
status: 403
userAgent: "XYZ"
}
Example of 200 httpRequest
httpRequest: {
latency: "0.5"
remoteIp: "x.x.x.x"
requestMethod: "POST"
Requestsize: "1202"
requestUrl: https://foo.example.io/api/foo
responsesize: "3150"
serverIp: "x.x.x"
status: 200
userAgent: "XYZ"
}
In Google cloud logging (audit logs)
cloudaudit.googleapis.com%2Factivity
resource.type="network_security_policy"
There are 3 cloud armor updates, but they are all a few hours after the timestamp above.
| Rule | ValidateOnly | Resource | timestamp | receiveTimestamp |
|---|---|---|---|---|
| 2500 | true | network_security_policy | 14:02:03 | 14:02:04 |
| 2500 | N_A | network_security_policy | 14:02:05 | 14:02:06 |
| N_A | N_A | network_security_policy | 14:02:11 | 14:02:12 |
What more steps can I take to understand why the rule is bypassed sometimes? The above example is not an isolated incident.
I don't think the "Cloud Armor POST body inspection limitation" is relevant here.