[aws.cloudtrail] Fix ARN partition grok pattern for aws-cn/aws-iso* (7.2.x backport)

[efd6]

Backport of the fix from #20403 to the 7.2.x line.

The grok processor that extracts the session name from aws.cloudtrail.user_identity.arn used the pattern arn:(aws|aws-us-gov), which silently dropped aws-cn and aws-iso* partition ARNs, leaving user.changes.name unpopulated. This widens the pattern to arn:[a-z0-9-]+.

[github-actions]

✅ Elastic Docs Style Checker (Vale)

No issues found on modified lines!

---

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

[infra-vault-gh-plugin-prod]

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

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[elastic-vault-github-plugin-prod]

✅ Package owners are in sync with main.

[infra-vault-gh-plugin-prod]

💔 Build Failed

• Buildkite Build
• Commit: fa47672

Failed CI Steps

• Check integrations aws

History

cc @efd6

[vera-review-bot]

Severity: 🔵 Low confidence: high path: packages/aws/data_stream/cloudtrail/elasticsearch/ingest_pipeline/default.yml:1096

No handwritten fixture exercises the widened partition pattern; add an AssumedRole event with an aws-cn (or aws-iso*) sts ARN so the fix is covered by pipeline tests.

Details

The grok pattern now accepts any arn:[a-z0-9-]+:sts: partition, but a grep over the handwritten .log inputs under data_stream/cloudtrail/_dev/test/pipeline/ finds only arn:aws:sts: and arn:aws-us-gov:sts: session ARNs (the latter in test-us-gov-arn.log). The behaviour this PR fixes is therefore never exercised by pipeline tests, so a regression back to the narrower alternation would pass CI unnoticed.

Recommendation:

Add one AssumedRole event with a China-partition session ARN, either appended to an existing multi-line fixture such as test-assume-role-json.log or as a small new fixture alongside test-us-gov-arn.log, so related.user receives the session name; then regenerate expected output with elastic-package test pipeline -g. Example record:

{"eventVersion":"1.08","userIdentity":{"type":"AssumedRole","principalId":"AROAEXAMPLEID:cn-session","arn":"arn:aws-cn:sts::123456789012:assumed-role/ExampleRole/cn-session","accountId":"123456789012","sessionContext":{"sessionIssuer":{"type":"Role","principalId":"AROAEXAMPLEID","arn":"arn:aws-cn:iam::123456789012:role/ExampleRole","accountId":"123456789012","userName":"ExampleRole"}}},"eventTime":"2024-01-01T00:00:00Z","eventSource":"sts.amazonaws.com","eventName":"GetCallerIdentity","awsRegion":"cn-north-1","sourceIPAddress":"192.0.2.10","userAgent":"aws-cli/2.0","eventType":"AwsApiCall","recipientAccountId":"123456789012"}

---

🤖 AI-Generated Review | Vera Review Bot - v0.4.1 | 📚 Knowledge base: integration-skills

⚠️ Automated review — verify suggestions before applying.

[vera-review-bot]

Review summary

Issues found across the latest commits fa47672 — 2 low

• 🔵 No handwritten fixture exercises the widened partition pattern (link) (Unresolved)

Package-level:

• 🔵 Proposed commit message (the PR body's user.changes.name claim does not match this branch

  aws: widen CloudTrail ARN partition grok pattern to cover aws-cn and aws-iso* (7.2.x backport)
  
  Backport of the grok pattern change from #​20403 to the 7.2.x line.
  
  The grok processor that extracts the session name from
  aws.cloudtrail.user_identity.arn matched only the arn:aws and
  arn:aws-us-gov partitions, so identities from aws-cn and aws-iso*
  partitions were silently skipped and the session name was never added
  to related.user or used to populate user.email. The pattern is widened
  to arn:[a-z0-9-]+ so all current and future AWS partitions match.
  
  Bumps the package to 7.2.1 with a bugfix changelog entry.
  

A new commit triggers another review — at most once every 15 minutes. I skip the PR while it's approved or has merge conflicts.

🤖 AI-Generated Review | Vera Review Bot - v0.4.1 | 📚 Knowledge base: integration-skills

⚠️ Automated review — verify suggestions before applying.

[github-actions]

TL;DR

The Buildkite step Check integrations aws failed, but the prefetched log only contains teardown output and a generic exit status 1, so the concrete failing assertion/error is not present. Immediate action is to fetch the full step log (or the uploaded build/test-results/*.xml) and rerun once to determine whether this is a reproducible package-test failure or transient CI issue.

Remediation

• Retrieve the first failing test/error lines from the full Buildkite step log for build 49468 (the provided log starts after failure handling).
• Download and inspect the uploaded JUnit artifacts (build/test-results/*.xml) from the same build to identify the exact failing test case.
• Re-run the same step once; if it reproduces with the same failing test, apply a targeted fix in that code path, then rerun package checks.

Investigation details

Root Cause

Inconclusive with current artifacts. The only available Buildkite log file is truncated to post-failure cleanup and does not include the original command output that triggered the non-zero exit.

Evidence

• Build: https://buildkite.com/elastic/integrations/builds/49468
• Job/step: Check integrations aws
• Key log excerpt (/tmp/gh-aw/buildkite-logs/integrations-check-integrations-aws.txt):
  • --- [aws] failed
  • 🚨 Error: The command exited with status 1
  • then immediate artifact upload + stack teardown
• PR change scope is limited to:
  • packages/aws/data_stream/cloudtrail/elasticsearch/ingest_pipeline/default.yml:1093 (grok partition pattern widening)
  • packages/aws/manifest.yml:3 (version bump)
  • packages/aws/changelog.yml:2 (changelog entry)

Verification

• Not run locally in this environment because the failing CI step relies on Elastic stack containers and the provided artifacts are the authoritative source for this workflow.

Follow-up

If you share the full step output (or the JUnit XML content), I can map the exact failing assertion to a specific file/line and provide a concrete patch-level remediation.

---

What is this? | From workflow: PR Buildkite Detective

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.