Skip to main content
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

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.
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.
Safe to run again. Each step reports what it found rather than failing on anything that already exists. See kubox cloud bootstrap.

​
Two bootstrap commands — pick by account

The names are similar. The jobs are not. Both are run once per account, by an administrator, and both are safe to run again.
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 in CI instead.
Add --dry-run to see what would change. It reads, writes nothing, and prints what must already be true.

​
Connect the account

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 for every option.

​
Read a permission before you grant it

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.

​
Check a connection still works

status

Shows the last recorded result. That check may be days old.

verify

Tests the connection now, from both ends.
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.
The command disconnects, then lists what is still in your account — the role, the keys, the bucket — and what deleting each one costs you.
Deleting the role does not revoke access to credentials Kubox already holds. That is the step people stop before.
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.

Architecture

Where accounts sit among planes and clusters.

Management plane

What is doing the building.

All cloud commands

The full kubox cloud surface.