aws_eks: EKS Cluster Creation Fails Due to Invalid Cluster ARN in IAM Policy

[Malok12]

Describe the bug

EKS cluster creation through AWS Service Catalog fails with an AccessDenied error due to malformed resource ARNs in the automatically generated IAM policy. The CDK generates an IAM policy for the EksEksClusterCreationRole that contains [object Object] instead of the actual cluster name or "*" in the resource ARN, causing AWS to reject EKS API calls even though the role has the correct permissions.

This is a synthesis-time vs runtime parameter resolution issue where CDK attempts to build specific resource ARNs during template synthesis using runtime parameters that are available during Service Catalog product deployment.

Lambda Functions with Faulty Role Generation
The error originates from these automatically generated Lambda functions:

• OnEventHandler42BEBAE0 - Uses role: OnEventHandlerServiceRole15A26729
• IsCompleteHandler7073F4DA - Uses role: IsCompleteHandlerServiceRole5810CC58
• ProviderframeworkonEvent83C1D0A7 - Framework wrapper function

The OnEventHandler function is specifically responsible for calling eks:CreateCluster and uses the problematic EksClusterCreationRole.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Library Version

No response

Expected Behavior

The EKS cluster should be created successfully through Service Catalog. Since Service Catalog creates a new Lambda function and role instance for each deployment, the CDK should properly resolve the CloudFormation parameter in the IAM policy resource ARN at deployment time.

The correctly generated policy should look like this:

  {
    "Action": [
      "eks:CreateCluster",
      "eks:CreateFargateProfile",
      "eks:DeleteCluster",
      "eks:DescribeCluster",
      "eks:DescribeUpdate",
      "eks:TagResource",
      "eks:UntagResource",
      "eks:UpdateClusterConfig",
      "eks:UpdateClusterVersion"
    ],
    "Effect": "Allow",
    "Resource": [
      {
        "Fn::Sub": "arn:${AWS::Partition}:eks:${AWS::Region}:${AWS::AccountId}:cluster/${cloudformation.parameter.cluster_name}"
      }
    ]
  }

This would create a specific policy for each deployment with the correct cluster name resolved at CloudFormation execution time, allowing the OnEventHandler Lambda function to successfully call eks:CreateCluster on the specific cluster being deployed. Since each
Service Catalog deployment creates its own Lambda function and role instance, this approach would provide proper least-privilege access while maintaining security.

Current Behavior

Cluster creation fails when the CDK attempts to generate specific resource ARNs using CloudFormation parameters that are only available at runtime. During synthesis, CDK cannot resolve the runtime parameter and defaults to JavaScript's string representation of an object, resulting in [object Object] in the policy resource ARN.

Error message:
Received response status [FAILED] from custom resource. Message returned: User: arn:aws:sts::443370674873:assumed-role/SC-443370674873-pp-d2iqrp-EksEksClusterCreationRole-ZMV8TCRtNZp7/AWSCDK.EKSCluster.Create.ce179586-8e76-49d6-955d-3618be0c416b is not authorized to perform: eks:CreateCluster on resource: arn:aws:eks:eu-west-1:443370674873:cluster/{clustername}

The issue occurs because CDK generates an IAM policy that attempts to use a CloudFormation parameter (cluster name) in the resource ARN during synthesis time, but the parameter is not available until Service Catalog deployment. This results in the following malformed policy:

  {
    "Action": [
      "eks:CreateCluster",
      "eks:CreateFargateProfile",
      "eks:DeleteCluster",
      "eks:DescribeCluster",
      "eks:DescribeUpdate",
      "eks:TagResource",
      "eks:UntagResource",
      "eks:UpdateClusterConfig",
      "eks:UpdateClusterVersion"
    ],
    "Effect": "Allow",
    "Resource": [
      {
        "Fn::Join": [
          "",
          [
            "arn:",
            {"Ref": "AWS::Partition"},
            ":eks:",
            {"Ref": "AWS::Region"},
            ":",
            {"Ref": "AWS::AccountId"},
            ":cluster/[object Object]"
          ]
        ]
      }
    ]
  }

The policy contains ":cluster/[object Object]" instead of a "*" or from the cloudformation parameter the cluster_name, causing AWS IAM to deny the eks:CreateCluster action since the resource ARN doesn't match.

Reproduction Steps

1. Create a CDK stack that defines an EKS cluster with a CloudFormation parameter for cluster name:
2. Run CDK synthesis to generate the CloudFormation template: cdk synth
3. Examine the generated CloudFormation template and locate the EksClusterCreationRole IAM policy
4. Observe that the policy contains [object Object] in the resource ARN instead of the CloudFormation parameter reference or wildcard

