Connect one Google Cloud root.

Keyless is recommended. A service-account key remains available.

Both modes use the same four predefined roles. Cloud Asset Viewer, Artifact Registry Reader, and Container Analysis Occurrences Viewer go at the selected root in either mode. Service Usage Consumer goes in the workload identity pool project for keyless access, or in the service-account project for a key. Both collect the same data, except that registry vulnerability scanning may not work under keyless access, as explained below. Choose one when you connect. A key connection can move to keyless later without changing its root.

Validation checks different things in each mode. Keyless validation exchanges a token and reads one page of Cloud Asset Inventory at the root, which proves the provider and root access but not every role. Key validation reads the complete Cloud Asset Inventory resource and IAM policy snapshots at the root before the key is stored. Neither reads a registry, so registry roles and APIs are first checked by the first sync.

Keep the identity, roles, and console under customer control.

Your Google Cloud administrators create and own every resource in this guide. Do not ask Sythe Labs staff to enter the Google Cloud console, and never paste a credential into a support request.

• 01

  One authoritative organization, folder, or project root for the inventory boundary.

• 02

  Every project under that root with an in-scope Artifact Registry Docker repository.

• 03

  Organization owner or administrator access to the signed-in Sythe Labs platform Integrations page.

Each mode also needs its own project and permissions.

Trust one issuer, grant four roles to one principal.

The signed-in Google Cloud integration page reserves the issuer and subject for your organization and shows them for you to copy into these steps. No key is created, uploaded, or stored. You also download no credential configuration file and set no token URL: Sythe Labs runs the token exchange from its side.

1. 01
   Reserve a setup identity

   Open the signed-in Google Cloud integration page, choose Keyless, and select Reserve setup identity. The page shows the issuer URI, subject, and attribute mapping reserved for your organization. Reserving again returns the same values, and they stay reserved after a disconnect.

2. 02
   Allow the issuer if your organization restricts providers

   Check the effective constraints/iam.workloadIdentityPoolProviders policy on the pool project. Only if it already lists allowed values, add the issuer URI to them before you create the provider. See the organization policy note above.

3. 03
   Create a workload identity pool

   Create a pool in the project that will hold it. Pool and provider IDs are 4 to 32 lowercase letters, digits, or hyphens, and cannot start with gcp-.

4. 04
   Create an OIDC provider

   Create an OIDC provider in that pool with the issuer URI exactly as shown and the attribute mapping google.subject=assertion.sub. Leave allowed audiences empty: Sythe Labs presents the provider's own resource name as the audience, which Google Cloud accepts by default. Do not upload a JWKS. Google Cloud reads the current signing keys from the issuer, so Sythe Labs key rotation needs nothing from you.

5. 05
   Enable the APIs

   Enable Cloud Asset Inventory in the pool project, and Artifact Registry and Container Scanning in every project with an in-scope Docker repository.

6. 06
   Grant the four roles to the principal

   Grant Service Usage Consumer on the pool project, and Cloud Asset Viewer, Artifact Registry Reader, and Container Analysis Occurrences Viewer at the root. Grant them directly to the principal below. It names only the Sythe Labs subject for your organization, so no other identity in the pool gains access.

7. 07
   Validate and connect

   On the signed-in page, enter the pool project number, pool ID, provider ID, and the root, then select Validate and connect. Sythe Labs exchanges a token with Google Security Token Service and reads one page of Cloud Asset Inventory at the root. Nothing is saved unless both succeed. That proves the provider and root access, not every role: validation reads no IAM policy and no registry, so a connection that validates can still fail its first sync, and the signed-in status page then names the reason. Google Cloud can take several minutes to apply a new provider or role, so if validation reports one you just created or granted, wait a few minutes and validate again.

Four predefined roles and the APIs they read through, in either mode.

A keyless connection grants each role to the principal above. A key connection grants it to the dedicated service account. Only the quota project differs: Service Usage Consumer and the Cloud Asset Inventory API go in the workload identity pool project for keyless access, and in the service-account project for a key.

