> ## 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.

# Google Cloud Platform Integration

> Connect GCP to collect IAM, Security Command Center, encryption, and audit-log evidence automatically.

## 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

<Steps>
  <Step title="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`
  </Step>

  <Step title="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).
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="(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.
  </Step>
</Steps>

<Note>
  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.
</Note>

***

## What gets mapped to which controls

| Evidence Collected                                     | Control Examples                                        |
| ------------------------------------------------------ | ------------------------------------------------------- |
| Service-account key rotation within 90 days            | Cryptography / credential lifecycle (ISO 27001 A.8.24)  |
| No GCS buckets with public read/write                  | Data 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, 3306       | Network security                                        |
| KMS key rotation enabled and ≤ 90 days                 | Cryptography controls                                   |
| GKE shielded nodes enabled                             | Workload integrity                                      |
| GKE binary authorization enforced                      | Software supply chain                                   |
| SCC findings — High and Critical resolved within SLA   | Vulnerability management                                |
| IAM bindings — no broad `roles/owner` to user accounts | Privileged 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**.

<CardGroup cols={2}>
  <Card title="AWS" href="/integrations/aws">
    The AWS-side equivalent
  </Card>

  <Card title="Azure" href="/integrations/azure-ad">
    Microsoft Azure (cloud + Entra ID)
  </Card>
</CardGroup>
