AWS CDK (Cloud Development Kit) is a powerful open source framework for defining cloud infrastructure using popular programming languages. It helps developers automate the setup and management of AWS resources via code. However, security issues can sneak in when default behaviors are too permissive—one such case arose with CVE-2023-35165, impacting users working with EKS clusters via the AWS CDK.

In this post, we'll break down exactly what happened, which components were involved, how you could be affected, and what you need to do to stay secure.

aws-cdk-lib from 2.. up to (but not including) 2.80.

- @aws-cdk/aws-eks from 1.57. up to (but not including) 1.202.

When you used the CDK to create an EKS cluster using eks.Cluster or eks.FargateCluster, the CDK would automatically create two IAM roles with overly broad trust policies:

CreationRole

- Trusted by ALL Lambda Principals in your account ("AWS": "*" for Lambda), not just the Lambda functions meant for cluster setup.

Default MastersRole

- Trusted by the account root principal (i.e., any user or service with root privileges, which is very broad).

Has full EKS cluster administrative privileges required to run kubectl commands.

This setup made it easier for users to get started, but also left gaps that could be abused by insiders or compromised resources.

Why Is This Dangerous?

- Over-Permissive Trust: An IAM trust policy controls 'who can assume this role'. Wildcard policies or those accepting many principals (like all Lambda functions) increase risk.
- Privilege Escalation: Malicious or compromised Lambda could assume the CreationRole and perform unintended operations.
- Cluster Takeover: If the default MastersRole exists and isn't tightly controlled, actors could gain admin-level access to your Kubernetes cluster.

Here's a simplified policy that CDK created for the CreationRole prior to the fix

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "lambda.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

What’s wrong here?
The Principal field allows *any* Lambda function in the account to assume this role, rather than just the specific handlers CDK deploys for EKS provisioning.

A safer trust policy (what is now implemented) restricts the trust to specific Lambda roles, not every Lambda in the account.

How Could This Be Exploited?

1. A malicious Lambda function deployed in your account (perhaps via compromised CI/CD, supply chain attack, or insecure 3rd party Lambda) could call sts:AssumeRole for the CreationRole or default MastersRole.

On success, it would receive temporary AWS credentials with broad permissions.

3. These could be abused to create, modify, or even delete EKS resources—potentially exposing secrets or disrupting workloads.

Small Proof of Concept:

If you had a vulnerable setup, any Lambda could do the following

import boto3

def handler(event, context):
    sts = boto3.client('sts')
    # Replace with actual CreationRole ARN
    assumed_role = sts.assume_role(
        RoleArn='arn:aws:iam::123456789012:role/EksClusterCreationRole-abc123',
        RoleSessionName='takeover'
    )
    # Use assumed_role['Credentials'] for powerful AWS API actions...

CDK v1 Users:

If using @aws-cdk/aws-eks versions >=1.57. but <1.202..

From: Trust policies allowed *any* Lambda or the account root to assume these critical roles.

- To: Trust is restricted to the specific Lambda functions CDK deploys for cluster management (CreationRole), and the default MastersRole is only created if you don't explicitly provide a mastersRole property.

Fixed in

- @aws-cdk/aws-eks v1.202.

aws-cdk-lib v2.80.

> See AWS's release note and pull request for details.

Is There a Workaround?

For CreationRole:  
No workaround if the vulnerable role was already created—you must upgrade and redeploy your stack.

For Default MastersRole:  
- Always set the mastersRole property to a specific, tightly controlled IAM role when creating your eks.Cluster or eks.FargateCluster.

Example fix

const mastersRole = new iam.Role(this, 'CustomMastersRole', {
  assumedBy: new iam.AccountPrincipal(accountId) // restrict as needed
});
const cluster = new eks.Cluster(this, 'MyCluster', {
  mastersRole, // pass your own
  /* ... other options ... */
});

Upgrade Immediately

- Update to @aws-cdk/aws-eks v1.202. or later, or aws-cdk-lib v2.80. or later.

- CVE-2023-35165 on NVD
- AWS CDK v2.80. Release Notes
- AWS Pull Request Fix
- AWS CDK EKS Cluster Documentation

Conclusion

CVE-2023-35165 teaches us an important DevSecOps lesson: default settings—even from official tools—aren't always secure. Automating infrastructure with CDK is powerful, but always keep up with upstream security bulletins, audit your IAM roles, and understand the permissions your code assets are granting and trusting.

If you're using AWS CDK for EKS in production, upgrade now and review your role policies for minimal, necessary access only.

Timeline

Published on: 06/23/2023 21:15:00 UTC
Last modified on: 07/06/2023 15:37:00 UTC