iamauth: GetRole called with instance profile names from AWSMachinePool / AWSMachineTemplate, breaking aws-iam-authenticator reconcile on EKS clusters #6075

/kind bug

What steps did you take and what happened:

When the aws-iam-authenticator reconciler in pkg/cloud/services/iamauth discovers worker roles from an AWSManagedControlPlane's referenced MachineDeployments and MachinePools, it conflates two distinct concepts:

• AWSMachineTemplate.Spec.Template.Spec.IAMInstanceProfile — an instance profile name
• AWSMachinePool.Spec.AWSLaunchTemplate.IamInstanceProfile — an instance profile name
• AWSManagedMachinePool.Spec.RoleName — an IAM role name

All three are collected into the same map[string]struct{} in getRolesForWorkers (reconcile.go#L107-L116) and then passed to getARNForRole, which unconditionally calls iam:GetRole (reconcile.go#L93-L105). For the first two cases this is wrong — GetRole is being called with an instance profile name, not a role name.

Result on any EKS cluster (AWSManagedControlPlane) whose worker nodes come from AWSMachinePool or MachineDeployment + AWSMachineTemplate:

• GetRole returns NoSuchEntity (when an IAM role with the same name as the instance profile happens not to exist) — reconcile fails on every loop, the aws-auth ConfigMap never gets the node role mapping, and the AMCP condition IAMAuthenticatorConfigured stays False indefinitely.
• Or, GetRole returns a role ARN for an unrelated IAM role that happens to share the name (instance profile and a separate role coincidentally have the same name) — aws-auth is silently populated with the wrong ARN, and node bootstrap fails downstream.

We hit the NoSuchEntity flavor across our fleet. Reproducing:

1. Create an AWSManagedControlPlane-backed cluster.
2. Add a worker AWSMachinePool whose AWSLaunchTemplate.IamInstanceProfile is an instance profile name that does not match any IAM role of the same name (normal for instance profiles created with a -instance-profile suffix or any non-trivial naming convention).
3. Watch capa-controller-manager logs:

   getting roles for remote workers: failed to get ARN for role <instance-profile-name>: ... NoSuchEntity: The role with name <instance-profile-name> cannot be found.
   

4. kubectl get awsmanagedcontrolplane <name> -o jsonpath='{.status.conditions[?(@.type=="IAMAuthenticatorConfigured")]}' shows status: False permanently.

What did you expect to happen:

The reconciler should resolve instance profile names via iam:GetInstanceProfile (reading the ARN of the attached role from the response) and resolve role names via iam:GetRole as it does today. The dispatch should be based on which CRD field the name came from, since the CRD schemas already encode the distinction unambiguously.

Anything else you would like to add:

• The bug is in pkg/cloud/services/iamauth/reconcile.go, in getRolesForWorkers and the helpers it calls (getRolesForMachineDeployments, getRolesForAWSMachinePool, getRolesForAWSManagedMachinePool). They write all three name sources into a single map[string]struct{}, losing the kind distinction by the time getARNForRole is called.
• Proposed shape of fix:
  • Track each discovered name's kind (asInstanceProfile vs asRole) at collection time via a map[string]nameKind.
  • Add a getARNForInstanceProfile(ctx, name) helper that calls iam:GetInstanceProfile and returns Roles[0].Arn (AWS limits an instance profile to one attached role; an instance profile with no attached role is treated as an error).
  • Add a resolveRoleARN(ctx, name, kind) dispatcher and call it from ReconcileIAMAuthenticator.
• Permissions: the IAM policy attached to the CAPA controller will need iam:GetInstanceProfile in addition to the existing iam:GetRole. Any shipped IAM policy templates (e.g. AWSIAMManagedPolicyControllers.json) need a corresponding update.

Environment:

Affected code path is version-independent — present on main HEAD and in every released version that has the current iamauth/reconcile.go shape (predates v2.5). Not OS- or Kubernetes-version-specific.