Connect your AWS account

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.

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
The 12-digit AWS account ID (top-right of the AWS console) and the region you want to deploy into

The three-step flow

Open AWS onboarding

Go to AWS onboarding. The flow appears the first time you land on the dashboard; you can reopen it from the top nav anytime.
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 attack against cross-account roles.
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.
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.

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	Create, configure, and tear down managed clusters
EC2	Provision instances for both EKS nodes and Starter (K3s) clusters
VPC	Create the VPC, subnets, security groups, and networking for each cluster
IAM	Manage scoped-down roles used by the clusters (pass-role, not admin)
CloudFormation	Update the bootstrap stack when permissions need to evolve
S3	Store infrastructure state and backups in buckets it creates
ACM	Provision and renew TLS certificates for public hostnames
Route 53	Manage DNS records for public hostnames
Elastic Load Balancing	Create the load balancer that fronts public deployments
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 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 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.

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 Provision your first cluster once the account is verified.

How it works Control plane vs data plane, and the trust model in detail.