Google Cloud Platform

Audits a client's GCP project: IAM policy, service accounts and their keys, Cloud Audit Log configuration, Cloud Storage bucket access, and VPC/firewall exposure.

Setup

1. In the client's GCP project, create a service account for Graften and generate a JSON key for it.
2. Grant it read-only roles. roles/iam.securityReviewer and roles/logging.viewer cover IAM policy and log sinks; roles/compute.viewer and roles/cloudasset.viewer add firewall/VPC and inventory. Do not grant a primitive role (roles/owner, roles/editor, roles/viewer) — Graften's own audit flags those as a HIGH finding, and it will flag yours.
3. Enable the APIs the collectors call, or their controls come back unassessed: cloudresourcemanager, iam, logging, and — if you want network and inventory data — compute and cloudasset. compute requires billing to be enabled on the project.
4. In Graften: Connections → Add Connection → Google Cloud Platform (GCP), set the region, and paste the entire JSON key file into the Service Account JSON field. Hit Test — a working connection reports the project ID and service account email back to you.

About the OAuth scope

Graften requests the cloud-platform scope. Google publishes no narrower read-only scope that covers the IAM API, so this is the only scope that lets the service-account checks run at all. The scope is an upper bound, not a grant — what Graften can actually do is limited by the read-only IAM roles you assign in step 2. If you grant only read roles, Graften cannot write, regardless of scope.

Reading the result

The score is reported alongside a coverage figure. They must be read together: 61/100 assessed over 77% of applicable controls is a different fact from 61/100 over all of them. Anything Graften could not collect is listed explicitly in an Assessment Coverage finding and is excluded from the score rather than counted as passing — so a control Graften could not see never silently becomes a control that passed. The E8 maturity level is withheld entirely until coverage is complete.

If controls come back unassessed

The finding text carries Google's own error. A 403 saying an API "has not been used in project N before or it is disabled" is an API-enablement problem and no role grant will fix it; a 403 naming a specific denied permission is a role problem. They are different failures with different fixes — read which one you have before changing anything.