Secure Access Controls for Cloud Logging

Enforcing IAM permissions, privileged roles, and perimeter boundaries for logs means controlling who can query telemetry in Cloud Logging and from where those queries can succeed. Identity and Access Management (IAM) (opens in a new tab) grants access from an identity to a log bucket or view, while IAM Conditions and VPC Service Controls perimeters add context and network boundaries. Together these controls separate standard operational logs from sensitive Data Access audit logs and block queries from unauthorized networks or identities.

1.1Predefined Logging Roles for Least Privilege Access

Predefined logging roles are the baseline for least privilege separation between standard logs and sensitive audit data in the _Default bucket. Logs Viewer (roles/logging.viewer) grants read access to standard logs and to entries in Logs Explorer, while Private Logs Viewer (roles/logging.privateLogViewer) is additionally required to read private logs that can contain sensitive data, including Data Access audit logs. Logs View Accessor (roles/logging.viewAccessor) grants read access to specific log views, and highly privileged administration belongs to broader roles such as Logging Admin, which must be reserved for administrators who manage buckets, sinks, and views.

Least privilege for log access means granting only the role needed for the task at the smallest resource scope, preferably to Google groups rather than individual users. A troubleshooting operator receives Logs Viewer on the project or view that holds the needed logs, while only auditors and incident responders receive Private Logs Viewer for sensitive audit telemetry. Privileged membership must expire automatically or be reviewed periodically, and all privileged use must require 2-step verification so a stolen password or OAuth token alone does not grant log access.

1.2IAM Conditions and Identity Context Enforcement

IAM Conditions are context-aware restrictions on logging roles so a valid role alone is not enough to read logs. An IAM Condition on a log bucket, view, or project evaluates attributes on every request, such as time of day, resource name, IP address, geographic location, or device context, and Cloud Logging denies the query when the condition is not met. This lets administrators allow log queries only from the corporate network, only from approved regions, or only for a defined maintenance window.

Attribute-based enforcement is implemented with Access Context Manager and Chrome Enterprise Premium access levels. Access Context Manager defines an access level, for example that the user must be on the corporate network or present a valid mutual-TLS certificate, and that access level is bound to the protected Logging resources. Chrome Enterprise Premium then evaluates that access level on every user API request to Cloud Logging, rejecting traffic that uses otherwise valid credentials from an attacker-controlled machine outside the authorized context.

1.3VPC Service Controls Perimeters for Log APIs

VPC Service Controls perimeters are resource-centric boundaries that control how Google Cloud data and APIs communicate across trust zones. A perimeter encloses protected projects, Cloud Logging buckets, and supported APIs on the inside, while untrusted networks, external exfiltration destinations, and unauthorized projects remain on the outside. Once log data is inside the perimeter, VPC Service Controls policies allow API calls and data movement within the perimeter but deny reads, copies, or sink exports that attempt to cross the perimeter boundary unless an explicit ingress or egress rule allows them.

The perimeter applies to every identity type, including both user accounts and service accounts, so an automated exporter cannot bypass the boundary. This complements identity-centric controls because Chrome Enterprise Premium evaluates only user identities in the organization, while VPC Service Controls evaluates all user and service account identities that call the protected Logging APIs. When used together, a compromised credential fails twice — the context check rejects the user from outside the corporate context, and the perimeter rejects movement of log data to resources outside the authorized boundary.

1.4Segregating Sensitive Logs by Views, Sinks, and Field Controls

Segregation architectures physically separate sensitive telemetry so restrictive IAM policies apply only where they are needed. Instead of placing logs of different sensitivity in one bucket with one broad role, Cloud Logging routes or filters entries so standard readers never receive private fields or private streams. The choice depends on whether the boundary should hide whole entries, whole streams, or single fields:

A common pattern keeps operational logs in the _Default bucket for broad Logs Viewer access, while a log sink routes Data Access audit logs to a locked-down security project where only holders of Private Logs Viewer can query them. Log views then narrow access further within each bucket, and field-level access control hides restricted fields from readers who are authorized to see the rest of the entry.

Secure aggregated log routing, export destinations, and storage immutability is the architecture for centralizing audit telemetry and proving it has not been altered. Cloud Logging (opens in a new tab) collects logs in each project, an aggregated sink defined at the organization or folder routes matching logs to a destination in a dedicated logging project, and that destination protects the data with customer-managed encryption and immutable retention.

