[Filebeat] googlecloud audit: use flattened type for request and response fields

[ynirk]

While ingesting gouglecloud audit logs we noticed mappings errors similar to #18465 where a same field can either be text or object.
Mapping errors mainly come from GKE control plan logs on the following fields:

• response.status (already handled in 7.9)
• response.metadata.labels.istio
• response.metadata.labels.app
• response.spec.volumes
• request.target
• request.instances
• request.spec.volumes
• request.metadata.labels.app

Also recently we encountered Limit of mapping depth errors on spec field (ex: response.spec.validation.openAPIV3Schema.properties.spec.properties.nodeSets.items.properties.volumeClaimTemplates.items.properties.status.properties.conditions.items.properties.status)

It would be helpful to do something similar to Cloudtrail #19121 and flatten response & request fields

[elasticmachine]

Pinging @elastic/siem (Team:SIEM)

[andrewkroh]

What's the version of Filebeat you were using when you encountered the Limit of mapping depth error?

[ynirk]

I'm using logstash with filters mapping filebeat ingestion pipeline - sorry for the confusion this one might not be relevant to filebeat

[andrewkroh]

No problem. Just wanted to make sure there wasn't an existing problem in the module. Because right now I expect the module to only create fields that we know are safely handled in the mapping and leave the rest in the raw event.original blob.

[botelastic]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.