WORKSPACE_ALERTS ingests only a subset of alerts, and WORKSPACE_CHROMEOS ingests no data (Third Party API feeds)

Hi Omskirt,

I tested these feeds in my lab environment and checked the default parser configurations in SIEM Settings > Parsers and the docs. Please find my answers in line:

1. Does the WORKSPACE_ALERTS feed ingest all Alert Center alert types, or only a subset? Are there other unsupported alert types besides GMAIL_BLOCK_MESSAGE?

The WORKSPACE_ALERTS feed queries https://alertcenter.googleapis.com/v1beta1/alerts with filter=createTime > "<timestamp>" and orderBy=createTime desc without filtering by alert type, so it pulls every alert returned by the Alert Center API in that creation time window. However, if you check the default WORKSPACE_ALERTS parser in SIEM Settings > Parsers (and the supported alert types table in the Collect Google Workspace logs documentation), the default parser only maps 17 data.@type payload schemas (GoogleOperations, DomainWideTakeoutInitiated, AppsOutage, ReportingRule, AppMakerSqlSetupNotification, DeviceCompromised, MailPhishing, BadWhitelist, AccountWarning, StateSponsoredAttack, SuspiciousActivity, ActivityRule, DlpRuleViolation, SensitiveAdminAction, AppSettingsChanged, ApnsCertificateExpirationInfo, and UserChanges when data.name matches one of eight user or admin lifecycle strings). When an alert uses another documented @type schema (such as AccessApproval, AbuseDetected, AccountSuspensionWarning, ClientSideEncryptionServiceUnavailable, DriveSyncStateChanged, MandatoryServiceAnnouncement, PhishingSpike, or VoiceMisconfiguration), uses an unmapped UserChanges rule name, or omits the data.@type field altogether (such as Gmail potential employee spoofing, which only populates top level type and source fields), the default parser hits a drop { tag => "TAG_UNSUPPORTED" } statement. In SecOps, TAG_UNSUPPORTED is recorded under drop_reason_code in datalake.ingestion_metrics rather than incrementing the parsing or validation error counters on the Data Ingestion and Health dashboard, and SecOps falls back to parse less JSON auto extraction. Those alerts are still indexed in your tenant as bare GENERIC_EVENT records where metadata.product_name, metadata.product_event_type, and security_result are empty and the raw JSON keys are placed under extracted.fields, which you can see in UDM Search with metadata.log_type = "WORKSPACE_ALERTS" AND metadata.product_name = "".
 

2. Does the impersonation user need Super Admin to see all alert types and ChromeOS devices through the APIs, or are the documented custom role privileges enough?

The impersonated Workspace user does not need Super Admin for either feed, and the Alert Center API (v1beta1) is available across all Google Workspace editions. For WORKSPACE_ALERTS, a custom admin role with Alert Center > Full access > View access is sufficient. For WORKSPACE_CHROMEOS, the Chrome Management > Settings privilege listed in the SecOps setup guide only covers Chrome policy settings and does not grant access to the Admin SDK Directory ChromeOS devices inventory endpoint (GET https://admin.googleapis.com/admin/directory/v1/customer/{customerId}/devices/chromeos). If you use a custom role instead of Super Admin, the impersonated user needs the Admin API privilege Devices > Chrome OS Devices > Read (or Services > Chrome Management > Manage Devices) assigned at the root organizational unit.
 

3. Does the WORKSPACE_ALERTS feed backfill existing alerts, or only alerts created after the feed is set up?

The WORKSPACE_ALERTS feed runs on an hourly schedule and does not backfill historical alerts. When the feed runs for the very first time, it starts from a 1 hour lookback window prior to initial execution and queries the API using filter=createTime > "<timestamp>". Because the filter evaluates createTime rather than updateTime, any alert created more than 1 hour before your feed was first enabled will not be pulled even if the alert is updated later in the console. That is why pre existing Suspicious login (which the Admin Console UI displays as Suspicious login blocked while the API sends Suspicious login), Leaked password, and Device compromised alerts sitting in your console were not ingested, even though those three alert types map to AccountWarning and DeviceCompromised and parse into USER_LOGIN and GENERIC_EVENT records for newly created alerts.

4. Is it expected for one Workspace alert to produce two UDM events, or does that point to a duplicate feed or parser behavior?

The default WORKSPACE_ALERTS parser in SIEM Settings > Parsers only has a single output block, always sets metadata.event_timestamp to the alert's createTime, and never sets or modifies metadata.asset_namespace because the namespace is stamped by the feed configuration prior to normalization. There are two ways you will see a pair of events a few milliseconds apart across your two namespaces when an alert triggers. In Google Workspace, both User's password changed and ActivityRule alerts are generated by rules that evaluate underlying Workspace audit events. When a password changes or an activity rule triggers, your active WORKSPACE_ACTIVITY feed ingests the underlying Admin Audit (CHANGE_PASSWORD) or Rules Audit (action_complete) event under the namespace configured on your WORKSPACE_ACTIVITY feed, and a few milliseconds later Alert Center generates the corresponding alert (UserChanges or ActivityRule), which your WORKSPACE_ALERTS feed ingests as USER_CHANGE_PASSWORD or GENERIC_EVENT under the namespace configured on your WORKSPACE_ALERTS feed. If both events in UDM Search show metadata.log_type = "WORKSPACE_ALERTS", then a second WORKSPACE_ALERTS feed or external collector configured with your previous namespace is still polling the API, and whenever Alert Center updates the alert's etag or updateTime between polls, the raw JSON payload changes enough to bypass deduplication and index under both namespaces.

 

5. For WORKSPACE_CHROMEOS, is the feed expected to return data when the only enrolled ChromeOS devices are [Meet hardware / N devices]? Is there a known way to confirm what the feed is receiving when it shows "Completed" but nothing is ingested?

The WORKSPACE_CHROMEOS feed polls https://admin.googleapis.com/admin/directory/v1/customer/{customerId}/devices/chromeos once every 24 hours. When that endpoint returns HTTP 200 with an empty chromeosdevices list, the API call succeeds so the feed status shows Completed, and because 0 records are returned nothing is sent to the normalizer or displayed on the Data Ingestion and Health dashboard. Managed Chrome browsers enrolled through Chrome Enterprise Core appear under Devices > Chrome in the Admin Console, but they live under the /devices/chromebrowsers API resource rather than /devices/chromeos, and Google Meet hardware appliances only appear in /devices/chromeos if they are standard ChromeOS devices enrolled with a Chrome Enterprise Upgrade license. You can confirm what the API returns for your impersonated user by testing https://admin.googleapis.com/admin/directory/v1/customer/my_customer/devices/chromeos with curl or the Google OAuth 2.0 Playground using the https://www.googleapis.com/auth/admin.directory.device.chromeos.readonly scope. Keep in mind that once /devices/chromeos does return device records, the WORKSPACE_CHROMEOS parser outputs ASSET context records into the Entity Graph (metadata.entity_type = ASSET and metadata.product_name = "ChromeOS") rather than UDM events, so they will only appear when querying entity context rather than standard UDM event searches.

Thanks,

-Ben