2.1Centralized Aggregated Sinks

An aggregated sink is a log sink created at the organization or folder level that captures logs from all current and future child projects and folders. Log entries flow from the source workloads to the sink filter, then from the sink to a single destination in a central logging project controlled by the security team. A common pattern is one sink that routes Administrator Activity audit logs to a logging bucket for investigation and a second sink that routes high-volume Data Access audit logs to long-term storage.

Choose centralized aggregated sinks when the security team requires a central record of specific log types and needs storage outside the control of the teams that produced the logs. Avoid this model when there is no central consistency requirement or when individual project owners retain full responsibility for their own audit logs. Because the destination lives in a separate project with restricted access, workload owners cannot modify, delete, or bypass the central copy even though they retain access to their local projects.

2.2Export Destinations and Central Logging Project

An export destination is the Google Cloud service in the central logging project that receives routed logs for storage or analysis. The sink destination sits on one side of the trust boundary in the security-owned logging project, while the log sources sit on the other side in workload projects, so access to the central project can be limited to privileged auditors and responders. Destinations divide by retention and use:

• Cloud Logging bucket stores, indexes, and searches logs in a specific region and supports analysis with Observability Analytics for impromptu investigations.
• Cloud Storage bucket stores exported logs as objects for low-cost, long-term retention and compliance archiving.
• BigQuery (opens in a new tab) dataset stores exported logs as tables for large-scale SQL analysis and retention.
• Pub/Sub topic streams exported logs in real time to downstream pipelines, including ingestion into Google SecOps or an external SIEM.

Logging buckets are regional resources, so select the region to meet latency, availability, and data-residency requirements. To apply the same region automatically to new _Default and _Required buckets across the organization, configure a default resource location.

2.3Protecting Log Storage With Customer-Managed Encryption Keys

Protection of log storage with customer-managed encryption keys (CMEK) replaces Google-managed encryption with keys the organization creates and manages in Cloud Key Management Service (Cloud KMS). By default Cloud Logging encrypts customer content at rest, and CMEK adds control over key lifecycle, rotation, and destruction for audit and regulatory requirements. The same CMEK model extends to downstream destinations, including Cloud Storage buckets, BigQuery datasets and tables, and Pub/Sub topics. The encryption choices differ by control and operational cost:

For additional control, configure HSM-backed keys or Cloud External Key Manager (Cloud EKM) with CMEK, and enforce the requirement centrally by blocking creation of non-compliant resources with CMEK organization policies such as gcp.restrictNonCmekServices. Customer-supplied encryption keys (CSEK) are not recommended because Cloud EKM supports more services with higher availability.

2.4Immutability With Retention and Bucket Lock

Immutability with retention and Bucket Lock ensures exported logs cannot be overwritten or deleted before their compliance period ends. Cloud Logging retains logs according to the retention rule of the bucket where they are held, with custom retention configurable from 1 day to 3650 days. A custom rule applies to every log in the bucket regardless of log type or whether the log was copied from another location.

For Cloud Storage destinations, configure a retention policy and then lock it with Bucket Lock to make the policy immutable until its duration expires. A locked policy prevents deletion or shortening of retention by any user, including privileged administrators, which preserves audit integrity and supports separation of duties. Combine locked retention with restricted Identity and Access Management (IAM) access to audit logs, additional logging on sensitive buckets, and centralized security monitoring so that access to audit management information is limited to privileged users and all access is itself auditable.

Custom log buckets, log views, and field-level access controls in Cloud Logging form a layered model for secure access to logs. A log bucket (opens in a new tab) is the regional storage container that holds log entries and enforces retention, location, and encryption policy. Log views segment that bucket by controlling which complete LogEntry objects a user can see, while field-level access controls (opens in a new tab) redact individual fields inside those entries, such as personally identifiable information (PII).

Both controls can be set on the same log bucket, so entry-level segregation and field-level redaction compose into one access decision when a user queries logs.

3.1Custom Log Buckets for Segregation and Storage Control

A custom log bucket is a user-defined Logging bucket used to centralize logs from many projects or to subdivide logs by compliance, team, or workload boundary. Log buckets are regional resources, which means the infrastructure that stores, indexes, and searches the logs lives in a specific geographic location. Select the bucket region to meet latency, availability, and compliance requirements, and configure a default resource location to automatically apply that region to new _Default and _Required buckets in the organization.

