Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

(eks): cluster only trusts cloudformation execution role with modern synthesis

See original GitHub issue

General Issue

Can’t use CLI credentials when deploying stacks in CDK v2, causing issues with default EKS RBAC

The Question

There doesn’t seem to be a way to fall back to the old behaviour of using the CLI credentials to deploy CF stacks rather than the execution role that CDK Boostrap creates.

This is an issue for EKS, where new clusters are created by default with the creator’s role being the only one with master permissions. If you’re using CfnCluster rather than the custom resource based provider, this means that you can’t then fix the RBAC after the stack has finished creating, as the only entity that the cluster “trusts” is the cloudformation-only deploy role.

I would prefer not to use the CDK custom resource based provider.

CDK CLI Version

2.0.0-rc.23 (build 1e54fb9)

Framework Version

No response

Node.js Version

No response


No response



Language Version

No response

Other information

No response

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:12 (4 by maintainers)

github_iconTop GitHub Comments

mipearsoncommented, Nov 28, 2021

@samjarrett is correct.

There’s three issues here:

(a) The first is that the documentation of BootstraplessStackSynthesizer is incorrect: it states that it’ll use the CLI credentials, but does not, as there’s a ||= in the code of the class BootstraplessStackSynthesizer is extending that reverts to using the created role as a default. (edit: and most importantly there’s no way to force it to use the CLI credentials without cooking up your own synthesizer, as in my example)

(b) Creating an EKS cluster via CfnCluster using this created role means the cluster can’t be accessed, as there’s no way to set up the master role mapping. There may be other similar issues with other resources & people’s expectations that the CLI role/user is the one used.

© This decision overall has some security implications that may be surprising, as @samjarrett pointed out. They were surprising to me! On the other hand, it’s a nice workaround to “oops my assumed role timed out in the middle of my big stack apply”.

stevehodgkisscommented, Nov 10, 2021

I ran into this issue upgrading to CDK 2 today. I realised due a PutKeyPolicy failure, which was due to the cfn-exec role not being on the key’s admin list (whereas the role provided via aws env vars credentials is).

There are other scenarios where we’d like to be using the role provided via env credentials, and not a cfn-exec role with extremely wide permissions. For example, we typically run CFN deploys with roles that don’t allow data destruction (to prevent accidental RDS “replacements” etc). To perform those actions a separate role needs to be assumed in order to make the action intentional (i.e aws-vault exec my-account-data-destroyer -- yarn cdk deploy ...). It’s not possible to use roles like this anymore if cdk deploy can’t be configured to use credentials from the environment.

It would be great if the use of an assumed cloudFormationExecutionRole could be disabled somehow (i.e. via cdk.json), so that deploys behave similar to CDK 1 and use the provided credentials in ENV when available.

This is a workaround for DefaultStackSynthesizer that avoids having to replace the synthesize function (using 2.0.0-rc.27):

class DefaultStackSynthesizerWithoutDefaultCloudFormationExecutionRole extends DefaultStackSynthesizer {
  protected emitStackArtifact(stack: Stack, session: ISynthesisSession, options: SynthesizeStackArtifactOptions = {}) {
    super.emitStackArtifact(stack, session, {
      cloudFormationExecutionRoleArn: undefined,

// Then make sure it's used in every cdk.Stack:
export class MyBaseCdkStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: cdk.StackProps) {
    super(scope, id, {
      synthesizer: new DefaultStackSynthesizerWithoutDefaultCloudFormationExecutionRole(),

Using the LegacyStackSynthesizer is also an option. I added "@aws-cdk/core:newStyleStackSynthesis": false to cdk.json, and it requires the new CDKToolkit stack from CDK v2 bootstrap, and works as expected using the provided role credentials in ENV.

Read more comments on GitHub >

github_iconTop Results From Across the Web

AWS::EKS::Cluster - AWS CloudFormation
Creates an Amazon EKS control plane. The Amazon EKS control plane consists of control plane instances that run the Kubernetes software, such as...
Read more >
New CDK Bootstrap and the EKS Cluster - Tech Blog
With the new CDK Bootstrap, where the CloudFormation is executed using the role cfn-exec-role , the Administrator role is not your user anymore ......
Read more >
@aws-cdk/pipelines - npm
A set of roles with permissions to access these asset locations and to execute CloudFormation, assumable from whatever accounts you specify under --trust...
Read more >
Pipelines - Amazon EKS Blueprints Quick Start
While it is convenient to leverage the CDK command line tool to deploy your first cluster, we recommend setting up automated pipelines that...
Read more >
Creating and Securing an EKS Cluster: First Steps - Aqua Blog
I deleted the EKS cluster, and used the CloudFormation Delete Stack option to remove the VPC and worker node resources. Container Security ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found