Skip to main content
Every AWS permission the Tier A install uses, in three parts:
  • what the installer needs in your account;
  • what the preflight needs to check your account before you install;
  • what the Genesis management agent may do once it is running.
The tables below are copied mechanically from the lists the installer, the preflight and the agent role actually use, and a test fails if a table and its list ever disagree. Section 1 explains where the installer’s list itself comes from.

​
1. The installer

The principal running the install needs these 123 actions in the sheet’s account: in the sheet’s region, plus the global IAM and AWS Budgets actions. This list is what the preflight simulates for you: if any action is missing, the preflight names it and the principal to grant it to, before anything is created. Where this list comes from. It is every action that the install and teardown of a real Tier A run actually called, read from AWS CloudTrail event history. Reading the installer’s code alone cannot enumerate it, because the infrastructure tool it uses (the OpenTofu AWS provider) makes calls of its own. Added to those are actions that AWS authorizes without logging them as their own event (iam:PassRole and the tag-on-create permissions), and teardown actions that run only when there is something to clean up. Genesis refreshes the list from CloudTrail whenever the AWS provider or an OpenTofu module version changes. The ready-to-attach policy. uv run python -m scripts.aws_tier_a permission-policy --sheet decision-sheet.json prints an IAM policy granting exactly these actions, scoped to your sheet:
  • reads (Describe, List, Get, View) on every resource;
  • IAM role and policy writes, including iam:PassRole, only on roles and policies whose names start with your cluster name. Those are the cluster, node, storage-driver and agent roles the install creates;
  • OIDC providers for any EKS cluster in your region (AWS names them by an ID, not by cluster);
  • service-linked roles (creation and cleanup) only for EKS, EKS node groups, Auto Scaling and Elastic Load Balancing;
  • EKS writes only on your cluster and its node groups, add-ons, access entries and Pod Identity associations. Cluster creation itself is limited to your region, because AWS does not scope it by cluster name;
  • the cluster’s log group, and the genesis-tier-a-daily budget;
  • network, instance and Auto Scaling writes limited to your region. AWS cannot scope these by resource, so the principal could change other VPCs in that region.
This scoping is not a privilege boundary. Treat the installing principal as administrator-equivalent. With role creation, policy attachment and iam:PassRole on roles named after the cluster, plus instance launch in the region, the principal can still escalate to account administrator. For example, it could create such a role, attach an administrator policy, and pass the role to an instance. Remove the principal (or this policy) after the install, or use a dedicated account. The policy was checked against AWS’s policy simulator. Every installer action was allowed on the resources a real install uses, and writes outside the sheet’s target (other roles, other clusters, other regions, other log groups and budgets) were denied.

​
2. The preflight

The preflight never changes your account; it reads only. Besides simulating the installer actions above (iam:SimulatePrincipalPolicy), it needs these reads: ec2:DescribeAddresses, ec2:DescribeAvailabilityZones, ec2:DescribeInstances, ec2:DescribeNatGateways, ec2:DescribeSubnets, ec2:DescribeVpcs, iam:GetRole, iam:SimulatePrincipalPolicy, servicequotas:GetServiceQuota, sts:GetCallerIdentity. servicequotas:GetServiceQuota is not an installer action, so grant it as well. Run the preflight as the same principal that will install: it checks the permissions of the principal it runs as. If a read is denied, the preflight fails a preflight_reads check that names the action to grant, and it keeps the results of the checks it had already completed.

​
3. The Genesis management agent (read side only)

The agent runs in your cluster. When infrastructure reporting is turned on for your install (it is off by default; the sheet’s infrastructure_reporting turns it on), the agent reads the state of the AWS infrastructure under it: the cluster version, node-group health, instance health and add-on versions. It reports them to Genesis every 15 minutes, with alarms. It changes nothing in AWS. The role below exists either way, so that turning reporting on needs no new permission. Infrastructure maintenance (scaling, node recovery, Kubernetes upgrades) is still carried out by Genesis with you, not by the agent. Its role is created by the install, in your account, and is used through EKS Pod Identity. No Genesis-held key or long-lived credential is involved. The role trusts only the EKS Pod Identity service, and only for your account, this cluster’s ARN, namespace genesis and service account genesis-management-agent. Regional scope of the two EC2 reads. AWS offers no resource-level scope for these two actions. So the role can read the metadata of every EC2 instance in the same account and region, not only this cluster’s nodes. The agent filters to this cluster’s node groups by tag, but that filtering is not an authorization boundary. If other workloads share the account and region, take this into account, or use a dedicated account. The role has no write permissions, no secret access, no IAM administration, no iam:PassRole and no role chaining.

​
4. Stated limits

  • How the vCPU-quota refusal was verified. The preflight’s quota reads were verified against a real AWS account. Its refusal, when the vCPU quota is too small for the requested node group, was verified only by Genesis’s automated tests of the same code. That account’s quota was larger than any node group a sheet can request, so a live refusal could not be shown.
  • Kubernetes API address changes. The install records the cluster’s Kubernetes API addresses. If AWS later changes them, the running agent and application are not affected. A later re-run of the installer on that same cluster, which Genesis performs, is refused until Genesis records the new addresses.
  • The agent’s AWS view is read-only. Automatic infrastructure repair is not part of this version.