Connect an AWS account
Give CBX Guard read-only visibility into an AWS account with a cross-account IAM role you create and control.
Connect an AWS account
Coming soon. CBX Guard is not yet generally available. This page describes the AWS connection model so you can review exactly what access it requests.
A verdict is only meaningful when it's resolved against your live infrastructure — is this resource reachable from the internet? is this a production account? To answer that, CBX Guard needs read-only visibility into the AWS account behind your IaC.
It gets that the way every modern SaaS does: you create a read-only IAM role in your account whose trust policy lets CBX Guard's control-plane account assume it. CBX Guard never receives long-lived keys into your account — it holds its own credentials and assumes your role on demand, scoped to read-only.
The three things that keep it safe
| Piece | What it is | Why it matters |
|---|---|---|
| Trust account | The only AWS account named in your role's trust policy. | The role trusts exactly one principal — CBX Guard's control plane — and nothing else can assume it. |
| External ID | A one-time secret (cbx-…) minted for your connection and baked into the trust policy's sts:ExternalId condition. | The confused-deputy guard. Even another customer of the same control-plane account can't assume your role without your exact External ID. |
| Permission ceiling | AWS-managed ViewOnlyAccess plus narrow read-only CloudTrail access. | No write action anywhere in the template. Deleting the stack revokes access instantly. |
Launch the role
CBX Guard creates the role through a CloudFormation stack you launch with one click — your account ID is never typed by hand; it's read from the role's ARN once the stack exists.
There are two ways to complete the connection. Both create the identical read-only, revocable role — they differ only in how the new role's ARN gets back to CBX Guard.
Automatic (recommended)
- In the Console, name the account (a nickname) and choose Automatic.
- Click Launch Stack. CBX Guard opens a pre-filled CloudFormation quick-create link in your AWS console — the template URL, the External ID, and a callback URL are all filled in for you.
- Review the template and create the stack.
- On creation, the stack calls CBX Guard back with the new role ARN. The Console verifies the External ID matches the secret it minted, and flips the account to Watching — no copy-paste needed.
Manual
Prefer not to grant the callback? Choose Manual: launch the same stack, then copy the Role ARN from the CloudFormation outputs and paste it into the Console. CBX Guard assumes the role to confirm the connection, then flips it to Watching.
Whichever variant you pick, the role is identical: read-only, scoped by your External ID, and revocable the instant you delete the stack.
What CBX Guard does and does not do
It does: call Describe*, Get*, and List* APIs to resolve a change against live state —
reachability (public subnets, internet-facing load balancers, public-accessibility flags), production
scope, and the current baseline — and read CloudTrail to understand what changed.
It does not: create, modify, or delete any resource. There is no write permission in the template. CBX Guard never stores long-lived credentials in your account; it assumes the role per session via AWS STS.
Scan the account
Connecting the role grants read access; the scan is what uses it. Once the account shows Watching, run a scan to inventory its resources and network graph — that captured landscape is what fills the Landscape and Context views and what the account-aware review resolves each change against. Until an account is scanned, reachability is not yet resolved, and verdicts fall back to offline reasoning.
Scan your account →
What the read-only scan captures, the reachability tri-state, and how it sharpens every verdict.
Disconnecting
Delete the CloudFormation stack in your account. That removes the role and revokes CBX Guard's access immediately — there's nothing left for it to assume.