> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kubox.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud accounts

> Connect an AWS account so Kubox can build clusters in it, and keep control of what it may do.

Connect your AWS account and Kubox can build clusters in it. You stay in control of what it may do, and everything it builds stays yours.

## Set the limits first

```bash theme={null}
kubox cloud bootstrap aws
```

Run this as an AWS administrator. It creates the limits Kubox works inside, and the single identity it connects as.

Everything Kubox does afterwards happens inside those limits. It cannot reach back to the credentials you ran this with.

<Note>
  Kubox never sets its own limits — that step is yours. The console shows you exactly what to run, so your security team can read it first.
</Note>

Safe to run again. Each step reports what it found rather than failing on anything that already exists. See [`kubox cloud bootstrap`](/reference/cli/kubox_cloud_bootstrap).

## Two bootstrap commands — pick by account

The names are similar. The jobs are not.

| Command | Run it in | Creates |
| - | - | - |
| [`kubox cloud bootstrap aws`](/reference/cli/kubox_cloud_bootstrap) | An account you are **connecting** | The limits, and the identity Kubox connects as |
| [`kubox admin aws bootstrap`](/reference/cli/kubox_admin_aws_bootstrap) | The account a **plane builds from** | Keys, a state bucket, and five IAM roles |

Both are run once per account, by an administrator, and both are safe to run again.

<Warning>
  Do not run either in CI. They create IAM roles, which means the power to grant any permission — so anyone who compromises the pipeline owns the account. Run [`kubox admin aws verify`](/reference/cli/kubox_admin_aws_verify) in CI instead.
</Warning>

<Tip>
  Add `--dry-run` to see what would change. It reads, writes nothing, and prints what must already be true.
</Tip>

## Connect the account

```bash theme={null}
kubox cloud connect aws production
```

Creates the role Kubox builds with, somewhere to keep the build state, and two encryption keys — all in your account. If it stops partway, run it again to carry on.

The two keys must be different: one protects the credentials Kubox stores, the other protects your build state.

To let Kubox manage DNS, pass `--hosted-zone` to limit it to one zone. Leave it out and the connection touches no DNS at all. See [`kubox cloud connect`](/reference/cli/kubox_cloud_connect) for every option.

## Read a permission before you grant it

```bash theme={null}
kubox admin aws policy --identity runner --plane-account 123456789012
```

Prints the exact IAM policy for one identity. It makes no AWS calls and needs no credentials, so you can review it before granting it, or compare it against what is attached today. See [`kubox admin aws policy`](/reference/cli/kubox_admin_aws_policy).

## Check a connection still works

<CardGroup cols={2}>
  <Card title="status" icon="eye" href="/reference/cli/kubox_cloud_status">
    Shows the last recorded result. That check may be days old.
  </Card>

  <Card title="verify" icon="circle-check" href="/reference/cli/kubox_cloud_verify">
    Tests the connection now, from both ends.
  </Card>
</CardGroup>

```bash theme={null}
kubox cloud verify production
```

Use `verify` when you need to know the connection works today. `status` only repeats the last result, so a green there is not proof.

`verify` checks from both ends because each catches what the other misses. A role can look correct in your account and still be one AWS will not accept — or accept a connection it should have refused.

## Disconnecting is not revoking

This is the distinction worth remembering.

```bash theme={null}
kubox cloud disconnect production
```

| | What happens |
| - | - |
| **Disconnect** | Kubox forgets the account. Nothing in AWS is deleted. |
| **Revoke** | You remove the access in AWS. Only you can do this. |

The command disconnects, then lists what is still in your account — the role, the keys, the bucket — and what deleting each one costs you.

<Warning>
  Deleting the role does **not** revoke access to credentials Kubox already holds. That is the step people stop before.
</Warning>

Kubox leaves those alone on purpose. They are the record of what was built, and the keys that open it. If Kubox could delete them, Kubox would hold the power this boundary exists to deny it.

## Related

<CardGroup cols={3}>
  <Card title="Architecture" icon="diagram-project" href="/concepts/architecture">
    Where accounts sit among planes and clusters.
  </Card>

  <Card title="Management plane" icon="tower-control" href="/concepts/management-plane">
    What is doing the building.
  </Card>

  <Card title="All cloud commands" icon="terminal" href="/reference/cli/kubox_cloud">
    The full `kubox cloud` surface.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.