Google Cloud Platform
Connect your customers' GCP projects so your product can read resource inventory, IAM policies, and storage data without ever asking for a service account key. The customer's Google admin grants consent on Google's own screen, covering the scopes your integration needs.
What you can do
List Compute Engine instances and their metadata
Read instance names, machine types, zones, network tags, and running status across all zones in the customer's project. Useful for infrastructure inventory and cost-posture checks.
Inspect Cloud Storage buckets and access controls
Fetch bucket names, locations, storage classes, and IAM bucket policies. Surface public-access settings or overly broad allUsers bindings during a security review.
Read IAM project policies and role bindings
Pull the project-level IAM policy to see which principals hold which roles, including primitive roles like owner and viewer that are often over-granted in early GCP environments.
Audit GCP service accounts
List service accounts, their enabled or disabled status, and their project-level role bindings. Flag accounts with editor or owner roles and accounts that have not been used recently.
Read Cloud SQL and Cloud Run inventory
Fetch Cloud SQL instance names, database versions, and backup configuration, plus Cloud Run services and their most recent revision status, without needing individual API credentials for each service.
Query Cloud Asset Inventory for a full resource snapshot
Use the Cloud Asset API to export a point-in-time snapshot of all resources across the project in one call. Faster than scraping individual service APIs and covers resource types Askel does not yet query natively.
Building a cloud security baseline during customer onboarding
You sell a cloud security posture product. A new customer, Coastline Data Services, runs their analytics platform entirely on GCP across two projects: production and staging. Your product needs to read their compute inventory, check for publicly exposed storage buckets, and review IAM bindings before the kickoff call.
- 1
Admin clicks Connect GCP
Coastline's GCP project owner clicks Connect Google Cloud Platform in your product's onboarding wizard. Askel redirects to Google's OAuth consent screen, which lists the read-only API scopes needed (Cloud Resource Manager, Compute, Storage, IAM).
- 2
Consent and token exchange
The admin approves the consent. Google issues an access token and a refresh token. Askel stores only the refresh token; the access token is minted fresh on each API request and expires in one hour.
- 3
Repeat for staging project
The admin connects the staging project through the same flow. Each project gets its own OAuth connection in Askel, scoped to that project's data.
- 4
Inventory pull
Askel fans out calls across both projects: Compute Engine instances, Cloud Storage bucket policies, and the IAM project policy. Your product receives structured data within a few minutes.
- 5
Posture report before kickoff
Your dashboard shows Coastline's baseline: 22 Compute instances, 3 Cloud Storage buckets with allUsers read access, and 2 service accounts with editor role. The kickoff call starts from a concrete finding list rather than a blank slate.
OAuth 2.0
The customer's Google admin (or project owner) consents on Google's standard OAuth screen. Askel requests the minimum read-only scopes across Cloud Resource Manager, Compute, Storage, and IAM APIs. Only the refresh token is stored; access tokens are minted per request and expire after one hour. No service account JSON files are generated or transferred.
How Askel sits between your product and the customer's system
Related integrations
FAQ for Google Cloud Platform
Does the connecting user need to be an org-level admin?+
What happens if the customer revokes the OAuth consent?+
Can this work across multiple GCP projects in one organisation?+
Does Askel ever request write access to the customer's GCP project?+
catching drift before it breaks, and hitting go-live dates.
© 2025 Askel.ai. All rights reserved.