Connecting a cloud account

Each cloud provider gets its own card on Clouds: AWS, Google Cloud, and Azure. A card with no accounts yet shows a connect button. One that already has an account shows connect another account instead, because you can connect multiple accounts per provider (for example, separate AWS accounts for staging and production).

Clicking either opens the cloud-connect modal, titled Connect <Provider> with a "Read-only · encrypted at rest" subtitle. It has three parts, top to bottom.

1. The setup guide

Before the form, a panel explains how to obtain the right credentials, opening with "We only ever read." and a copyable shell command that mints a least-privilege identity, plus a "Provider docs →" link. This is provider-specific.

AWS: create a read-only IAM user and access key.

aws iam create-user --user-name ace-discovery
aws iam attach-user-policy --user-name ace-discovery \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
aws iam create-access-key --user-name ace-discovery

Google Cloud: create a Viewer service account and download its key.

gcloud iam service-accounts create ace-discovery \
  --display-name="ACE Discovery"
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
  --member="serviceAccount:ace-discovery@$PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/viewer"
gcloud iam service-accounts keys create key.json \
  --iam-account="ace-discovery@$PROJECT_ID.iam.gserviceaccount.com"

Azure: create a Reader service principal.

az ad sp create-for-rbac --name ace-discovery \
  --role Reader \
  --scopes /subscriptions/$SUBSCRIPTION_ID
# appId → Client ID · password → Client Secret · tenant → Tenant ID

Each command has its own copy button (flips to copied for 1.5 seconds).

2. The credential form

Below the guide, one field per piece of credential the provider needs. Required fields are marked; optional ones carry an "(optional)" label next to the field name. Long values (like a JSON key) render as a monospace textarea instead of a single-line input, and secrets render as a password field.

Provider	Fields
AWS	Access Key ID (AKIA…), Secret Access Key, Default region (for example us-east-1); all required
Google Cloud	Service Account JSON (paste the full key file; the field's help text notes the project_id is read from it automatically), required
Azure	Tenant ID, Client ID (App ID), Client Secret (required); Subscription ID (optional), with the help text "Leave blank to auto-discover every subscription the principal can read"

The "Validate & connect" button stays disabled until every required field has a value.

3. Validation and the result

Submitting calls the provider's own API with the pasted credentials before anything is saved, so a typo and a valid-but-under-permissioned credential never look the same:

• Wrong or unparsable credentials: the modal stays open and shows a red error banner with the failure detail (for example an auth error from the provider) instead of a generic message.
• Valid credentials that cannot list resources: the modal advances to a success screen ("Connected", with the resolved account name), but shows a yellow warning banner with the specific permission gap, because the credential itself is fine even though it cannot yet do what Discovery needs.
• Valid and able to list: the success screen shows cleanly with just the account name and a Done button.

Either way, once "Connected" appears, the new account shows up as a card entry back on Clouds, and closing the modal (Done, the ✕, or clicking outside) refreshes the list.

What is the account for?

A connected cloud account exists to power infrastructure discovery: "Discover infra" runs a census against it, and "Investigate" turns the confirmed inventory into a written Infra Map. See Managing cloud accounts for what happens after you have more than one account for the same provider, and for reconnecting or disconnecting.

What do you need?

Requires org:integrations:manage (see Clouds permissions) and a selected workspace. Connecting is blocked with "Select a workspace to connect" if none is active.