+
+ 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].
+ 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.
+ > 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.
+ > 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.
+ 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.
+
+
+- \[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.