aws_eks: Support AccessConfig on aws_eks.Cluster

[TirTech]

Describe the feature

Support setting AccessConfig (or at least AuthenticationMode) on aws_eks.Cluster.

Use Case

We currently use aws_eks.Cluster to create our clusters, and would like to start using EKS access modes (specifically API_AND_CONFIG_MAP)

Proposed Solution

No response

Other Information

No response

Acknowledgements

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

CDK version used

2.118.0

Environment details (OS name and version, etc.)

Ubuntu 22.04.3 LTS on Windows 11 x86_64, python 3.10

[pahud]

Yes this is an awesome feature we just announced and we definitely should support that. Would you tell me more about your expected CDK experience with that?

[TirTech]

Yes this is an awesome feature we just announced and we definitely should support that. Would you tell me more about your expected CDK experience with that?

Sure. When creating an EKS cluster, we would like to opt in to access entries by passing the authentication mode to the constructor:

cluster = aws_eks.Cluster(
            self,
            id="MyCluster",
            # ...snipped
            authentication_mode=aws_eks.AuthenticationMode.API_AND_CONFIG_MAP
        )

with aws_eks.AuthenticationMode being one of the available cluster authentication modes (default CONFIG_MAP).

For now we would go on to create CfnAccessEntry resource for each of the IAM roles we want to grant cluster access to, but in the future we would be looking to get the higher level AccessEntry resource added so we could create these entries for some aws_iam.Role "role" either on their own:

aws_eks.AccessEntry(
            self,
            id="AdministatorAccessEntry",
            cluster_name=cluster.cluster_name,
            principal_arn=role.role_arn,
            # other options
        )

or with a helper method on the cluster:

cluster.add_access_entry(self, id="AdministatorAccessEntry", principal_arn=role.role_arn, ...)

[codeJack]

Thanks @TirTech for raising this one.

@pahud to complement what has been shared above around the expected CDK experience with AccessConfig.

• Ideally, the aws_eks.Cluster construct should also expose the bootstrapClusterCreatorAdminPermissions flag along with AuthenticationMode.
  Today the role which creates the cluster is intrinsically a Kubernetes Cluster Administrator (doesn't even show up in the aws-auth config map). With access entries you might want to have full control and explicitly grant access to IAM entities. The CDK IAM model would need to evolve accordingly as today, by default, the kubectl provider leverages the cluster creation role as kubectl role. I would expect a dedicated IAM identity to be crafted for this specific purpose so that it can be audited and quarantined in case of need.
• About how to provide access to IAM roles into the cluster, I would expect the aws_eks.Cluster construct to somehow expose grant semantics to be consistent with other CDK libraries.
  Something along these lines, where IGrantable is implemented by IAM roles, users, groups etc:

# Grant cluster admin (system:masters RBAC group)
cluster.grant_admin(IGrantable)
# Grant read only (similarly to what a console user needs to navigate the cluster resources)
cluster.grant_read_only(IGrantable)
# General purpose grant where explicit mapping to RBAC access management can be expressed.
# Eventually this one could also take care of the heavy lifting by creating the Kubernetes' Role/ClusterRole/Binding/Group behind the scenes.
cluster.grant(IGrantable, <rbac mapping>)

[pahud]

This makes sense to me. Thank you for the user experience sharing. I am bumping this issue to p1 now but we still welcome any pull requests from the community.

[akefirad]

Is this possible/safe to use the escape hatch to enable API_AND_CONFIG mode until this feature is released? Asking because if it’s enabled manually, it cannot be set in the CDK stack anymore since the deployment is going to fail (which seems unnecessary, it could have simply succeeded, but that’s not the point here). Thanks.