system/auth: extract group.name and set event.action for groupadd/groupdel

[Tacklebox]

Summary

Fixes #20063

Two bugs in the system.auth ingest pipeline for groupadd and groupdel events:

• group.name not extracted from the additional message formats Linux emits alongside the primary new group: line:

  • group added to /etc/group: name=fleet, GID=1234 (groupadd)
  • group added to /etc/gshadow: name=fleet (groupadd)
  • group 'fleet' removed from /etc/gshadow (groupdel)
  • group 'fleet' removed from /etc/group (groupdel)

• event.action never set for groupadd or groupdel events. The pipeline was correctly setting event.category: iam and event.type: [group, creation/deletion] but left event.action empty.

Changes

• Add grok-groupadd processor (conditional on process.name == 'groupadd') to extract group.name (and group.id where present) from the /etc/group and /etc/gshadow message formats.
• Add grok-groupdel processor (conditional on process.name == 'groupdel') to extract group.name from group 'xxx' removed from /etc/... messages.
• Add event.action: group-added for groupadd and event.action: group-deleted for groupdel.
• Update all affected pipeline test expected outputs.
• Add new test-groupdel.log test fixture covering the exact message formats from the issue.

Test plan

• All existing system/auth pipeline tests pass (elastic-package test pipeline)
• New test-groupdel.log test confirms group.name and event.action are populated for both groupadd and groupdel messages

🤖 Generated with Claude Code

[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.

[elastic-vault-github-plugin-prod]

✅ All changelog entries have the correct PR link.

[nicholasberlin]

Human Review

Finding 1 seems worth doing to avoid the same issue coming up later for a slightly different log line.

Finding 2 seems fine to me.

PR Review: #20606 — system/auth: extract group.name and set event.action for groupadd/groupdel

Author: Tacklebox
Branch: system-auth-groupadd-groupdel-fixes -> main
Commits: 1 | Files changed: 11 | +198 -1
URL: #20606
Reviewed commit: 0519830
Reviewed by: claude-fable-5-thinking

Summary

Fixes #20063 by adding two conditional grok processors to the shared message.yml auth pipeline that extract group.name (and group.id where present) from the /etc/group and /etc/gshadow message variants of groupadd/groupdel, and by setting event.action: group-added / group-deleted based on process.name. The change is correct, consistent with the pipeline's existing patterns, and well covered by tests. I verified the grok patterns against every groupadd/groupdel message in the fixtures, and confirmed that all five test inputs containing such messages had their expected outputs updated — none were missed.

Verification details:

• The new grok patterns correctly match all fixture messages: group added to /etc/group: name=tsg, GID=1003, group added to /etc/gshadow: name=tsg (optional GID group works with the non-greedy DATA pattern), and both group 'fleet' removed from /etc/{group,gshadow} variants.
• group.id is extracted as a string, consistent with the pre-existing new group: name=..., GID=... pattern and the ECS keyword mapping.
• The set processors for event.action run late in the pipeline and are keyed on process.name alone; I checked all earlier event.action setters (chauthtok, gpasswd, usermod, userdel, faillock, session open/close, SSH script) and none can realistically fire for groupadd/groupdel messages, so no clobbering occurs.
• Placement and style (tags, ignore_missing/ignore_failure, conditional on ctx.process?.name) match the neighboring usermod/userdel/gpasswd processors; action values follow the pipeline's kebab-case convention (group-user-added, group-member-removed, etc.).
• Manifest bump (2.22.2 -> 2.22.3) and changelog entry are consistent; linking the changelog to the issue rather than the PR has precedent in this file, and the repo's changelog-link CI check passes.
• The new test-groupdel.log-config.yml correctly uses dynamic_fields for @timestamp, so the year-less syslog timestamps won't cause failures when the year rolls over.

Findings

Minor

1. The third groupdel syslog line is not covered. shadow-utils groupdel emits three lines on success: group 'X' removed from /etc/group, group 'X' removed from /etc/gshadow, and a final summary group 'X' removed (see SYSLOG ((LOG_INFO, "group '%s' removed\n", group_name)) in src/groupdel.c). The new pattern anchors on removed from /etc/(?:group|gshadow)$, so the summary line gets event.action: group-deleted but no group.name. Adding a second pattern (^group '%{DATA:group.name}' removed$) or making the suffix optional would close the gap; the existing userdel grok already uses an unanchored ^removed (?:shadow )?group '...' pattern as precedent. Not blocking — the two formats reported in the issue are fully handled.

2. event.action is asserted for unparsed groupadd/groupdel messages. Because the new set processors key on process.name only, any message from these processes — including failure messages or the literal this is the message fixture in test-host-syslog-processor.json — gets group-added/group-deleted. This mirrors how the pipeline already sets event.category: iam and event.type: group/creation/deletion unconditionally for these processes, and ECS treats event.action as the attempted action (outcome is carried separately in event.outcome), so this is defensible and consistent. Noting it only because it is a semantic choice a maintainer may want to confirm.

Verdict

APPROVE — correct, well-tested fix that follows the pipeline's established conventions. The two minor notes are optional improvements, not blockers.

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: 0519830

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request