Summary

The AWS Cloud Development Kit (AWS CDK) [1] is an open-source software development framework for defining cloud infrastructure in code and provisioning it through AWS CloudFormation. The AWS CDK CLI [2] is a command line tool for interacting with CDK applications. Customers can use the CDK CLI to create, manage, and deploy their AWS CDK projects.

An issue exists in the AWS CDK CLI where, under certain conditions, AWS credentials may be returned in the console output. Plugins that return an expiration property in the credentials object are affected by this issue. Plugins that omit the expiration property are not affected.

Impact

When customers run AWS CDK CLI commands with credential plugins and configure those plugins to return temporary credentials by including an expiration property, the AWS credentials retrieved by the plugin may be returned in the console output. Any user with access where the CDK CLI was ran would have access to this output.

The following are examples of configuring a custom credential plugin:

Via command line option:

cdk deploy --plugin /path/to/plugin

Via configuration file [3]:

json { "plugin": "/path/to/plugin" }

Plugins that return an expiration property in the credentials object, such as the following example, are affected:

console return { accessKeyId: '<access-key>', secretAccessKey: '<secret-access-key>', sessionToken: '<session-token>', expiration: <date>, };

The expiration property indicates that the provided credentials are temporary.

Please refer to our "AWS CDK CLI Library" guide for more information about custom credential plugins [4].

Impacted versions: >=2.172.0 and <2.178.2

Patches

The issue has been addressed in version 2.178.2 [5]. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.

Workarounds

If you are unable to upgrade to version 2.178.2 or later, you can downgrade to version 2.171.1. If you are unable to downgrade, but have access to the code of the credential plugin you use, you can remove the expiration property from the object returned by the plugin.

For example, change the code from returning this:

javascript return { accessKeyId: assumeRoleOutput.Credentials.AccessKeyId, secretAccessKey: assumeRoleOutput.Credentials.SecretAccessKey, sessionToken: assumeRoleOutput.Credentials.SessionToken,

// Expiration indicates to the CLI that this is temporary expiration: assumeRoleOutput.Credentials.Expiration, };

To return this:

javascript return { accessKeyId: assumeRoleOutput.Credentials.AccessKeyId, secretAccessKey: assumeRoleOutput.Credentials.SecretAccessKey, sessionToken: assumeRoleOutput.Credentials.SessionToken, };

Note that this will prevent the CDK CLI from refreshing the credentials when needed, and may cause your workflow to fail on an expired credentials error.

References

[1] https://docs.aws.amazon.com/cdk/v2/guide/home.html

[2] https://docs.aws.amazon.com/cdk/v2/guide/cli.html

[3] https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-config

[4] https://www.npmjs.com/package/@aws-cdk/cli-plugin-contract

[5] https://github.com/aws/aws-cdk/releases/tag/v2.178.2

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.

Impact Users who use IAM OIDC custom resource provider package will download CA Thumbprints as part of the custom resource workflow, https://github.com/aws/aws-cdk/blob/d16482fc8a4a3e1f62751f481b770c09034df7d2/packages/%40aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts#L34.

However, the current tls.connect method will always set rejectUnauthorized: false which is a potential security concern. CDK should follow the best practice and set rejectUnauthorized: true. However, this could be a breaking change for existing CDK applications and we should fix this with a feature flag.

Note that this is marked as low severity Security advisory because the issuer url is provided by CDK users who define the CDK application. If they insist on connecting to a unauthorized OIDC provider, CDK should not disallow this. Additionally, the code block is run in a Lambda environment which mitigate the MITM attack.

As a best practice, CDK should still fix this issue under a feature flag to avoid regression.

packages/@aws-cdk/custom-resource-handlers/lib/aws-iam/oidc-handler/external.ts ❯❱ problem-based-packs.insecure-transport.js-node.bypass-tls-verification.bypass-tls-verification Checks for setting the environment variable NODETLSREJECTUNAUTHORIZED to 0, which disables TLS verification. This should only be used for debugging purposes. Setting the option rejectUnauthorized to false bypasses verification against the list of trusted CAs, which also leads to insecure transport.

Patches The patch is in progress. To mitigate, upgrade to CDK v2.177.0 (Expected release date 2025-02-22). Once upgraded, please make sure the feature flag '@aws-cdk/aws-iam:oidcRejectUnauthorizedConnections' is set to true in cdk.context.json or cdk.json. More details on feature flag setting is here.

Workarounds N/A

References https://github.com/aws/aws-cdk/issues/32920