Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.matproof.com/llms.txt

Use this file to discover all available pages before exploring further.

Overview

The Google Cloud Platform (GCP) integration reads security and configuration data from your GCP organization or project to provide evidence for cloud-infrastructure controls. It uses a read-only service account with viewer-level roles — Matproof never modifies your GCP environment. Evidence collected automatically:
  • IAM policies, role bindings, and group inheritance
  • Service accounts and their key rotation status
  • Cloud Storage bucket encryption (CMEK / Google-managed) and public-access settings
  • VPC firewall rules with overly permissive ingress (e.g., 0.0.0.0/0 on sensitive ports)
  • Cloud KMS key rotation cadence
  • Cloud Audit Logs configuration (Admin Activity, Data Access, System Event)
  • Security Command Center (SCC) findings
  • Cloud SQL encryption and backup configuration
  • GKE cluster shielded-nodes, binary authorization, and network-policy status

Prerequisites

  • GCP project or organization where Matproof should read configuration data
  • Permission to create a service account with Viewer and Security Reviewer roles
  • Matproof Admin or Owner role
  • (Recommended) Security Command Center Standard or Premium tier — Matproof reads SCC findings if available

Connecting GCP

GCP supports connection at either the project level (single project) or the organization level (Matproof scans every project in your org). For multi-project setups, organization-level is recommended — it scales without re-onboarding each project.

Step-by-step

1

Create the service account

In GCP Console, go to IAM & Admin → Service Accounts → Create Service Account:
  • Name: matproof-readonly
  • Description: Read-only access for Matproof compliance evidence
2

Grant the required roles

On the service account, grant:
  • roles/iam.securityReviewer — for IAM policy reads
  • roles/viewer — for resource configuration reads
  • roles/securitycenter.findingsViewer — for SCC findings (if SCC is enabled)
  • roles/logging.viewer — for audit log metadata
For organization-level connections, grant the roles at the organization node (not just one project).
3

Create a service-account key

On the service account → Keys → Add key → Create new key → JSON. Download the JSON file. Treat it as a credential — store it only briefly until step 4.
4

Upload the key to Matproof

In Matproof: Settings → Integrations → Google Cloud → Connect → Upload service-account key. Paste or upload the JSON. Matproof immediately tests the connection and runs the first scan.
5

(Optional) Delete the local key

Once Matproof shows Connected, delete the JSON file from your local machine. Matproof has stored the credential encrypted in our secrets store; you don’t need a copy.
Matproof only ever uses the service account for read calls. Roles granted are intentionally minimum for visibility — no Editor, no Owner, no project-creation rights.

What gets mapped to which controls

Evidence CollectedControl Examples
Service-account key rotation within 90 daysCryptography / credential lifecycle (ISO 27001 A.8.24)
No GCS buckets with public read/writeData protection (ISO 27001 A.5.10, GDPR Art. 32)
Cloud Audit Logs enabled (Admin + Data Access)Logging and monitoring (DORA Art. 10, ISO 27001 A.8.15)
Firewall — no 0.0.0.0/0 on port 22, 3389, 3306Network security
KMS key rotation enabled and ≤ 90 daysCryptography controls
GKE shielded nodes enabledWorkload integrity
GKE binary authorization enforcedSoftware supply chain
SCC findings — High and Critical resolved within SLAVulnerability management
IAM bindings — no broad roles/owner to user accountsPrivileged access management

Multi-project setups

When connected at the organization level, Matproof discovers all projects under the org and scans each. The discovered project list appears in Integrations → Google Cloud → Projects, where you can:
  • See per-project compliance status
  • Exclude specific projects from scanning (e.g., sandbox or experimental projects)
  • Tag projects with environment (prod, staging, dev) so audit-relevant evidence focuses on production
For project-level connections, only the connected project is scanned. To add more projects, repeat the connection flow per project — or upgrade to organization-level access.

Common issues

”Permission denied on Security Command Center”

SCC findings are only visible to service accounts with roles/securitycenter.findingsViewer granted at either the organization or the SCC source level. If SCC is enabled but findings come back empty, verify the role is granted at the organization node, not just on a project. SCC is an org-scoped service.

”Audit logs are enabled but Matproof reports them as missing”

Matproof checks for Data Access audit logs specifically — these are off by default in GCP. Admin Activity logs are on by default and don’t satisfy the data-access logging requirement under DORA Art. 10. Enable them under IAM & Admin → Audit Logs.

”Service-account key shows as nearing expiry”

GCP service-account keys don’t have a hard expiry, but Matproof flags keys older than 90 days as a finding (per CIS GCP Foundations Benchmark 1.6). Rotate by creating a new key, uploading to Matproof, and deleting the old one — typically a 5-minute task.

”I can’t see my GKE clusters”

GKE inventory needs roles/container.viewer in addition to the base viewer role. Add it on the service account and run a manual sync.

Disconnecting

In Matproof: Settings → Integrations → Google Cloud → Disconnect. The encrypted key is purged from our secrets store. In GCP: also delete the service account (not just disable) so the key is fully revoked. Go to IAM & Admin → Service Accounts → matproof-readonly → Delete.

AWS

The AWS-side equivalent

Azure

Microsoft Azure (cloud + Entra ID)