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.

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.

Tip

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 serviceWhat Ownkube does
EKSCreate, configure, and tear down managed clusters
EC2Provision instances for both EKS nodes and Starter (K3s) clusters
VPCCreate the VPC, subnets, security groups, and networking for each cluster
IAMManage scoped-down roles used by the clusters (pass-role, not admin)
CloudFormationUpdate the bootstrap stack when permissions need to evolve
S3Store infrastructure state and backups in buckets it creates
ACMProvision and renew TLS certificates for public hostnames
Route 53Manage DNS records for public hostnames
Elastic Load BalancingCreate the load balancer that fronts public deployments
ECRPull 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.

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


Don't see a feature you need? Email support@ownkube.io. Ownkube is shaped by the teams using it and we ship what our users ask for.

On this page