← back
CVE-2023-35165

AWS CDK EKS overly permissive trust policies

CVSS 6.6 MEDIUMEPSS 0.9%CWE-863
In short

AWS CDK's EKS cluster setup creates roles with overly permissive permissions that allow any principal in the AWS account to assume them. This means users or services you didn't intend could gain access to manage your Kubernetes cluster.

Technical detail

CVE-2023-35165 affects AWS CDK EKS constructs (versions aws-cdk-lib 2.0.0-2.80.0 and @aws-cdk/aws-eks 1.57.0-1.202.0) which generate CreationRole and default MastersRole with trust policies allowing account root principal instead of specific service roles. An authenticated AWS IAM principal with AssumeRole permissions can escalate privileges to assume these roles and execute kubectl commands or deploy Kubernetes manifests on the cluster. Fix: upgrade to aws-cdk-lib ≥2.80.0 or @aws-cdk/aws-eks ≥1.202.0, or explicitly specify mastersRole property.

Summary generated and translated by AI from the official description.
AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define cloud infrastructure in code and provision it through AWS CloudFormation. In the packages `aws-cdk-lib` 2.0.0 until 2.80.0 and `@aws-cdk/aws-eks` 1.57.0 until 1.202.0, `eks.Cluster` and `eks.FargateCluster` constructs create two roles, `CreationRole` and `default MastersRole`, that have an overly permissive trust policy. The first, referred to as the `CreationRole`, is used by lambda handlers to create the cluster and deploy Kubernetes resources (e.g `KubernetesManifest`, `HelmChart`, ...) onto it. Users with CDK version higher or equal to 1.62.0 (including v2 users) may be affected. The second, referred to as the `default MastersRole`, is provisioned only if the `mastersRole` property isn't provided and has permissions to execute `kubectl` commands on the cluster. Users with CDK version higher or equal to 1.57.0 (including v2 users) may be affected. The issue has been fixed in `@aws-cdk/aws-eks` v1.202.0 and `aws-cdk-lib` v2.80.0. These versions no longer use the account root principal. Instead, they restrict the trust policy to the specific roles of lambda handlers that need it. There is no workaround available for CreationRole. To avoid creating the `default MastersRole`, use the `mastersRole` property to explicitly provide a role.
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
Affected products
aws · aws-cdk

Want to know if your infrastructure is exposed to this?

Talk to TrueHacking →