Connect one Google Cloud root.

Set up or upgrade a read-only Google Cloud service account so the Sythe Labs platform can read Cloud Asset Inventory and Artifact Registry container vulnerability findings for exactly one resource root.

Context:
- I am already signed in to the gcloud CLI with an account that can administer IAM at the root below and enable APIs in each registry project.
- Use the gcloud CLI and ordinary POSIX shell syntax only. Do not open the Google Cloud console and do not install anything.

Ask me for these five values first, then echo them back before running anything:
1. ROOT_KIND - organization, folder, or project. This is the highest resource whose descendants Sythe Labs should read.
2. ROOT_ID - the numeric id for an organization or folder, or the project id for a project.
3. SA_PROJECT - the project id that owns the service account and the Cloud Asset Inventory API. It may be the same project as ROOT_ID.
4. REGISTRY_PROJECT_IDS - every project under the root that hosts an in-scope Artifact Registry Docker repository. APIs are enabled in these projects.
5. CONNECTION_MODE - new_connection or upgrade_existing_connection. For an upgrade, also ask for the exact existing service-account email shown on the Sythe Labs Google Cloud integration and use it unchanged. Do not create a key or reconnect during an upgrade.

After I confirm the values, assign them to quoted shell variables. Set REGISTRY_PROJECT_IDS as a shell array with one quoted project id per item. For new_connection, set SA_EMAIL to sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com and KEY_FILE to an unused absolute local path. For upgrade_existing_connection, set SA_EMAIL to the exact existing service-account email I provided.

Run these steps in order. Stop at the first failure and show me the exact gcloud error.

Step 1 - enable the required APIs. Enable Cloud Asset Inventory in the service-account project. Enable Artifact Registry and Container Scanning in every registry project. Container Scanning enables Container Analysis for vulnerability metadata.
gcloud services enable cloudasset.googleapis.com --project="$SA_PROJECT"

for REGISTRY_PROJECT_ID in "${REGISTRY_PROJECT_IDS[@]}"; do
  gcloud services enable artifactregistry.googleapis.com containerscanning.googleapis.com --project="$REGISTRY_PROJECT_ID"
done

Step 2 - get or create exactly one dedicated service account. Run this describe command first. For upgrade_existing_connection, it must succeed and you reuse that exact account. For new_connection, if it succeeds, reuse the account. Only if it reports NOT_FOUND, run the create command below. If it reports any other error, stop. Never create a second service account.
gcloud iam service-accounts describe "$SA_EMAIL" --project="$SA_PROJECT"

Only after a new_connection describe reports NOT_FOUND, run:
gcloud iam service-accounts create sythe-labs-asset-reader \
  --project="$SA_PROJECT" \
  --display-name="Sythe Labs Cloud and Artifact Registry reader"

For new_connection, the created account email is sythe-labs-asset-reader@$SA_PROJECT.iam.gserviceaccount.com.

Step 3 - grant roles/serviceusage.serviceUsageConsumer on the service-account project:
gcloud projects add-iam-policy-binding "$SA_PROJECT" \
  --member="serviceAccount:$SA_EMAIL" \
  --role="roles/serviceusage.serviceUsageConsumer" \
  --condition=None

Step 4 - grant these three roles at the root so they inherit to every child resource:
- roles/cloudasset.viewer
- roles/artifactregistry.reader
- roles/containeranalysis.occurrences.viewer

ROOT_ROLES=(
  "roles/cloudasset.viewer"
  "roles/artifactregistry.reader"
  "roles/containeranalysis.occurrences.viewer"
)

for ROOT_ROLE in "${ROOT_ROLES[@]}"; do
  case "$ROOT_KIND" in
    organization)
      gcloud organizations add-iam-policy-binding "$ROOT_ID" \
        --member="serviceAccount:$SA_EMAIL" \
        --role="$ROOT_ROLE" \
        --condition=None
      ;;
    folder)
      gcloud resource-manager folders add-iam-policy-binding "$ROOT_ID" \
        --member="serviceAccount:$SA_EMAIL" \
        --role="$ROOT_ROLE" \
        --condition=None
      ;;
    project)
      gcloud projects add-iam-policy-binding "$ROOT_ID" \
        --member="serviceAccount:$SA_EMAIL" \
        --role="$ROOT_ROLE" \
        --condition=None
      ;;
    *)
      echo "ROOT_KIND must be organization, folder, or project" >&2
      exit 1
      ;;
  esac
done

Step 5 - create one JSON key only for new_connection. Choose an unused local path, stop if it already exists, and never overwrite a key file. For upgrade_existing_connection, skip this step entirely and keep the JSON key already stored by Sythe Labs.
if [ "$CONNECTION_MODE" = "new_connection" ]; then
  if [ -e "$KEY_FILE" ]; then
    echo "KEY_FILE already exists: $KEY_FILE" >&2
    exit 1
  fi

  gcloud iam service-accounts keys create "$KEY_FILE" \
    --iam-account="$SA_EMAIL" \
    --project="$SA_PROJECT"
fi

If Step 5 fails because of the constraints/iam.disableServiceAccountKeyCreation organization policy, stop and tell me. A new connection requires a user-managed JSON key and has no OAuth or Workload Identity Federation fallback. An upgrade continues to use the key already stored by Sythe Labs.

Rules:
- Grant exactly the four roles above. Do not grant Owner, Editor, Viewer, or any other role, do not enable another API, and do not create or change any other resource.
- Never print the contents of the key file and never send it anywhere. Leave it on my machine.
- Do not disconnect, replace the key, or upload a key during upgrade_existing_connection. After IAM propagation, the existing integration can use the new Registry access on its next sync.

For new_connection, when every step succeeds, print exactly these four lines:
ROOT_TYPE=<organization, folder, or project>
CANONICAL_ROOT=<organizations/ID, folders/ID, or projects/PROJECT_ID>
SERVICE_ACCOUNT=<service-account email>
KEY_FILE=<absolute path to the JSON key file>

I select ROOT_TYPE as the root type, paste CANONICAL_ROOT into the canonical resource name field, and upload KEY_FILE on the Sythe Labs Google Cloud integration page.

For upgrade_existing_connection, when every step succeeds, print exactly these four lines:
ROOT_TYPE=<organization, folder, or project>
CANONICAL_ROOT=<organizations/ID, folders/ID, or projects/PROJECT_ID>
SERVICE_ACCOUNT=<service-account email>
NEXT_ACTION=Run Sync from the existing Sythe Labs Google Cloud integration without reconnecting or uploading a key.

Container Scanning starts on new image pushes. Existing images need a new push before Google creates vulnerability results for them.