Possible Solution

The CDK should handle CloudFormation parameters properly when generating IAM policies for the EKS Custom Resource Provider. There are two viable approaches:

Option 1: Use wildcard resources (Recommended)
Modify the EKS construct to generate IAM policies with wildcard (*) resources instead of attempting to resolve runtime parameters:

  {
    "Action": [
      "eks:CreateCluster",
      "eks:DeleteCluster",
      "eks:DescribeCluster"
    ],
    "Effect": "Allow",
    "Resource": "*"
  }

Option 2: Proper parameter resolution
Ensure the CDK correctly passes CloudFormation parameters to the Custom Resource Provider's IAM policy using Fn::Sub:

  {
    "Action": [
      "eks:CreateCluster",
      "eks:DeleteCluster",
      "eks:DescribeCluster"
    ],
    "Effect": "Allow",
    "Resource": {
      "Fn::Sub": "arn:${AWS::Partition}:eks:${AWS::Region}:${AWS::AccountId}:cluster/${{cloudformation.parameter.cluster_name}"
    }
  }

Additional Information/Context

No response

AWS CDK Library version (aws-cdk-lib)

2.210.0

AWS CDK CLI version

2.1024.0

Node.js Version

11.5.2

OS

Windows

Language

Python

Language Version

3.11.0

Other information

No response

[related-issues-bot-for-aws]

Hi @Malok12,

Thanks for reporting! This appears to be a duplicate issue. If you feel this is a distinct issue, please let us know in the comments. Otherwise, we'll close this ticket in 7 days and encourage you to follow the conversation threads in the potential duplicates listed below ranked by engagement.

Potential Duplicate Issues

• (eks, core): eks.Cluster has malformed IAM policy resource ARNs if clusterName is part-string, part token #18540: This issue describes the identical problem where EKS cluster creation fails due to malformed IAM policy resource ARNs containing [object Object] instead of the actual cluster name when using dynamic values. Both issues show the same error pattern where the IAM policy contains incorrectly formed ARNs like ":cluster/[object Object]", leading to authorization failures with the eks:CreateCluster API. The issues would be resolved by the same fix in how resource ARNs are constructed when using tokens or parameters for cluster names.

This message was generated automatically to help connect related conversations and improve discoverability.

Please react with 👍 or 👎 to let us know if this response was helpful!

Thank you for helping improve CDK! 🙌

Related Issues

• (aws-eks): ClusterName set from CfnParameter.ValueAsString leads to cluster creation failure #13532
• (aws-cdk): (Assets built in EKS/HELM/LAMBDA product in wrapped stack) #27311

[pahud]

Thanks @Malok12 . This is a duplicate of #18540 but I am trying to investigate the root cause and permanently get it fixed.

Root Cause Analysis

After examining the code, I can now identify the exact root cause of issue #18540:

The Problem

The issue occurs in the ClusterResource.createAdminRole() method in cluster-resource.ts at lines 139-146:

const resourceArns = Lazy.list({
  produce: () => {
    const arn = stack.formatArn(clusterArnComponents(stack.resolve(props.name)));
    return stack.resolve(props.name)
      ? [arn, `${arn}/*`] // see https://github.com/aws/aws-cdk/issues/6060
      : ['*'];
  },
});

Why [object Object] Appears

1. Token Resolution Issue: When props.name contains a mixed token like cdk.Fn.sub('eks-${param}', { param: param.stringValue }), calling stack.resolve(props.name) during synthesis time
   attempts to resolve the token.

2. Synthesis vs Runtime: The Fn.sub token contains references to CloudFormation parameters that are only available at runtime, not during CDK synthesis.

3. JavaScript Object Stringification: When stack.resolve() encounters a token it cannot fully resolve, it returns the token object itself. When this object is later used in string
   concatenation (in formatArn), JavaScript converts it to [object Object].

4. The Flow:
   • stack.resolve(props.name) returns a token object (not a string)
   • clusterArnComponents(stack.resolve(props.name)) passes this object as resourceName
   • stack.formatArn() eventually concatenates this object into a string
   • JavaScript's string coercion converts the object to [object Object]

The Core Issue

The problem is that the code is trying to resolve tokens at synthesis time that should only be resolved at deployment time. The Lazy.list wrapper doesn't help because the resolution happens inside the produce function, which is still called during synthesis.

Proposed Fix

The fix is to avoid calling stack.resolve() on the cluster name when building the ARN. Instead, we should pass the unresolved token directly to formatArn, which can handle tokens properly.

