aws-eks: albController and FargateCluster compatibility with AuthenticationMode.API mode

[Hazzard17h]

Describe the bug

Setting EKS Cluster authenticationMode: AuthenticationMode.API cause "Error: ConfigMap not supported in the AuthenticationMode" if using albController or fargate profiles (for FargateCluster).

Expected Behavior

Use the new AccessEntry mechanism when authenticationMode: AuthenticationMode.API, for all resources managed by Cluster that need EKS API access.

Current Behavior

Error: ConfigMap not supported in the AuthenticationMode

Reproduction Steps

new Cluster(this, 'cluster', {
  version: KubernetesVersion.V1_27,
  authenticationMode: AuthenticationMode.API,
  albController: { version: AlbControllerVersion.V2_6_2 }
});

or

new FargateCluster(this, 'cluster', {
  version: KubernetesVersion.V1_27,
  authenticationMode: AuthenticationMode.API
});

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.148.0 (build e5740c0)

Framework Version

2.148.0

Node.js Version

v20.15.1

OS

Ubuntu 20.04

Language

TypeScript

Language Version

TypeScript 5.5.3

Other information

No response

[pahud]

Yes, that is how AuthenticationMode is designed.

When you switch to AuthenticationMode.API, your cluster would support auth API only, ConfigMap would not be supported.

I am not sure if albController does require ConfigMap, if it does, you probably should use AuthenticationMode.API_AND_CONFIG_MAP

[Hazzard17h]

@pahud I know that this is the intended behavior for AuthenticationMode.API, but as this is implemented in CDK I expect that other managed resources are configured to be able to use this new mode.

Currently it's not possibile to use Fargate in a Cluster with AuthenticationMode.API (and FargateCluster construct at all, as per the example code), probably there should be an if here checking the AuthenticationMode, and if it's API should use cluster.grantAccess instead of cluster.awsAuth.addRoleMapping:

aws-cdk/packages/aws-cdk-lib/aws-eks/lib/fargate-profile.ts

Lines 204 to 213 in e3c0764

	// map the fargate pod execution role to the relevant groups in rbac
	// see https://github.com/aws/aws-cdk/issues/7981
	props.cluster.awsAuth.addRoleMapping(this.podExecutionRole, {
	username: 'system:node:{{SessionName}}',
	groups: [
	'system:bootstrappers',
	'system:nodes',
	'system:node-proxier',
	],
	});

Or maybe could be removed at all, as per EKS documentation:

It's unnecessary to create an access entry for an IAM role that's used for a managed node group or a Fargate profile, because Amazon EKS adds entries for these roles to the aws-auth ConfigMap, regardless of which platform version your cluster is at.

And I can also see that just switching to AuthenticationMode.API_AND_CONFIG_MAP, EKS created an AccessEntry for the Fargate podExecutionRole automatically.
But I'm not expert of EKS, so maybe we should ask to the team.

About ALB Controller, I don't know why here there is a dependency to awsAuth:

aws-cdk/packages/aws-cdk-lib/aws-eks/lib/alb-controller.ts

Lines 329 to 332 in e3c0764

	// the controller relies on permissions deployed using these resources.
	chart.node.addDependency(serviceAccount);
	chart.node.addDependency(props.cluster.openIdConnectProvider);
	chart.node.addDependency(props.cluster.awsAuth);

As far as I know ALB Controller needs permissions to access AWS API with a ServiceAccount, not to grant access to K8S API to an IAM entity.
Also here should be checked with EKS and ALB Controller teams.

[pahud]

Yes we will need to improve the compatibility with AuthenticationMode.API as some legacy code probably still assume ConfigMap only.

probably there should be an if here checking the AuthenticationMode, and if it's API should use cluster.grantAccess instead of cluster.awsAuth.addRoleMapping

Yes I agree. This might be required.

About ALB Controller, I don't know why here there is a dependency to awsAuth

We probably need a similar check here as well.

We welcome PRs to help us improve the compatibility with AuthenticationMode.API mode. Please help us prioritize with 👍 .