feat: declaratively provision the EKS-test AWS identity (OIDC role vs static key)

[devantler]

🤖 Generated by the Daily AI Assistant

Child 2 of #2324. Declaratively provision the EKS-test AWS identity. Depends on child #1 (AWS provider + aws tenant).

Scope

In the devantler-tech/aws repo deploy/, declare (as Crossplane managed resources) a least-privilege identity for the ksail EKS CI system test — enough for eksctl to create and delete an EKS cluster (+ nodegroup, VPC/CFN as eksctl needs) and for the GitOps-on-EKS smoke (Flux/ArgoCD install themselves via Helm, so cluster-admin on the freshly created cluster suffices).

Decision point — surface to the maintainer in the PR

• (preferred) GitHub OIDC role: an IAM OIDC identity provider for token.actions.githubusercontent.com + an IAM Role with a trust policy scoped to the ksail repo + the EKS workflow, assumed via OIDC at runtime → no long-lived secret stored anywhere. Most secure; changes child Update Raspbian kernel on nomad02 #3 to "configure the OIDC trust" instead of syncing a secret.
• (fallback) static access key: an IAM user + access key surfaced as a Crossplane connection secret, to be delivered to CI by child Update Raspbian kernel on nomad02 #3. Simpler but a long-lived credential.

Acceptance criteria

• IAM policy is least-privilege and reviewed (no *:*); scoped/bounded to ephemeral EKS test clusters (name prefix / tag condition where feasible).
• Identity provisioned declaratively + reconciles clean; chosen delivery mechanism (OIDC role ARN or connection secret) is available to child Update Raspbian kernel on nomad02 #3.
• Cost guardrail noted: the test must create→delete within the run; document expected spend.

Blocked by #1. Blocks #3. Rough size: M.

[devantler]

🤖 Generated by the Daily AI Engineer

Step 1 shipped: devantler-tech/aws#2 (draft) — the GitHub Actions OIDC identity provider, schema-checked against the live openidconnectproviders.iam.aws.m.upbound.io/v1beta1 CRD (activated by #2565).

Why two steps: the role's trust policy must name the provider's exact ARN (principal ARNs can't be wildcarded), and that ARN — which embeds the account id — only becomes observable in status.atProvider.arn after step 1 reconciles. Reconciling step 1 also proves the OpenBao bootstrap credential end-to-end before any privileged resource exists.

Step 2 (next run, mechanical once the ARN is readable): a Role per #2564's design — trust scoped to repo:devantler-tech/ksail:environment:ci (aud sts.amazonaws.com), maxSessionDuration: 7200 (the smoke job runs up to 120 min incl. the billable-cluster cleanup), and the least-privilege permissions as an inline policy (Policy/RolePolicyAttachment MRDs deliberately inactive) scoped to the workflow's naming: CloudFormation on stack/eksctl-st-eks-*, EKS on cluster/st-eks-* + nodegroups, IAM create/delete/pass-role on role|instance-profile/eksctl-st-eks-* + CreateServiceLinkedRole (eks/eks-nodegroup/autoscaling), SSM GetParameter on the EKS AMI parameters, EC2 per eksctl's documented minimum. Then the role ARN goes to ksail's ci environment as AWS_OIDC_ROLE_ARN (child #3's clean-skip gate) and a manual System Test - EKS dispatch E2E-verifies the whole chain.