Tier A decision sheet

{
  "schema_version": "genesis-tier-a-decision-sheet-v1",
  "account_id": "123456789012",
  "region": "us-east-2",
  "cluster_name": "genesis-prod",
  "api_cidrs": ["203.0.113.10/32"],
  "daily_budget_usd": 200,
  "maintenance_window": {
    "day": "sunday",
    "start": "02:00",
    "timezone": "America/New_York",
    "duration_minutes": 120
  },
  "upgrade_policy": "approval-required",
  "profile": "<profile name Genesis gives you>",
  "nodes": {"instance_type": "t3.large", "count": 2},
  "budget_alert_email": "[email protected]",
  "automatic_operation_consent": true,
  "sign_in": {
    "domain": "your-tenant.us.auth0.com",
    "client_id": "<32-character Auth0 application client ID>",
    "audience": "https://genesis-api"
  }
}

​

Fields

​

What each decision does

• Target and profile. The profile is reviewed by Genesis and lists the exact account, region and cluster it approves. The install refuses a sheet whose target its profile does not approve, so a mistyped account or region cannot install somewhere unintended.
• API access. Only the api_cidrs ranges can reach the cluster’s Kubernetes API. Ranges wider than /16 are refused because they would open the API to a large public block.
• Daily budget. The install creates (or checks) an AWS Budget named genesis-tier-a-daily. It covers all spend in the account, not only Genesis, so size it for the infrastructure the install creates plus anything else the account runs. The infrastructure (the EKS control plane, the NAT gateway and the nodes) costs money every hour it exists. Alerts fire at half, three quarters and all of the amount, to budget_alert_email (Genesis’s operations address if you leave it out). A new install is refused once reported spend for the day reaches half. AWS billing data lags by hours, so treat this as a guardrail, not a hard stop. To change the amount later, delete that budget and run again; otherwise the install refuses because the existing budget differs from the sheet. The alert address is used only when the budget is created: a different address in a later sheet is not applied, so change it in AWS Budgets or delete the budget first.
• Node group. The preflight checks that your On-Demand Standard vCPU quota has room for count x the instance type’s vCPUs (2 for t3.large and m6i.large, 4 for m6i.xlarge), on top of what is already running.
• Sign-in. With sign_in, the application requires people to sign in through your Auth0 tenant. Without it, the application installs with sign-in off. Create the Auth0 application as a Single Page Application. Its allowed callback, logout and web-origin URLs must be exactly http://localhost:18080, the fixed address that open uses (guide, step 6). The sheet carries only identifiers, never a secret. Your whole Auth0 tenant is the boundary. Genesis accepts anyone your tenant authenticates for this application. It also accepts an access token that your tenant’s userinfo endpoint accepts. A person’s Genesis account is created the first time they sign in, and new users are administrators by default. So, before you enable sign-in:
  • turn off public sign-ups in your Auth0 tenant;
  • enable only the connections you intend (for example, your company’s Google Workspace or SSO) on this application;
  • have the person who should administer Genesis sign in first, then use Users & roles to move everyone else to a non-administrator role.
• Infrastructure reporting. With "infrastructure_reporting": true, the management agent reads the cluster version, node-group health, instance health and add-on versions through its read-only role, and reports them to Genesis. It is off by default: without it, the agent reports nothing about the AWS infrastructure. The role exists either way (see the permission appendix).
• Maintenance window, upgrade policy and consent. With "automatic_operation_consent": true, the install starts the upgrade controls unpaused, with your window and policy. Consent removes only the initial pause; your policy still applies. Under approval-required, every upgrade still waits for your approval, and under approve-then-next-window an approved upgrade still waits for the window. Without consent, the controls start paused and nothing upgrades until they are enabled. Either way the install sets the controls only once: a retry or a reinstall never overwrites controls that already exist, including a pause you set later.

​

Upgrade policies