GCP provider setup: least-privilege roles and checks for CIS v5.0 configuration reads

[maximelb]

Summary

Updates the Google Cloud provider setup page:

• Required roles now match the web app's grant. The page asks for roles/browser, roles/compute.viewer and roles/iam.securityReviewer, the same least-privilege set as the in-app Permissions required list and its generated gcloud script. Until now the page asked for roles/viewer, which grants much more than the collector reads. roles/viewer stays documented as an alternative, with what it still lacks:

  • resourcemanager.organizations.get / folders.get, needed by the auth check for org and folder scopes, so add roles/browser;
  • bigquery.tables.get, so add roles/bigquery.metadataViewer.

• New optional roles for the configuration reads behind the CIS Google Cloud Foundation Benchmark checks: roles/bigquery.metadataViewer (metadata only, no table data), roles/accessapproval.viewer, roles/appengine.appViewer and roles/orgpolicy.policyViewer.

• APIs to enable: Organization Policy, Logging, Monitoring, Cloud DNS, Essential Contacts, Access Approval, App Engine Admin and Dataproc.

• New provider test checks added to the table: sa_keys, audit_config, essential_contacts, log_sinks, log_metrics_alerts, dns, network_config, service_usage, access_approval, app_engine, cloud_sql, kms, api_keys, bigquery_metadata, dataproc. The page explains that these use testIamPermissions and name the missing permission and the role to add.

• APIs checked on the service account's project. For API Keys, Essential Contacts, Access Approval, Organization Policy, Access Context Manager and Policy Analyzer, Google checks enablement on the project that owns the calling service account. If one is off there, every read fails with SERVICE_DISABLED naming that project, and the dependent controls read as not assessed. The page now says so, gives a gcloud services enable command for that project, adds accesscontextmanager.googleapis.com to the enable list, notes which provider test checks catch it (Organization Policy, Access Context Manager, Policy Analyzer) and which do not (API Keys, Essential Contacts, Access Approval are IAM-only checks), and replaces the stale activity_ciem troubleshooting row with the generic "enable this API in the project this message names" failure. Verified live against each API with a service account whose own project had them disabled.

Role contents were verified with gcloud iam roles describe. The permissions used by the new checks were verified to be accepted by testIamPermissions on a project, a folder and an organization.

Merge timing: the new check ids appear once the matching service release is deployed. Please merge this when that release ships.

Self-review

This repository has no automated review, so I reviewed the diff myself. Fixed before opening: a miscounted "three things" sentence, and a claim about how unread controls are graded that describes behaviour not yet released. markdownlint: 0 issues. Second pass (caller-checked APIs): narrowed the troubleshooting row to the three checks that actually probe those APIs, and softened a claim that enabling in scanned projects is irrelevant for every API (only shown for API Keys and Essential Contacts).

🤖 Generated with Claude Code

[maximelb]

Added b33da7e: optional roles/storage.bucketViewer for the log sink destination bucket retention-lock check (CIS GCP 2.4), with a new log_sink_destinations preflight check. Verified with gcloud iam roles describe roles/storage.bucketViewer: it contains only storage.buckets.get and storage.buckets.list, so no object access. roles/viewer and roles/iam.securityReviewer do not carry storage.buckets.get, which is why the roles/viewer tip now mentions it. testIamPermissions accepts storage.buckets.get on a project, a folder and an organization (checked live).

Self-review: the role, permission and check names match the collector and preflight code. The check is marked optional (—). No private repo references.

[limacharlie-refractionpoint]

LimaCharlie Cloud Security — code scan

No new code findings were introduced by this pull request.

This check reports and never fails: no gating.fail_on is set on the code_scanning policy.

Scanned refractionPOINT/documentation 278f605…e9a402a — only findings new in the head commit are listed; anything already on the base branch is the repository's own finding set, on the Cloud Security Code page.

This comment is updated in place on every push to this pull request.