[GCP][CDR] Add actor.entity.id and target.entity.id fields to audit logs

[kubasobon]

Proposed commit message

Add actor.entity.id and target.entity.id fields to properly identify events' origins and targets. It is a requirement for https://github.com/elastic/security-team/issues/9352.

Warning

To be merged after #11762. Please remember to change the base to main.
Merged. The base is now main.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Related issues

• Required by https://github.com/elastic/security-team/issues/9352
• Closes https://github.com/elastic/security-team/issues/10398

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[kubasobon]

@romulets The issue stated origin.id and target.id, but I've seen actor and target.ENTITY.id formats elsewhere. Can you confirm what is the one we're going with?

[efd6]

Can you confirm what is the one we're going with?

This is the kind of question that emphasises why we want to be working from accepted specifications. Decisions should already have been made and be publicly visible so that we know that we are all on the same page and so that our users know what behaviour they can expect.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: a74d88823bcce86e1d3039ca4ebbba02f3b0ba9b

History

• 💔 Build #19368 failed 47a0c46b00a4da697a4929de393c6feb2d02d1f6
• 💚 Build #19032 succeeded d4a3d0b
• 💔 Build #19015 failed a84fd8f
• 💔 Build #19014 failed ae5fd2c

cc @kubasobon

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
96.6% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[kubasobon]

@elastic/obs-service-integrations & @elastic/security-service-integrations I would appreciate someone taking a look here :)

[ishleenk17]

I had some Nits and those are addressed. Thanks.
The changes mainly pertain to GCP audit logs owned by Security Service Integrations. I am providing code owner approval from obs-infraobs side.
Please get the code reviewed from security team before merging.

[chrisberkhout]

Minor question and comment.
Already fine.

[chrisberkhout]

Fine as is, but here's an alternative:

Suggested change

	boolean isKubernetes = false;
	if (ctx.json?.resource?.type != null) {
	String typ = ctx.json.resource.type;
	isKubernetes = (typ == "k8s_cluster" || typ == "gke_cluster" || typ == "kubernetes");
	}
	boolean isKubernetes = ["k8s_cluster", "gke_cluster", "kubernetes"].contains(ctx.json?.resource?.type);

[kubasobon]

That's a nice, concise way of setting the flag. I'll keep it in mind for the future.

[chrisberkhout]

Are the outer ifs necessary here? is it okay to just collect entities from any of these locations if they exist?

[chrisberkhout]

This could potentially be reduced to something closer to a short list of locations by using Streams, similar to this.

[kubasobon]

We were using streams for similar PRs, but we got pointed toward this approach in #11762.
I agree that nested if clauses are an overkill and we could just try to grab everything. However this way we get a nice readability bump, I think. It tells a story of where each value originates from, and lays solid groundwork for any future PRs.

[elastic-vault-github-plugin-prod]

Package gcp - 2.40.0 containing this change is available at https://epr.elastic.co/package/gcp/2.40.0/