aws-samples / aws-samples/cdk-eks-karpenter
Bug: addControllerPolicyIAMPolicyStatements is out of date
- Dominant language
- TypeScript
- Stars
- 48
- Forks
- 21
- PR merge metrics
- No merged PRs in 30d
Description
I was getting a werid IAM issue from karpenter controller in an edge case scenario
and I think it's because the IAM permissions are out of date.
I get an error like this
`api error AccessDenied: User: arn:aws:sts::905418347382:assumed-role/dev1-eks-dev1ekskarpenterRoleBAB00E15-YYY0TRmRblRA/1745543251692454822 is not authorized to perform: iam:GetInstanceProfile on resource: instance profile dev1-eks_15343853126976930035 because no identity-based policy allows the iam:GetInstanceProfile action"}`
https://github.com/aws-samples/cdk-eks-karpenter/blob/v1.0.16/src/index.ts#L458
Mentions the current IaC is based on v0.32.0
https://raw.githubusercontent.com/aws/karpenter/v0.32.0/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml
This is the current version
https://raw.githubusercontent.com/aws/karpenter/v1.4.0/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml
copy paste both of those into
https://www.diffchecker.com/text-compare/
And they've very different 15 removals & 52 additions.
This needs to be updated and I have an idea of how to future proof at the cost of introducing a dependency.
You can do something similar to this
```typescript
import request from 'sync-request-curl'; //npm install sync-request-curl (cdk requires sync functions, async not allowed)
//... (it makes it easy to fetch version specific iam policy) ...
const ALBC_Version = 'v2.12.0'; //April 9th, 2025 latest from https://github.com/kubernetes-sigs/aws-load-balancer-controller/releases
const ALBC_IAM_Policy_Url = `https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/refs/tags/${ALBC_Version}/docs/install/iam_policy.json`
const ALBC_IAM_Policy_JSON = JSON.parse(request("GET", ALBC_IAM_Policy_Url).body.toString());
const ALBC_IAM_Policy = new iam.Policy(stack, `${config.id}_AWS_LB_Controller_policy_for_EKS`, {
document: iam.PolicyDocument.fromJson( ALBC_IAM_Policy_JSON ),
});
const ALBC_Kube_SA = new eks.ServiceAccount(stack, 'aws-load-balancer-controller_kube-sa', {
cluster: cluster,
name: 'aws-load-balancer-controller',
namespace: 'kube-system',
identityType: eks.IdentityType.POD_IDENTITY, //depends on eks-pod-identity-agent addon
//Note: It's not documented, but this generates 4 things:
//1. A kube SA in the namespace of the cluster
//2. An IAM role paired to the Kube SA
//3. An EKS Pod Identity Association
//4. The eks-pod-identity-agent addon (dependency)
});
ALBC_Kube_SA.role.attachInlinePolicy(ALBC_IAM_Policy);
```
Contributor guide
Research direction
Start at src/index.ts#L458 and compare the Karpenter v0.32.0 and v1.4.0 CloudFormation policy files linked in the issue. Review the proposed sync-request-curl approach and determine the intended update scope. Done means the controller policy includes the permissions needed for the reported iam:GetInstanceProfile case without leaving the policy definition out of date.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, kubernetes, typescript
- Domain
- cloud, infrastructure, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100