The alternative: a dedicated service account and one JSON key.

Copy the prompt below into a CLI coding agent. It asks for the root, service-account project, Registry projects, and whether this is a new connection or an upgrade. For an upgrade, it reuses the existing service account and encrypted key: grant the new access, then run Sync without disconnecting or reconnecting.

1. 01

   Choose the authoritative organization, folder, or project root and copy its canonical resource name.

2. 02

   Choose or confirm the customer-owned project that owns the dedicated service account.

3. 03

   Enable the Cloud Asset Inventory API in the service-account project, and Artifact Registry and Container Scanning in every project with an in-scope Docker repository.

4. 04

   Create or reuse the dedicated service account for the Sythe Labs platform connection.

5. 05

   Grant Service Usage Consumer to that service account in the project that owns it.

6. 06

   Grant Cloud Asset Viewer, Artifact Registry Reader, and Container Analysis Occurrences Viewer at the selected root with inherited coverage for every intended child resource.

7. 07

   Create and download one JSON key only for a new connection if organization policy permits user-managed keys.

8. 08

   For a new connection, open the signed-in Integrations page, choose Service-account key, enter the canonical root, and select the JSON key file. Sythe Labs reads the complete Cloud Asset Inventory resource and IAM policy snapshots at the root before it stores the key.

9. 09

   For an existing connection, keep the stored JSON key, wait for IAM propagation, and run Sync. Do not disconnect or reconnect.

Move an existing key connection to keyless without a gap.

The move keeps the connection, its root, and its inventory. It switches authentication only after Google Cloud accepts the keyless identity.

1. 01

   Open the connected Google Cloud status page and select Move to keyless access. The connection keeps its root.

2. 02

   Review the preview. It warns that registry vulnerability scanning may stop under keyless access when the connection collects registry data, holds open or triaged registry findings, or has registry coverage Sythe Labs cannot read. The warning never blocks the move.

3. 03

   Reserve the setup identity, then create the pool, provider, and role bindings for the same root as in the keyless steps above.

4. 04

   Enter the pool project number, pool ID, and provider ID, then select Validate and move. The connection keeps syncing with its key until Google Cloud accepts the keyless identity. If validation fails, nothing changes.

5. 05

   After the move, Sythe Labs no longer stores the key, but Google Cloud accepts it until you delete or disable it. Delete the key under IAM & Admin > Service accounts > Keys, then remove the service account, or its role bindings, if nothing else uses them.

Fixed Cloud Asset types and Registry vulnerability occurrences.

The connector supplies these exact asset-type filters to the two Cloud Asset Inventory reads. It also lists Docker images plus VULNERABILITY and DISCOVERY occurrences in each configured Registry project. Discovery data prevents an unscanned or expired image from appearing clean. It does not request an unbounded asset catalog.

8 types become inventory

Supporting configuration checks

• Public SSH ingress on Compute Engine firewall rules

• Public Cloud Storage bucket IAM

• Cloud Storage bucket versioning or retention protection

• Automated Cloud SQL backups

Project and firewall assets support lookup and checks but do not become inventory rows. The connector does not call Compute Engine, Cloud Storage, Cloud SQL, AlloyDB, Resource Manager, export, feed, or search APIs. Container Scanning begins with new image pushes; existing images need a new push before Google creates vulnerability results. A failed or incomplete CAI or Registry collection preserves the prior complete data and never produces a false pass.

The customer controls repair, replacement, and removal.

A keyless connection holds no secret: Sythe Labs stores only non-secret configuration, such as the root, the pool and provider reference, and the subject reserved for your organization. A key connection's JSON key is stored as an encrypted opaque secret and used only for the bounded SDK operations in this guide. Google Cloud remains the source of truth for what it trusts and for key status.

Resolve the stable reason shown in the signed-in status page.

Match the reason code to the customer-owned action below. Keep a safe request identifier for support, but never copy a credential or raw provider response into a message.