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. Get the values Argmin will provide — 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 Argmin.
  6. Rotation / removal / troubleshooting when you need it.

The trust boundary, in one paragraph

Argmin reads. Argmin 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