GCP Access Transparency logs every action taken by Google administrators on your resources, acting as an independent audit trail for your cloud environment.
Imagine you’re running a critical application on GCP, and suddenly, something goes wrong. You need to know who did what, when, and why. Access Transparency provides exactly that: a definitive log of privileged Google personnel actions.
Here’s a glimpse of what Access Transparency logs look like in practice. Let’s say a Google engineer, identified by their userEmail (e.g., google-support-admin@google.com), needs to access your project’s compute instances for troubleshooting. The log entry, captured by Access Transparency, would reveal:
{
"logName": "projects/your-project-id/logs/cloudaudit.googleapis.com%2Factivity",
"protoPayload": {
"@type": "type.googleapis.com/google.cloud.audit.AuditLog",
"authenticationInfo": {
"principalEmail": "google-support-admin@google.com",
"principalSubject": "auth_id_token:...",
"principalDelegationInfo": [
{
"principal": {
"serviceAccount": {
"emailAddress": "service-account-for-support@google.com"
}
},
"principalDelegationType": "SOFTWARE_SERVICE_ACCOUNT"
}
]
},
"requestMetadata": {
"callerIp": "203.0.113.1",
"callerSuppliedUserAgent": "google-api-client-libraries/v1/java",
"operation": {
"id": "operations/...",
"producer": "compute.googleapis.com",
"operationType": "patch"
},
"requestAttributes": {
"time": "2023-10-27T10:30:00Z",
"auth": {}
},
"destinationAttributes": {
"time": "2023-10-27T10:30:05Z"
}
},
"serviceName": "compute.googleapis.com",
"methodName": "google.cloud.compute.v1.Instances.Update",
"resourceName": "projects/your-project-id/zones/us-central1-a/instances/my-vm-instance",
"accessLevel": "ACCESS_LEVEL_UNSPECIFIED",
"authorizationInfo": [],
"request": {
"@type": "type.googleapis.com/google.cloud.compute.v1.Instance",
"name": "my-vm-instance",
"status": "RUNNING"
},
"response": {
"@type": "type.googleapis.com/google.cloud.compute.v1.Instance",
"name": "my-vm-instance",
"status": "RUNNING"
}
},
"resource": {
"type": "gce_instance",
"labels": {
"instance_id": "...",
"zone": "us-central1-a",
"project_id": "your-project-id"
}
},
"timestamp": "2023-10-27T10:30:05.123456789Z",
"severity": "INFO",
"insertId": "...",
"trace": "projects/your-project-id/traces/...",
"spanId": "...",
"commitTimestamp": "2023-10-27T10:30:06.123456789Z"
}
This log entry shows a google-support-admin@google.com performing an Instances.Update operation on my-vm-instance in us-central1-a within your-project-id. Crucially, the authenticationInfo.principalDelegationInfo reveals that this action was performed on behalf of a Google service account, indicating a legitimate, authorized access for support or maintenance.
Access Transparency is built upon the standard Cloud Audit Logs infrastructure, but it specifically captures events that occur when Google personnel access your data or resources. This is distinct from your own users’ actions or automated service account operations.
To enable Access Transparency, you need to configure it at the organization level. This ensures that all projects within your organization are covered.
- Navigate to IAM & Admin: In the Google Cloud Console, go to "IAM & Admin".
- Access Organization Policies: Select "Organization policies".
- Find Access Transparency: Search for "Access Transparency" or find it under the "Security" category.
- Edit Policy: Click "Edit policy".
- Allow Access Transparency: Under "Policy enforcement," select "Allow". This will enable Access Transparency for all projects under this organization.
- Add Conditions (Optional but Recommended): You can add conditions to refine when Access Transparency is enforced, for example, based on resource type or location. However, for a comprehensive audit, it’s often best to enforce it broadly.
- Save Policy: Click "Save".
Once enabled, Access Transparency logs will start appearing in your Cloud Audit Logs. You can view these logs by:
-
Navigating to Logging: In the Google Cloud Console, go to "Logging" and then "Logs Explorer".
-
Querying the Logs: Use a query like this to filter for Access Transparency logs:
logName="projects/your-project-id/logs/cloudaudit.googleapis.com%2Factivity" protoPayload.authenticationInfo.principalEmail=~"^google-support-admin@google.com$" OR protoPayload.authenticationInfo.principalEmail=~"^google-internal-support@google.com$" OR protoPayload.authenticationInfo.principalEmail=~"^google-restricted-admin@google.com$"Replace
your-project-idwith your actual project ID. This query specifically looks for entries where the principal email belongs to Google’s internal administrative accounts. -
Analyzing the Results: Examine the
protoPayload.authenticationInfo.principalEmailto identify the Google administrator, theserviceNameandmethodNameto understand the service and action performed, and theresourceNameto see which resource was accessed. TheprotoPayload.authenticationInfo.principalDelegationInfofield is particularly important as it indicates the specific Google service account that was used for the operation, providing a deeper layer of accountability.
The core problem Access Transparency solves is the lack of visibility into actions taken by cloud provider personnel. In a shared responsibility model, you are responsible for your data and applications, but the underlying infrastructure is managed by Google. Access Transparency bridges this gap by providing an auditable record of Google’s privileged access to your environment.
Internally, Access Transparency works by instrumenting the Google infrastructure that accesses customer data. When a Google administrator initiates an action that involves accessing your resources (e.g., to debug a hardware issue, fulfill a support request, or perform maintenance), this action is logged. These logs are then ingested into your Cloud Audit Logs, making them accessible through the same tools you use for your own application and infrastructure logs. The key differentiator is the principalEmail field, which will be a specific Google-domain email address.
A common misconception is that Access Transparency logs all Google actions. In reality, it logs only those actions where a Google administrator accesses your data or resources for specific operational reasons. Routine, automated system maintenance that doesn’t involve direct access to your data is generally not logged by Access Transparency. Furthermore, the logs capture the fact of access and the type of action, but not necessarily the content of any data accessed, adhering to privacy principles.
The next step after enabling Access Transparency is often to set up log sinks to route these critical audit logs to a more durable or centralized logging solution, such as Cloud Storage buckets or BigQuery, for long-term retention and advanced analysis.