GCP Cloud
The GCP Cloud connector reads the resource inventory of a Google Cloud project (read-only, via a service account you create) and maps it to your architecture model: the as-built view of what is actually running. See Connectors for the general workflow.
Prerequisites
Section titled “Prerequisites”You need the Cloud Asset API enabled on the project and a service account with the Cloud Asset Viewer role.
- Enable the API: in the GCP console, go to APIs & Services → Library, search for Cloud Asset API, and click Enable (or run
gcloud services enable cloudasset.googleapis.com). - Create the service account: IAM & Admin → Service Accounts → Create service account. Name it (e.g.
archngn-discovery). - Grant it the Cloud Asset Viewer role (
roles/cloudasset.viewer) on the project. - Optional but recommended: also grant Cloud Run Viewer (
roles/run.viewer) so the connector can capture Cloud Run container images for cross-layer linking. Without it, Cloud Run services are still discovered, just without image detail. - Create a key: open the service account → Keys → Add key → Create new key → JSON. Download the key file.
Configuration
Section titled “Configuration”| Field | Value |
|---|---|
| Project ID | The GCP project ID (e.g. my-gcp-project), not the project number |
| Service-account key (JSON) | Paste the entire downloaded JSON key file |
The key must be a service-account key containing client_email and private_key, not an API key or OAuth client. The Project ID is a non-secret identifier and stays in the connector configuration; the key is stored in an encrypted secrets store and never shown again. To rotate, create a new key on the service account, paste it over the placeholder, and delete the old key in GCP.
What a Run Produces
Section titled “What a Run Produces”The connector lists every asset in the project through the Cloud Asset Inventory, grouped by service (Compute Engine, Cloud Run, Cloud SQL, Pub/Sub, …) and enriched with Cloud Run container images where permitted. The AI then maps the inventory to your metamodel:
- Objects on the Technology and Data layers only: managed services become Technology Service, VMs/containers/serverless become Compute, networks and load balancers become Network, databases and storage become Data Store. Well-known asset types are classified deterministically from the resource ID.
- Associations backed by concrete evidence. No evidence, no edge.
- Cross-layer links: Cloud Run images and resource labels are captured so as-built objects can be linked (Deployed To) to the Application objects discovered by the GitHub connector.
Your Application and Business layers are never invented from infrastructure. The logical view comes from code and document sources and is linked to the as-built objects instead.
- Label your resources. Consistent labels give the mapper stronger grouping and linking signals.
- The connector works regardless of which cloud your ArchNGN environment runs on.
- Re-runs are stable: resources are matched by resource ID, so renames update objects in place.
- Each project is its own estate. Same-named workloads in different clouds or projects are kept as separate objects, never merged.