# Connect your AWS account
> A CloudFormation stack creates a least-privilege IAM role Ownkube assumes via external ID. No access keys, no root credentials.
Ownkube runs infrastructure inside **your** AWS account. Connecting an account takes about three minutes and creates a single least-privilege IAM role. No access keys stored, no root credentials ever used.
Start at [**AWS onboarding**](https://app.ownkube.io/dashboard/aws-onboarding).
## Before you start
- An **AWS account** with permission to create IAM roles and CloudFormation stacks (typically an IAM user with `AdministratorAccess` or equivalent, needed only to **install** the stack, not to run Ownkube)
- An [Ownkube account](https://app.ownkube.io/signup)
- The **12-digit AWS account ID** (top-right of the AWS console) and the **region** you want to deploy into
## The three-step flow
1. **Open AWS onboarding**
Go to [**AWS onboarding**](https://app.ownkube.io/dashboard/aws-onboarding). The flow appears the first time you land on the dashboard; you can reopen it from the top nav anytime.
2. **Enter your account ID and region**
- **AWS account ID**, 12 digits, from the top-right account menu in the AWS console
- **Region**, where your clusters will run. Ownkube supports 17 regions including `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-south-1`.
Ownkube generates a **unique external ID** for your account. The external ID is baked into the stack and the IAM trust policy and prevents the [confused deputy](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) attack against cross-account roles.
3. **Deploy the CloudFormation stack**
Click **Deploy stack**. A new tab opens the AWS console with the template URL, stack name, and external ID pre-filled. Tick the IAM acknowledgement and click **Create stack**.
The stack creates a single IAM role named `ownkube-control-plane` with a trust policy that allows Ownkube's AWS account to assume it, only with the unique external ID issued in the previous step.
4. **Verify the connection**
Return to the Ownkube tab and click **Verify**. Ownkube assumes the role, confirms the external ID matches, runs a short account-setup workflow (creating shared IAM roles your clusters will use), and marks the account as verified.
The stack takes about two minutes to create. If verification times out, wait a few seconds and click **Verify** again. CloudFormation propagation isn't instantaneous.
## What the IAM role can do
The CloudFormation stack grants a scoped-down role that can only do what Ownkube needs:
| AWS service | What Ownkube does |
|---|---|
| [**EKS**](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) | Create, configure, and tear down managed clusters |
| [**EC2**](https://docs.aws.amazon.com/ec2/) | Provision instances for both EKS nodes and Starter (K3s) clusters |
| [**VPC**](https://docs.aws.amazon.com/vpc/) | Create the VPC, subnets, security groups, and networking for each cluster |
| [**IAM**](https://docs.aws.amazon.com/iam/) | Manage scoped-down roles used **by** the clusters (pass-role, not admin) |
| [**CloudFormation**](https://docs.aws.amazon.com/cloudformation/) | Update the bootstrap stack when permissions need to evolve |
| [**S3**](https://docs.aws.amazon.com/s3/) | Store infrastructure state and backups in buckets it creates |
| [**ACM**](https://docs.aws.amazon.com/acm/) | Provision and renew TLS certificates for public hostnames |
| [**Route 53**](https://docs.aws.amazon.com/route53/) | Manage DNS records for public hostnames |
| [**Elastic Load Balancing**](https://docs.aws.amazon.com/elasticloadbalancing/) | Create the load balancer that fronts public deployments |
| [**ECR**](https://docs.aws.amazon.com/ecr/) | Pull from ECR (when you connect an ECR registry) |
Ownkube does **not** get access to anything it didn't create. It has no read or write on your existing EC2 instances, VPCs, IAM principals, or buckets.
## No access keys, no root credentials
Ownkube never stores long-lived AWS credentials. Every action the platform takes in your account uses short-lived [STS](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) credentials obtained by assuming the IAM role (with the unique external ID) on demand. AWS has a good write-up on the [external ID pattern](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/) if you want to dig deeper.
## Disconnecting
Delete the CloudFormation stack at any time. Ownkube loses access immediately. Your clusters, databases, and load balancers **keep running**. Reconnecting is the same three-step flow.
If you delete the stack while clusters are still provisioned, Ownkube can't manage them until you reconnect. Your running workloads aren't affected. Deletes stop working until the stack is back.
## Troubleshooting
Verification fails with 'AccessDenied'
The IAM role trust policy may not have the correct external ID, or CloudFormation hasn't finished creating it. Wait 60 seconds and try again. If it still fails, delete and redeploy the stack.
Stack fails to create
Usually the caller doesn't have `iam:CreateRole` or `cloudformation:CreateStack` permission. Re-run with a principal that has the needed IAM and CloudFormation permissions.
I need to connect more than one account
Each AWS account gets its own external ID and its own stack. Repeat the flow for each. Clusters can live in any connected account.
- [Create a cluster](/docs/guides/create-cluster)
- [How it works](/docs/how-it-works)
---
**Don't see a feature you need?** Email [support@ownkube.io](mailto:support@ownkube.io?subject=Feature%20request). Ownkube is shaped by the teams using it and we ship what our users ask for.