Skip to content
Edka infrastructure automation platform Edka infrastructure automation platform Edka
SYS.DOCS // DOCS

AWS

Edka creates Kubernetes clusters in your own AWS account: K3s on EC2 instances, with the VPC, volumes and load balancers in the same account. AWS bills them to you. Edka works through an IAM role you create in the account with Edka’s CloudFormation stack, and the role trusts Edka only when Edka presents your organization’s external ID.

Prerequisites

Section titled “Prerequisites”
  • An AWS account where you can create a CloudFormation stack with IAM resources.
  • The owner or admin role in your Edka organization.

Connect an account

Section titled “Connect an account”
  1. Open Settings > Integrations > AWS and click Connect an AWS account.
  2. Enter a Name for the account and pick the Region the CloudFormation console opens in, then click Continue. The role works in every region.
  3. Click Launch stack in AWS. The CloudFormation console opens with Edka’s template and your organization’s external ID filled in.
  4. Acknowledge that the stack creates IAM resources, and create the stack.
  5. When the stack reaches CREATE_COMPLETE, copy RoleArn from its Outputs tab.
  6. In Edka, paste it into Role ARN and click Connect.

Edka assumes the role with the external ID. The account page then shows Connected with the AWS account ID, and the account appears under AWS account when you create a cluster.

What the stack creates

Section titled “What the stack creates”
  • The IAM role EdkaProvisioner under the /edka/ path. It trusts Edka’s AWS principal with the condition sts:ExternalId set to your organization’s external ID.
  • Policies that let the role create, change and delete the resources of Edka’s clusters: EC2 instances, the VPC and its subnets, security groups, Elastic IPs, launch templates and Auto Scaling groups, load balancers, and the IAM roles of the cluster’s nodes.
  • The policy EdkaNodePermissionsBoundary under /edka/. Edka sets it as the permissions boundary of every role it creates for a cluster, so a node role never holds more than the boundary allows.

To create the role without CloudFormation, expand Create the role manually on the account page. It shows the trust policy with your external ID and links the template that defines the permissions.

Change the role

Section titled “Change the role”

On a connected account, paste the ARN of another role into Role ARN and click Save. Edka assumes the new role first:

  • When it can, the account switches to the new role, and every cluster in the account moves to it.
  • When it cannot, the account keeps its current role, and the reason shows on the field.

While clusters run in the account, the new role must belong to the same AWS account. It must also trust the External ID shown on the account page.

Update the stack

Section titled “Update the stack”

A newer Edka can use a permission that an older stack does not grant, such as ec2:RebootInstances to power cycle a node that does not come back from an OS update. An operation that needs a missing permission fails on its first attempt, and its error starts with: “The role Edka uses in the AWS account lacks a permission this needs.”

To grant it, update the stack to the latest template:

  1. In the CloudFormation console, select the stack and click Update.

  2. Choose Replace existing template and enter this Amazon S3 URL:

    https://edka-cfn-226705211158.s3.eu-central-1.amazonaws.com/aws/edka-account-v1.yaml

  3. Keep the parameters as they are and update the stack.

A role created by hand needs the permission added to its policies instead.

Disconnect an account

Section titled “Disconnect an account”

Open the account and click Disconnect. Edka refuses while a cluster runs in the account. Disconnecting stops Edka from using the role. The role stays in your AWS account until you delete the stack.

Troubleshooting

Section titled “Troubleshooting”

The role can be assumed without the external ID. The role’s trust policy lacks the sts:ExternalId condition. Add it with the external ID from the account page, or create the role from the stack.

AWS refused to let Edka assume the role. The trust policy names another principal or another external ID, or the role ARN has a typo. Compare the trust policy with the one under Create the role manually.

A cluster operation fails with a quota error. Before it launches anything, Edka checks two quotas in the cluster’s region and names the one that is too low:

  • Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances (L-1216C47A). New AWS accounts start at 5 vCPUs.
  • EC2-VPC Elastic IPs (L-0263D0A3). The default is 5.

Request an increase in the Service Quotas console, then retry the operation.

Section titled “Related docs”