How the Graylog Google Workspace input connects Workspace audit logs
If you need Google Workspace audit trails in your central Graylog, the supported route is the Google Workspace input, which is an Enterprise pull input. Graylog Open alone does not include it, so the license decision comes first. The input does not read Workspace directly. It reads Workspace logs that have been exported to Google BigQuery, and it deletes them from BigQuery after ingestion. That deletion matters for retention planning: anything you need to keep for longer must be archived elsewhere before Graylog takes it, or you must confirm your own retention arrangement in BigQuery. The starting point is the Workspace BigQuery export, which an administrator enables in the Admin console. Until that export is running and writing to a dataset, there is nothing for Graylog to pull.
The moving parts sit in three places. In Google Cloud, you need a project with billing enabled, a BigQuery dataset that receives the export, and a service account granted the BigQuery Editor role so the input can read and delete the exported tables. In the Admin console, you confirm which Workspace services feed the export. In Graylog, the Enterprise license must be active before the input appears and works. Confirm with Graylog and with your Google account team which Enterprise tier and license size your event volume requires, since the pricing page ties licensing to processed data rather than users or devices. Also confirm the exact BigQuery roles and dataset location your organization's policies allow, because a broader role than the input needs is a common finding in access reviews.
Decide early who owns the Google Cloud project, the service account key and the dataset, and how that key is rotated and stored. Graylog and BigQuery are separate billing and access boundaries, so a change in one can silently stop ingestion. Check that the export is delivering rows before you configure the input, and check again after the first pull to confirm that deletion behaves as expected. Ask your Google Cloud partner or internal team to estimate BigQuery storage and query charges for your Workspace volume, since those costs are billed by Google and recur with usage.
What you need before configuring the Google Workspace input
The Google Workspace input reads audit logs from BigQuery rather than calling Google directly, so the work starts in Google Cloud and the Workspace Admin console before Graylog is touched. Each card below is a prerequisite or decision that has to be settled first, and each one is easier to fix before configuration than after.
Google Cloud project with billing
The export lands in BigQuery, which only runs inside a Google Cloud project, and that project must have billing enabled. Decide which project will own the dataset, who holds billing administration on it, and whether it is separate from projects that run production workloads. Ask your Google Cloud administrator to confirm the billing account and cost center before the export is turned on, because BigQuery charges accrue from the moment data starts arriving.
Service account with BigQuery Editor
Graylog authenticates to BigQuery as a service account that holds the BigQuery Editor role. Create a dedicated account for this input rather than reusing a person's credentials or a shared automation account, so the key can be rotated and audited on its own. Confirm with your security team how the JSON key will be stored in Graylog and who can view it, since the role allows the account to read and delete data in the dataset.
BigQuery dataset for audit logs
The input reads from a BigQuery dataset that receives the Workspace export, and it deletes records after ingestion. That makes the dataset a transient handoff rather than an archive. Plan the dataset location and access controls with your data governance team, and do not treat it as a retention store. If you need Workspace logs kept for a set period, that retention has to be designed separately in Graylog or in your own archive.
Workspace BigQuery export enabled
The export is switched on in the Google Workspace Admin console, where you choose the Google Cloud project and dataset that receive the logs. A Super Admin or a delegated administrator with access to the export settings must make this change. Confirm which Workspace logs your organization needs, because the export setting determines what arrives in BigQuery, and Graylog can only read what the export provides.
Graylog Enterprise license
The Google Workspace input is a Graylog Enterprise pull input, so it does not run on Graylog Open alone. Confirm with Graylog that your license includes this input before you design the pipeline, because a deployment without the license will not show it as an option. The licensing decision also determines whether the matching content pack and other Enterprise features are available to your team.
Supported Graylog 7.x release
Plan the input against a Graylog 7.x release that your team has validated, and check the Graylog documentation for the version your environment runs. The current documentation covers version 7.2, but your server nodes, MongoDB and search backend must match the compatibility matrix for that release. Confirm these versions with your Graylog support contact before you schedule the configuration work.
Configuration sequence from Google Cloud to the Graylog input
This sequence connects a Google Workspace tenant to Graylog through a BigQuery export, with a check at each step so the team knows the data path works before it relies on the input. It runs in the order the pieces depend on each other: project, service account, dataset, Workspace export, then the Graylog input and a test search.
Select or create a billing-enabled Google Cloud project
A Google Cloud administrator selects an existing project or creates a new one, and confirms that billing is attached to it. The Graylog Google Workspace input requires a project with billing, so a project without billing will block the later steps. Keep the project dedicated to log export if your security team wants separate ownership, access and cost tracking for this data. Done when the project appears in the console with an active billing account linked and the administrator can open the BigQuery page for that project.
Create the service account and grant BigQuery Editor
Create a service account in the project that Graylog will use to read the exported Workspace logs, then grant it the BigQuery Editor role. The input's documentation names this role, so use it as the starting point and confirm with your own security reviewers whether a narrower custom role is acceptable in your environment. Generate a JSON key for the service account and store it in your secrets manager, since that key is the credential you will paste into Graylog. Done when the service account is listed with the BigQuery Editor role and the key file is saved outside the project's shared folders.
Create the BigQuery dataset for Workspace logs
Create a BigQuery dataset in the project to receive the Workspace audit export. Choose a location that matches your data residency requirements and record the dataset name, since you will enter it in the Graylog input configuration. Confirm that the service account can see the dataset by opening its sharing or permission settings. Done when the dataset is visible in the BigQuery explorer, its name and location are written in your change record, and the service account appears with access to it.
Enable the Workspace BigQuery export in the Admin console
A Google Workspace super administrator enables the BigQuery export in the Admin console and points it at the project and dataset created earlier. The export is configured at the Workspace level, so this step needs an administrator with that privilege and cannot be completed by the Graylog team alone. Once enabled, Google creates export tables in the dataset as Workspace events are written, which can take time to appear, so plan to check later rather than expecting rows immediately. Done when the Admin console shows the export as enabled for the chosen project and dataset, and the first export table appears in BigQuery.
Verify the export table and its events in BigQuery
Before touching Graylog, confirm in BigQuery that the Workspace export table exists and contains rows with recent audit events. Run a simple query limited to a small number of rows and check that the timestamps and event types match actions you took in the Workspace admin or user console, such as a test sign-in or a settings change. If no table appears, recheck the Admin console settings and the dataset location before going further, since the Graylog input can only read what the export writes. Done when a query returns recent Workspace audit rows from the dataset.
Add the Google Workspace input in Graylog
In Graylog, a user with permission to manage inputs adds a Google Workspace input, which requires an Enterprise license. Enter the service account credentials, the project and the dataset name, then choose the polling settings the input offers. Confirm that your Graylog deployment has the Enterprise license applied before you expect the input type to appear. Start the input and check its status page for a running state with no credential or permission errors. Done when the input shows as running and reports no authentication failures in the input diagnostics.
Confirm Workspace events arrive in a Graylog search
Run a search in Graylog over the time range since the input started and filter on the source or input name for the Workspace input. Compare a few returned messages against the rows you checked in BigQuery and against a test action you perform in Google Workspace. Note that the input deletes data from BigQuery after ingestion, so do not rely on BigQuery as a second copy unless you have arranged a separate retention path. Done when a test search returns Workspace audit events that match the BigQuery rows and the test action, and your team has recorded the input's configuration and owner.
Who owns which part of the Workspace to Graylog path
The Google Workspace super admin is the only party who can turn on the BigQuery export in the Admin console, so this work starts with them. Their step is short, but nothing downstream receives data until the export is running and writing to a dataset that the Google Cloud owner has named.
- Enable the BigQuery export: Turn on the Workspace BigQuery export in the Admin console, which the Graylog input documentation lists as a prerequisite.
- Agree the target project and dataset: Confirm with the Google Cloud owner which project and dataset will receive the export before the setting is changed.
- Record the change: Note which admin account made the change and when, so the export setting has a clear owner for later review.
- Hand over identifiers: Give the cloud owner the project ID and dataset name, plus the contact who can change the export later.
Before you tell the Graylog administrator the source is ready, check in BigQuery that new Workspace records are arriving in the dataset.
The Google Cloud owner manages the project that holds the exported data, the billing account that pays for it and the service account Graylog uses to read it. Graylog needs a Google Cloud project with billing, a service account with the BigQuery Editor role and a BigQuery dataset, so this party makes most of the infrastructure decisions.
- Project and billing: Create or select a project with billing enabled and confirm who approves BigQuery spend for it.
- Service account: Create a service account and grant it the BigQuery Editor role, which the Graylog documentation names for this input.
- Dataset: Create or confirm the BigQuery dataset that receives the export, and agree its location with the Workspace admin.
- Credential handover: Pass the service account credentials to the Graylog administrator through an approved secret channel, and record who holds a copy.
Ask the Graylog administrator and your finance contact how much BigQuery storage and query activity the export will create, since the cost depends on your Workspace log volume and retention in BigQuery. Only the Google Cloud owner can answer that from the actual project.
The Graylog administrator configures the input, so this party needs a Graylog Enterprise license, because the Google Workspace input is an Enterprise pull input. They also decide how long data stays in Graylog, since the input deletes records from BigQuery after ingestion.
- Licensing: Confirm that the Graylog installation holds an Enterprise license that includes this input before you add it.
- Input configuration: Enter the project, dataset and service account credentials supplied by the cloud owner, then start the input and check for errors in the Graylog logs.
- Content pack: Install the Illuminate content pack for Workspace logs if your edition and version support it, and confirm the pack's version in your environment.
- Streams and index sets: Route Workspace events to a stream and index set with retention that matches your policy.
- Failure behavior: Ask the vendor how the input behaves if Graylog is down during ingestion, since records are deleted after they are read.
Before sign-off, search for a recent Workspace event and confirm that its fields display correctly in Graylog.
Each party's work becomes useful only when the next party has what it needs. Agree these handoffs in writing before any setting changes, so that the Workspace admin, the cloud owner and the Graylog administrator know exactly what they are passing on and what they must receive.
- Workspace admin to cloud owner: Export enabled, project ID, dataset name and the contact who can change the export.
- Cloud owner to Graylog administrator: Service account credentials with the BigQuery Editor role, dataset location and the billing contact for BigQuery charges.
- Graylog administrator to the business owner: Enterprise license confirmation, input status, stream and index set choices and the retention period in Graylog.
- Access review: Confirm that only named people hold the credentials and admin rights each step needs, and that the service account is limited to this project.
- Ownership of changes: Name who approves future changes to the export, the service account and the input.
Check that each handoff is recorded with a date and a named owner, because these records are the first thing a reviewer will ask for.
How Workspace audit fields land in Graylog
This table follows one Workspace audit event from the BigQuery export into Graylog, showing which element holds each part of the record and what to check at each step. Read it in order before you build streams, dashboards or alerts, because field names come from the export schema and the content pack version you install. The main takeaway is that content pack parsing only works when its field expectations match your export schema and Graylog version.
| Element | Where it lands in Graylog | What to verify |
|---|---|---|
| BigQuery dataset and tables | Source that the pull input reads from | Dataset name, location and table names in the Workspace export settings |
| Audit event row | One Graylog message per exported row, as the input produces it | How your installed input version maps rows to messages |
| Event timestamp | Sets the message time used for search and index placement | Which column the input uses and the time zone of the stored values |
| Nested event attributes | Stored as message fields under names set by the input | Which attributes are nested in your export and how the input names them |
| Illuminate content pack | Supplies parsing and prebuilt dashboards for audit fields | The pack version matches your Graylog version and your export schema |
| Streams and pipeline rules | Route Workspace messages to a dedicated index set | Routing rules and index set settings after the content pack loads |
| Post-ingestion deletion | Graylog indices become the main copy of the audit trail | Index retention and archive plans cover your required review period |
Securing the service account, dataset and Graylog input
The Google Workspace input reads audit data from a BigQuery dataset using a service account, so the controls that matter sit in three places: the Google Cloud identity, the dataset, and the Graylog input itself. The cards below cover those controls and one data-lifecycle decision that must be settled before the first run.
Limit the service account key
The input authenticates with a service account, and its JSON key is the credential an attacker would want. Create a dedicated service account for this input only, avoid sharing it with other pipelines, and check whether your organization policy allows long-lived keys at all. Record who created the key, where it is stored, and when it will be rotated. Confirm the rotation procedure with your Google Cloud administrators before go-live, because replacing the key later means editing the input configuration in Graylog.
Scope BigQuery Editor to the dataset
The input needs the BigQuery Editor role, which is broader than reading. Where Google Cloud permits, grant that role on the audit dataset rather than at project level, so the service account cannot change unrelated datasets. Confirm with your Google Cloud administrator whether the input's read and delete behavior can be satisfied with dataset-level permissions in your project, and test that in a non-production project first. Document the grant so reviewers can see the exact scope.
Protect the stored credential in Graylog
The service account key is entered into the Graylog input configuration, so anyone who can edit that input can view or replace the credential. Restrict input management to a small administrator group, and confirm how your Graylog version stores and displays secret fields. Keep the key out of configuration files, tickets and chat, and use your secrets manager for the source copy. Review who holds the Graylog admin role whenever team membership changes.
Restrict who can view the input
Audit logs describe administrator actions and user activity, so the Graylog input and the streams it feeds deserve the same care. Use Graylog roles so that most analysts can search the destination stream without seeing the input setup page or its credential fields. Confirm the role capabilities in your Graylog edition, since sharing and role controls depend on the features you license.
Decide retention before the first run
The input deletes exported records from BigQuery after Graylog ingests them, so the only copy left may be the one in Graylog. Before the first run, decide how long Graylog must keep these logs, which index set will hold them, and whether a separate copy in cheaper storage is required. Agree that retention with your compliance and legal owners. If an export is lost before ingestion or Graylog data is deleted by rotation, the data cannot be pulled again from BigQuery.
Confirm backups and the ingest checklist
Before enabling the input, write a short checklist covering the key owner, the rotation date, the dataset scope, the Graylog roles allowed to edit the input, and the backup location for the Graylog data it creates. Verify that a restore of a sample index works in a test environment, so you know your backups can recover audit records. Ask your implementation partner or internal team to walk through the checklist with the security owner.
Why Workspace logs stop arriving in Graylog
This table lists the failures that most often stop Workspace audit logs from reaching Graylog, with the cause and fix for each. Work down the rows in order, because the input status and logs in Graylog usually show which layer has broken. Most failures sit in the Admin console export, the Google Cloud project or the Enterprise license rather than in Graylog itself.
| Symptom or failure | Likely cause | Fix |
|---|---|---|
| Input shows running but no messages arrive | Workspace BigQuery export is not enabled in the Admin console, or it writes to a different dataset than the input expects | Confirm the export is enabled in the Admin console, then check the dataset name and project ID configured in the input against the export target. |
| Input logs show permission errors reading BigQuery | The service account lacks the BigQuery Editor role on the dataset or project | Grant the service account the BigQuery Editor role as the input requires, then restart the input and watch its logs for a clean read. |
| Input cannot query the project at all | Billing is disabled on the Google Cloud project | Re-enable billing on the project that holds the dataset. The input needs a project with billing, so a suspended account stops reads. |
| Input does not start or is missing from the input list | Enterprise license is not applied to the Graylog cluster | Apply a valid Enterprise license, confirm it under system settings, then re-create or restart the Google Workspace input. |
| Messages arrive but fields are unparsed or dashboards are empty | Illuminate content pack is missing, outdated, or does not match the Graylog version | Compare the installed Illuminate content pack version with your Graylog release and reinstall the matching pack for Workspace logs. |
| Logs were ingested once, then stopped, and the dataset is empty | The input deletes records from BigQuery after ingestion, so earlier data is gone from the source | Confirm retention in Graylog and plan for loss if the input stops before records are read. Keep a separate BigQuery copy if you need the source history. |
| Time gaps or late events in searches | BigQuery export lags behind activity, or the input poll interval is long | Check the export timing in Google's documentation, compare event timestamps with ingest time, and adjust the poll interval after testing. |
What BigQuery and Graylog licensing add to the cost
The cost of this input has three separate parts: a Graylog Enterprise license, Google Cloud billing for BigQuery, and internal effort to build and tune the pipeline. The Enterprise license is required because the Google Workspace input is an Enterprise pull input, so Graylog Open alone cannot run it. Graylog's pricing page lists Graylog Enterprise from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Ask Graylog how the Workspace audit volume you expect counts against that minimum and whether your current deployment size fits the Enterprise tier before you commit.
BigQuery is billed by Google Cloud, not by Graylog, and it is the cost most likely to change with your audit volume. Your bill will reflect the storage that holds the exported Workspace logs until the input reads them, the queries the input runs against those tables, and any other datasets in the same project. The input deletes logs after ingestion, which limits how long the data sits in BigQuery, but it does not remove the need to check storage and query charges. Confirm current BigQuery pricing directly with Google, and model it against the export volume from your Admin console and the query frequency you set on the input. Ask whether the project will carry other billing, and set a budget alert on it from the start.
Internal effort is a one-time cost that is easy to underestimate. Someone must create the Google Cloud project with billing, the service account and its BigQuery Editor role, the dataset, and the Workspace export, then verify that events arrive in Graylog. The Illuminate content pack for Workspace audit logs also needs review against your own events, because field mappings, streams and dashboards usually need adjustment once real data flows. Those tuning hours recur whenever Google changes event fields. Graylog Enterprise also carries its own support terms, which Graylog should describe in writing. When you request a quote, ask for the license tier, the expected data volume basis, the BigQuery cost assumptions and the effort split between setup and ongoing tuning.
Questions teams ask before connecting Google Workspace to Graylog
Can Graylog Open pull Google Workspace audit logs without an Enterprise license?
No. The Graylog Google Workspace input is a Graylog Enterprise pull input, so Graylog Open cannot read the BigQuery export through it. Graylog Open still handles syslog, GELF and Beats inputs, search and dashboards, but that does not cover this source. The Graylog pricing page lists Graylog Enterprise from 15,000 US dollars per year, with a minimum of 10 GB per day or 100 Graylog Compute Units, licensed on processed data with no per-user or per-device fees. Confirm the current terms with Graylog before budgeting, since the quote depends on your daily volume and edition.
What drives the total cost of connecting Google Workspace to Graylog?
Cost has three layers: the Graylog license, the Google Cloud charges for BigQuery, and the labor to build and verify the pipeline. The license follows the Enterprise tier and your processed data volume, with the pricing page setting the minimum described above. BigQuery charges depend on how much audit data lands in the dataset, how long it stays there and how often it is queried. The Graylog input deletes records after ingestion, which limits accumulation, but confirm the current storage and query pricing in Google's own documentation for your region. Labor scales with the number of projects, service accounts and streams you need. Ask any quote to separate one-time setup from recurring license and cloud costs.
How long does Google Workspace log setup take in Graylog?
The duration depends on your environment. The main variables are whether a Google Cloud project with billing already exists, how quickly a Workspace administrator can enable the BigQuery export, whether your change process must approve a service account with the BigQuery Editor role, and whether Enterprise licensing is already in place. No fixed duration applies to every environment, so treat any timeline as provisional until those prerequisites are confirmed. Ask for the work to be split into discovery, build and verification steps, and confirm which steps wait on approvals from your security or change teams before work starts.
What does our internal team need to provide for this integration?
Three roles are usually needed. A Google Workspace super administrator or delegated administrator must enable the BigQuery export in the Admin console. A billing owner must be responsible for the Google Cloud project and its budget. A Graylog administrator with access to an Enterprise license must create the input, the stream and the index routing for the events. You also need a named owner for the service account credentials and confirmation that Graylog servers can reach Google's APIs over the network path your security policy allows. Confirm who approves new IAM roles and who receives budget alerts before the build starts.
Can our own team set up the Google Workspace input without a partner?
Yes, if your team has Google Cloud, Workspace administration and Graylog skills and holds the Enterprise license. The documented sequence is to create a Google Cloud project with billing, create a service account with the BigQuery Editor role, create a BigQuery dataset, enable the Workspace BigQuery export in the Admin console and then configure the input in Graylog. The harder parts are scoping IAM tightly, proving that logs arrive and are deleted after ingestion, and checking the Illuminate content pack against the Workspace log types you actually collect. A partner works from a written, fixed scope, so the deliverables and verification steps are agreed before work starts.
How do we stop BigQuery costs from growing without limits?
Start with a dedicated project and dataset so spend is traceable to this integration. Set budgets with alerts on the Google Cloud billing account, scoped to that project. Because the Graylog input deletes exported records after it ingests them, the dataset should hold a short backlog rather than a long archive, so confirm that behavior in a test before go-live. Limit the service account to the one dataset, and check whether any other tool or dashboard also queries the same tables, since those queries add cost. Review the current BigQuery pricing for your region, and ask any quote to show the assumed monthly data volume.
What happens to Google Workspace logs when the Graylog input stops reading?
Because the input deletes exported records after ingestion, a stalled pull can leave logs sitting in BigQuery until someone notices, and storage charges continue during the gap. Watch the input status in Graylog, alert on silence in the stream that receives these events, and check that the service account key has not expired and that its IAM roles have not changed. Confirm that the Workspace BigQuery export is still enabled after administrator changes in the Admin console. Test the recovery path on a non-production dataset first, so the team knows how the input resumes and whether any records were missed.
Official Graylog documentation for this input
The Graylog Google Workspace input documentation is the one source to treat as authoritative for this integration. Every setting in this page, from the Google Cloud project and service account to the BigQuery dataset and the way the input deletes exported records after ingestion, should be checked against it before you configure anything. Other pages, forum posts and vendor blog summaries can lag behind the product, so use them only as background and confirm the details in the primary document. Read the page for the exact version of Graylog you run, because the input's options and prerequisites can change between releases.
Start by confirming your version. The current Graylog documentation covers version 7.2, but many production environments run an earlier 7.x release or are still planning an upgrade. Use the version selector in the documentation to open the page that matches your server, and compare it with the release you have installed. If the two differ, note the gap and decide whether to upgrade first or to document the configuration against your running version. Record the version and the documentation date in your change ticket so an auditor or a colleague can see which instructions were followed.
Because the input is an Enterprise feature, also confirm that your license covers it before you read the configuration steps in detail. The input reads Workspace logs from BigQuery and removes them after ingestion, so an error in the export, dataset retention or service account permissions can cause data loss or gaps in the audit trail. Keep a short list of the points the documentation says you must confirm, such as the BigQuery Editor role on the service account and the Admin console export setting, and check each one against your own tenant before you enable the input in production.
How DeployOpen scopes and delivers the Google Workspace input
DeployOpen plans, builds, documents and hands over Graylog deployments inside your own infrastructure, including the Google Workspace BigQuery input. Each engagement starts from a written scope that covers the Google Cloud project, service account, BigQuery dataset, Graylog licensing and the content you intend to use.
How we scope
- Confirm your Graylog edition and Enterprise license before any Google Cloud work begins.
- Map which Workspace audit log categories you need and where the BigQuery export will land.
- Agree the Google Cloud project, billing owner, service account and BigQuery dataset in writing.
How we build
- Create the service account with the BigQuery Editor role and limit it to the dataset in scope.
- Enable the Workspace BigQuery export in the Admin console and confirm rows are arriving.
- Configure the Google Workspace input in Graylog and test ingestion, parsing and stream routing.
How we hand over
- Document the project, service account, dataset, input settings and credential rotation steps.
- Walk your team through checking input health, BigQuery cost trends and the deletion behavior.
- Provide a written record of what was tested, what was changed and what remains your responsibility.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review Graylog version changes and the Google Workspace input before you upgrade either side.
- Confirm with your team which support scope and response expectations apply before engagement.