Storage controls on a log bucket apply to everything the bucket holds. Custom retention rules retain logs between 1 day and 3650 days to meet compliance needs, and each rule applies to all logs in the bucket regardless of log type or whether the log was copied from another location. By default Cloud Logging encrypts customer content at rest with Google-managed keys, and organizations with advanced requirements can instead configure customer-managed encryption keys (CMEK) with Cloud Key Management Service (Cloud KMS) to control their own key lifecycle.

3.2Log Views for Entry-Level Segmentation

Log views are access boundaries inside a log bucket that determine which complete LogEntry objects a principal can read. A user who lacks permission on a view cannot see the entries assigned to that view at all, which supports segregation by project, resource type, or payload attributes from shared or centralized storage. This entry-level filtering is distinct from field-level controls, which leave the entry visible but remove sensitive fields. Use log views when the decision is whether a team should see an event, and use field-level controls when the decision is which parts of a visible event they may see.

3.3Field-Level Access Controls for Sensitive Fields

Field-level access controls in Cloud Logging hide individual LogEntry fields from Google Cloud project users who lack permission to view those fields. A typical use is redacting external user PII, such as an email address in the log payload or an SSN in jsonPayload.data.ssn, from most organization users while leaving the rest of the entry readable. Logging enforces the control at query time by checking Identity and Access Management (IAM) permissions on the bucket that stores the restricted fields. Restricted fields are configured at the log bucket level and include broad and leaf-level paths:

• jsonPayload, which also restricts all of its nested paths
• Leaf fields of jsonPayload, such as jsonPayload.data.ssn
• Leaf fields of textPayload
• Leaf fields of protoPayload, often used for authentication payloads
• Leaf fields of httpRequest, such as httpRequest.status
• Leaf fields of labels, such as labels.check_id
• Leaf fields of sourceLocation

A user without the corresponding access receives a permission-denied error if they directly query a restricted field, global searches ignore the contents of denied fields, and any returned LogEntry results omit the restricted fields. Access requires both permission to view logs in the bucket and the logging.fieldAccessor IAM role for that field path, so least privilege is preserved by granting the field role only to users who need the sensitive data.

3.4Configuring and Granting Access to Restricted Fields

Configuration of restricted fields is managed with the Google Cloud CLI on new or existing log buckets. Prerequisites are gcloud CLI version 362.0.0 or later, a configured default project, and one of roles/logging.configWriter, roles/logging.admin, or roles/owner on the project that contains the bucket. To restrict fields on creation, run gcloud logging buckets create with --restricted-fields set to a comma-separated field list, and to change an existing bucket run gcloud logging buckets update with the same flag.

The update operation replaces the full restricted-field set, so the command must relist every field that should remain restricted. For example, adding jsonPayload.data.entryDate to a bucket that already restricts jsonPayload.data.ssn and httpRequest.status requires listing all three fields, otherwise the two omitted fields stop being restricted. By default Logging hides all restricted fields from users without the field role, and administrators grant visibility by assigning roles/logging.fieldAccessor for all restricted fields or by scoping IAM conditions to a subset of field paths for specific users.

3.5Query Behavior, Analytics Limits, and Bypass Paths

Query behavior on a bucket with field-level access controls depends on the tool used to read the logs. Queries from Logs Explorer enforce the controls and omit denied fields, while live tailing is not supported on buckets with field-level controls. A linked BigQuery dataset does not honor field-level access controls, so a user who can query the linked dataset can query all fields in the log entries even if those fields are restricted in Logging.

Key Facts

• Logs Viewer grants read access to standard logs, while Private Logs Viewer is additionally required to read private logs including Data Access audit logs.
• VPC Service Controls perimeters evaluate both user and service account identities, while Chrome Enterprise Premium access levels evaluate only user identities.
• Aggregated sinks created at the organization or folder level route logs from all current and future child projects to a destination in a security-owned central logging project.
• Custom log bucket retention is configurable from 1 day to 3650 days, and a Cloud Storage retention policy locked with Bucket Lock cannot be shortened or deleted until it expires.
• Field-level access controls require the logging.fieldAccessor role for the restricted field path, and a linked BigQuery dataset does not honor those controls.