Allow access to Worker Node Role in EKS Auto mode clusters

[hlascelles]

Describe the feature

The new Cluster class creates an EKS cluster in auto mode, and it creates the worker node for the general-purpose pool too: https://github.com/aws/aws-cdk/blob/0a55ed1a01009d28739e8f081b1ce0ad78eac73d/packages/%40aws-cdk/aws-eks-v2-alpha/lib/cluster.ts#L1193

However, that role is not easy to get hold of to modify.

We would like to add a permission to that node role. At the moment we do a Child dig like this:

      const all = Node.of(context).findAll();
      // @ts-ignore
      const roles = all.filter(c => c.assumeRoleAction) as Role[];
      const workerRoles = roles.filter((c) => {
        // @ts-ignore
        return c["managedPolicies"]?.find(mp => mp["managedPolicyArn"].indexOf(":iam::aws:policy/AmazonEKSWorkerNodePolicy") > -1)
      }) as Role[];
      // Probably the first one

Use Case

We have pods running with ServiceAccounts to and bound to roles, all that is fine. But sometimes there is some "default" access coming out of a pod (eg DIND). We want to modify the permissions for that access.

Proposed Solution

Expose the WorkerNode Role after a cluster has been created. eg:

const cluster = new Cluster(....)
const role = cluster.workerNodeRole;

Other Information

No response

Acknowledgements

• [x] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

AWS CDK Library version (aws-cdk-lib)

2.190.0

AWS CDK CLI version

2.1007.0

Environment details (OS name and version, etc.)

Linux

[pahud]

Hi @hlascelles,

Thanks for this feature request! I took a closer look at the current implementation and wanted to clarify the available options.

You can already provide your own node role!

The ComputeConfig interface already supports providing a custom node role:

const customNodeRole = new iam.Role(this, 'CustomNodeRole', {
  assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
  managedPolicies: [
    iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonEKSWorkerNodeMinimalPolicy'),
    iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonEC2ContainerRegistryPullOnly'),
    // Add your custom policies here
  ],
});

const cluster = new Cluster(this, 'MyCluster', {
  version: KubernetesVersion.V1_31,
  compute: {
    nodeRole: customNodeRole, // <-- Use your custom role
    nodePools: ['system', 'general-purpose'],
  },
});

// Now you can modify the role as needed
customNodeRole.addManagedPolicy(/* your custom policy */);

Is there any reason that stops you from providing your own role?

[hlascelles]

The main reason is to avoid "losing out" on the good works that CDK provide, setting up the right role with all the latest improvements 👍 . What if a new ManagedPolicy or similar is added to that role in CDK? I wouldn't know when I upgrade... Does that makes sense?

I think one of two solutions would work:

1. Expose the role "afterwards" with cluster.workerNodeRole.
2. Expose the work node role factory method. I could then call that, change it, and then pass the arn into the new Cluster as you describe.

What do you think?

[hlascelles]

Actually, case in point, the default role has:

AmazonEKSWorkerNodePolicy
AmazonEC2ContainerRegistryReadOnly

But your example gives:

AmazonEKSWorkerNodeMinimalPolicy
AmazonEC2ContainerRegistryPullOnly

Maybe that has changed recently, but if so, we would have missed out... Be good to have the actual role, to be sure not to miss changes 👍!