Here's the fix for packages/aws-cdk-lib/aws-eks/lib/cluster-resource.ts:

// BEFORE (problematic code):
const resourceArns = Lazy.list({
  produce: () => {
    const arn = stack.formatArn(clusterArnComponents(stack.resolve(props.name)));
    return stack.resolve(props.name)
      ? [arn, `${arn}/*`] // see https://github.com/aws/aws-cdk/issues/6060
      : ['*']; 

// AFTER (fixed code):
const resourceArns = Lazy.list({
  produce: () => {
    // Don't resolve the name - let formatArn handle the token properly
    if (!props.name) {
      return ['*'];
    }
    const arn = stack.formatArn(clusterArnComponents(props.name));
    return [arn, `${arn}/*`]; // see https://github.com/aws/aws-cdk/issues/6060
  },
});

, fix the fargateProfileResourceArn:

// BEFORE:
const fargateProfileResourceArn = Lazy.string({
  produce: () => stack.resolve(props.name)
    ? stack.formatArn({ service: 'eks', resource: 'fargateprofile', resourceName: stack.resolve(props.name) + '/*' })
    : '*',
});

// AFTER:
const fargateProfileResourceArn = Lazy.string({
  produce: () => props.name
    ? stack.formatArn({ service: 'eks', resource: 'fargateprofile', resourceName: props.name + '
});

Why This Fix Works

1. Proper Token Handling: By not calling stack.resolve(), we let the CDK's token system handle the resolution at the appropriate time (deployment).

2. formatArn Handles Tokens: The stack.formatArn() method is designed to work with tokens and will properly generate CloudFormation intrinsic functions like Fn::Sub when needed.

3. Maintains Functionality: The logic still works - if props.name is falsy, we use wildcards. If it has a value (even a token), we build specific ARNs.

4. Backward Compatibility: This change doesn't break existing functionality for clusters with concrete names.

Additional Considerations

This fix addresses the core issue, but there are two approaches the CDK team could consider:

Option 1: Use Wildcards (Simpler, More Permissive)

// Always use wildcards for IAM policies to avoid token resolution issues
const resourceArns = ['*'];

Option 2: Proper Token Handling (Recommended)

The fix I proposed above, which maintains the intent of having specific resource ARNs while properly handling tokens.

The recommended approach is Option 2 because it:
• Maintains the principle of least privilege
• Properly handles both concrete names and tokens
• Doesn't require changes to user code
• Follows CDK's token resolution patterns

This fix would resolve both issue #18540 and its duplicate #35254, allowing EKS clusters to work properly with CloudFormation parameters and AWS Service Catalog deployments.

[pahud]

Minimal Reproduction Code

1. CDK Stack (Essential Parts)

import * as cdk from 'aws-cdk-lib';
import * as eks from 'aws-cdk-lib/aws-eks';
import * as ssm from 'aws-cdk-lib/aws-ssm';

export class ReproStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Create a hybrid cluster name with CloudFormation tokens
    const param = ssm.StringParameter.fromStringParameterName(
      this, 'Param', '/some/parameter'
    );

    const hybridClusterName = cdk.Fn.sub('eks-${param}', {
      param: param.stringValue
    });

    // This triggers the bug in IAM policy generation
    new eks.Cluster(this, 'cluster', {
      version: eks.KubernetesVersion.V1_29,
      clusterName: hybridClusterName,  // ← This causes [object Object] in IAM policies
    });
  }
}

2. App Entry Point

import * as cdk from 'aws-cdk-lib';
import { ReproStack } from './repro-stack';

const app = new cdk.App();
new ReproStack(app, 'ReproStack', {
  env: { account: '123456789012', region: 'us-east-1' }
});

3. Bug Detection

# Synthesize and check for the bug
npx cdk synth
grep "object Object" cdk.out/ReproStack.template.json

Expected Bug Output

The synthesized CloudFormation template will contain:

{
  "Action": ["eks:CreateCluster", "eks:DescribeCluster"],
  "Resource": [
    "arn:aws:eks:us-east-1:123456789012:cluster/[object Object]",
    "arn:aws:eks:us-east-1:123456789012:cluster/[object Object]/*"
  ]
}

Key Elements

• Hybrid Name: Combination of static string + CloudFormation token
• EKS Cluster: Any EKS cluster using the hybrid name
• Bug Location: IAM policies in the synthesized CloudFormation template
• Detection: Search for [object Object] in cluster ARNs

This minimal reproduction demonstrates how CloudFormation tokens become [object Object] when the CDK prematurely resolves them during synthesis.