Connect add-ons to AWS without keys

On eks-prod, each add-on reaches AWS through its own cloud identity, never a stored key. Alice, the platform engineer, sets it on each add-on once the cluster exists; anyone who deploys a model never sees it.

Before you start

The cluster eks-prod (your cluster's name), created and connected to AWS in the Connect step of Create the EKS cluster.
For a private bucket: a read-only role for it.

Where each identity is set

On EKS, add-ons use IAM roles for service accounts (IRSA), so the cluster needs its OIDC provider; a cluster AstroPulse creates has it. Node Autoscaling uses EKS Pod Identity instead.

Model Serving reads private model weights. Cloud access: Workload identity, then under Identity set Cloud to Amazon Web Services and enter the AWS role ARN; see step 3 of Deploy your first model. The role must trust system:serviceaccount:*:astro-model-* and system:serviceaccount:kserve-localmodel-jobs:default.
DNS Automation writes the DNS records. On a cluster AstroPulse created, leave Cloud access at None; if the apply is refused, run a cluster update so the role is created. On a registered cluster, set Cloud access to Workload identity with an AWS role ARN; see step 4 of Put the model on your domain.
Node Autoscaling launches the nodes. Leave IAM role ARN and Instance profile empty and the roles are created on install; on a registered cluster, create them first and enter the ARN. See Add GPU nodes only when needed.
Certificates prove domain ownership with a DNS check. Only a DNS-01 solver on AWS needs a role; it trusts system:serviceaccount:cert-manager:cert-manager.
Cost Visibility reads your cost and usage report for invoiced cost. Give it an IRSA role ARN and the report's bucket, database, table, account and region. A price sheet needs no cloud access.
Vulnerability Scanning pulls private images to scan them. The role trusts system:serviceaccount:astro-security:trivy-operator; a cluster AstroPulse creates gets an ECR pull-only role.