Kubernetes clusters managed by EKS make calls to other AWS services on the user's behalf to manage the resources that
the cluster uses.
For a cluster to be allowed to make those calls, it **requires** to have the aforementioned permissions.
To create clusters which would **not** require access to any other AWS resource, one can assign the cluster the
`AWSServiceRoleForAmazonEKS` service-linked role directly [1][service-linked role permissions for amazon eks],
[2][amazon eks cluster iam role].
> Amazon EKS uses the service-linked role named `AWSServiceRoleForAmazonEKS` - The role allows Amazon EKS to manage
> clusters in your account. The attached policies allow the role to manage the following resources: network
> interfaces, security groups, logs, and VPCs.
>
> ---
>
> Prior to October 3, 2023, [AmazonEKSClusterPolicy] was required on the IAM role for each cluster.
>
> Prior to April 16, 2020, [AmazonEKSServicePolicy] was also required and the suggested name was `eksServiceRole`.
> With the `AWSServiceRoleForAmazonEKS` service-linked role, that policy is no longer required for clusters created on
> or after April 16, 2020.
Should one want to use more advanced features like [encryption with managed keys][secrets encryption through kms], the
role will need access to the referenced resources.
In this case it would probably be better to create a custom role instead of assigning permissions to the built-in one.
- \[suggestion] 1+ (one or more) custom service role(s) for the pod executors, with the required policies attached or
similar permissions.
The reasons and required permissions vary depending on the type of executor.