Support EKS Access entries

[cPu1]

Description

Summary

This implementation integrates the EKS Access Entries API with eksctl by using the new API to manage access for self-managed nodegroups and IAM identity mappings.

Proposal

Managing self-managed nodegroups

Creating nodegroups

eksctl will take one of two actions depending on whether the Access Entry API is enabled or not.

Access Entry API is enabled

For authorizing self-managed nodegroups, eksctl will create a unique access entry for each nodegroup with the principal ARN set to the node role ARN, and the type set to EC2_LINUX for Linux-based nodegroups and EC2_WINDOWS for Windows nodegroups. A new resource AWS::EKS::AccessEntry will be added to a self-managed nodegroup's CloudFormation stack to allow the nodes to join the cluster. Including the AccessEntry resource in a nodegroup's CloudFormation stack allows eksctl create nodegroup to provide atomicity by offloading atomicity guarantees to CloudFormation. The existing codepath that adds a self-managed nodegroup’s node role ARN to aws-auth will be removed. Thus, all new nodegroups, including on existing clusters, will use the new Access Entry API for node authorization.

Access Entry API is not enabled

eksctl will continue to use the existing codepath of adding entries to the aws-auth ConfigMap.

Deleting nodegroups

When a self-managed nodegroup is being deleted, the AccessEntry resource included in the nodegroup's CloudFormation stack will also be deleted. An entry for the nodegroup may exist in the aws-auth ConfigMap if it was created when the Access Entry API was not enabled, so eksctl will inspect the nodegroup's CloudFormation stack to determine if it was authorized using the Access Entries API, and use the existing implementation of deleting the entry from aws-auth if it wasn't. Thus, eksctl will have to keep the existing aws-auth-based codepath for deleting nodegroups.

Managing access entries for IAM entities

Adding a top-level accessConfig.accessEntries field

eksctl can add a new top-level accessConfig.accessEntries field that maps one-to-one to the Access Entries API.

accessConfig:
  authenticationMode: API_AND_CONFIG_MAP
  accessEntries:
  - principalARN: <>

accessEntries:
  - principalARN: arn:aws:iam::111122223333:user/my-user-name
    kubernetesGroups: # optional kubernetes groups
      - group1 # groups can used to give permissions via RBAC
      - group2
  - principalARN: arn:aws:iam::111122223333:role/role-name-1
    accessPolicies: # optional access polices
      - policyARN:arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
        accessScope:
          type: namespace
          namespaces:
          -default
          -my-namespace
          -dev-*
  - principalARN: arn:aws:iam::111122223333:role/admin-role
    accessPolicies: # optional access polices
      - policyARN: arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy
        accessScope:
          type: cluster

This is quite straightforward to implement as each access entry in accessEntries maps to the CreateAccessEntry and AssociateAccessPolicy APIs.
If the authentication mode for the cluster is CONFIG_MAP, eksctl will fail early and print a message suggesting the user to enable the Access Entry APIs.

Caveats

This feature maps one-to-one to the AWS API, and in that sense, eksctl does not provide any improved user experience over the AWS CLI and will act merely as a wrapper over the AWS API. Many existing users may not discover this new feature and are less likely to use it over the existing aws-auth-based iamIdentityMappings feature. eksctl can improve discovery of the feature by printing a message informing the user to switch to eksctl create accessentries when eksctl create iamidentitymapping is used, but this will still have less feature adoption than using the existing iamIdentityMappings field for managing access entries.

Enabling Access Entry API

eksctl will introduce a new field accessConfig.authenticationMode that can be set to one of CONFIG_MAP, API_AND_CONFIG_MAP and API.

accessConfig:
  authenticationMode: <>

During cluster creation

If accessConfig.authenticationMode is set during cluster creation, eksctl will pass it to the CreateCluster API call.

Existing cluster

eksctl will introduce a new command eksctl utils update-authentication-mode --authentication-mode=CONFIG_MAP|API_AND_CONFIG_MAP|API that updates the authentication mode for a cluster. The authentication mode can also be updated by passing a config file, as in:

accessConfig:
  authenticationMode: <>

$ eksctl utils update-authentication-mode -f cluster.yaml

Disabling cluster creator admin permissions

eksctl will add a new field accessConfig.bootstrapClusterCreatorAdminPermissions: boolean that, when set to false, disables granting cluster-admin permissions to the IAM identity creating the cluster. When this field is set to false, eksctl will pass its value to BootstrapClusterCreatorAdminPermissions.

accessConfig:
  authenticationMode: API
  bootstrapClusterCreatorAdminPermissions: false
  accessEntries:
  - principalARN: arn:aws:iam::111122223333:user/my-user-name
    kubernetesGroups: # optional kubernetes groups
      - group1 # groups can used to give permissions via RBAC
      - group2

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the userdocs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes
• (Core team) Added labels for change area (e.g. area/nodegroup) and kind (e.g. kind/improvement)

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