Google Cloud

Proofroom reads Google Cloud as a service account with read-only roles and files three kinds of evidence, for the projects you list or every active project it can find. Add it on Integrations → Catalogue → Google Cloud → Connect.

What each collector shows

Collector	Kind	Default cadence	What it shows	Suggested controls
Who has access	snapshot	quarterly	Every principal and role in each project’s IAM policy. With the organization ID configured, also the organization’s and every folder’s beneath it (nested folders included), since a folder’s grants reach every project under it. Owner and Editor count as owner-level; conditional grants are marked.	PCI DSS 7.2.4, 7.2.5; SOC 2 CC6.1, CC6.3
Audit logging on	snapshot	quarterly	Per project: which Data Access audit logs are on, enabled log sinks, and how long the `_Default` bucket keeps logs. With the organization ID configured, settings and aggregated sinks (those that include children) on folders and the organization count for the projects beneath them, and each is labelled with where it is set. Admin Activity logs are always on and kept 400 days.	PCI DSS 10.2.1, 10.5.1; SOC 2 CC7.2
Security findings	snapshot	monthly	Active, unmuted Security Command Center findings with severity and resource. A project or organization where Security Command Center is off or unreadable is named.	PCI DSS 6.3.1, 11.3.1; SOC 2 CC7.1

Set up

Create a service account in any project and add a JSON key.
Grant it, on the organization (or on each project; folders are read only with the organization):
- Security Reviewer (roles/iam.securityReviewer): IAM policies, projects, log sinks and buckets.
- Security Center Findings Viewer (roles/securitycenter.findingsViewer): findings.
In the project that owns the service account, enable the Cloud Resource Manager, Cloud Logging and Security Command Center APIs.

Security Command Center accepts only Google’s broad cloud-platform scope; the two roles keep the service account read-only. Proofroom never writes to Google Cloud.

If Google will not create the key

Organizations created on or after 3 May 2024 block service-account key creation by default with an organization policy, so Add key fails with “Service account key creation is disabled”. Two constraints can do this; check both and change whichever is enforced:

iam.managed.disableServiceAccountKeyCreation (the newer managed constraint, which new organizations get), and
iam.disableServiceAccountKeyCreation (the older one).

Allow keys for the service account’s own project only, not the whole organization:

Someone with Organization Policy Administrator (roles/orgpolicy.policyAdmin) on the organization signs in to the Google Cloud console and picks the service account’s project in the project picker.
Go to IAM & Admin → Organization policies, open the constraint (search “Disable service account key creation”), click Manage policy, choose Override parent’s policy, add a rule with enforcement Off, and save. Do not change the policy on the organization itself.
Create the JSON key (step 1 above).
Optional: put the policy back by choosing Inherit parent’s policy on the project, or run gcloud org-policies delete <CONSTRAINT> --project=<PROJECT_ID>. Keys made while it was off keep working; the policy only stops new keys.

The same with gcloud, for the project only:

# The older constraint:
gcloud resource-manager org-policies disable-enforce iam.disableServiceAccountKeyCreation --project=<PROJECT_ID>
# The managed constraint: write policy.yaml, then apply it.
cat > policy.yaml <<'YAML'
name: projects/<PROJECT_ID>/policies/iam.managed.disableServiceAccountKeyCreation
spec:
  rules:
  - enforce: false
YAML
gcloud org-policies set-policy policy.yaml

Signing in without a key (Workload Identity Federation) is planned for a later release.

Connect

Field	Value
Service account key	The whole JSON key file, pasted
Organization ID	Optional but recommended: the numeric ID, to include the organization’s and its folders’ grants, inherited audit log settings and sinks, and to read findings once for it
Projects	Project IDs, one per line; empty means every active project the service account can find

Test connection lists the projects, reads one project’s IAM policy and log sinks, lists folders when the organization ID is set, and reports whether Security Command Center answered (it is optional). Without the organization ID it passes with a warning that folder and organisation grants can’t be read.

Known limits

Without the organization ID, folders and the organization are not read: grants there are missing, and a project may inherit Data Access logging or an aggregated sink that the evidence does not show. Each item’s description and summary say it covers projects only, and its records carry coverage: "projects only".
With it, the service account needs Security Reviewer on the organization, so it can list every folder and read each folder’s policy and sinks. A folder it cannot read fails the run rather than being skipped.
A sink’s destination retention (BigQuery, Cloud Storage) is not read; the evidence says so. The built-in _Required and _Default sinks are not counted as exports.
If Security Command Center refuses every project (or the organization), the findings run fails with Google’s reason rather than filing a clean result.
Findings are read at the global location.
A project listed in the configuration that the service account cannot read fails the run, so evidence never leaves it out silently.

When the key should be replaced

Proofroom reads the service account key’s creation date from Google’s public certificate list for the service account (no permission needed) and shows it under Credentials on the integration page. A key that never expires should be replaced a year after it was created; admins are emailed 30 and 7 days before that date. If an organisation policy gives keys an expiry, that date is used instead.