Skip to content

Connect your cloud

Pick the cloud you’re connecting. Every guide follows the same six steps, so if you run multi-cloud you’ll see one predictable flow.

  •   AWS

    Cross-account IAM role, external-ID scoped. Grants read of Cost Explorer, the CUR bucket, Bedrock metadata, CloudWatch/CloudTrail, and identity inventory.

    Onboard AWS

  •   Google Cloud

    Service account via Workload Identity Federation: no exported keys. Grants BigQuery billing-export, Monitoring, Logging, and Service Usage read.

    Onboard GCP

  •   Azure

    Service principal via federated credential: no long-lived secret. Grants Reader, Cost Management Reader, and Monitoring Reader at subscription scope.

    Onboard Azure

The six-step shape

  1. Contact Venturi (contact@venturi.systems): your tenant is created and you receive your cloud-specific values: issuer / subject / account-id / external-id.
  2. Fill terraform.tfvars.
  3. terraform apply.
  4. Run the module’s scripts/verify.sh to confirm the trust boundary holds: read-only access works, write attempts fail.
  5. Hand outputs back to Venturi.
  6. Venturi confirms ingestion (≤ 1 business day); data appears in your dashboard roughly 1–2 hours after confirmation.

Rotation, removal, and troubleshooting are lifecycle tasks each cloud guide covers below its steps; they are not part of the connect flow.

The trust boundary, in one paragraph

Venturi reads. Venturi does not write into customer environments. Every module ends with a verify.sh that proves both halves of that claim: it exercises one Get/List call per granted service and one write call per service that should fail. Any 200 on a write API is a security finding and exits the script non-zero. The platform’s check_permissions.py enforces the same boundary at gate time, so an onboarding module that violates read-only constraints can’t merge to main.

Full trust & security model