Unable to create Amazon EKS cluster - iam:PassRole permission denied for AmazonEKSClusterRole

Anupk · August 3, 2026, 1:50pm

eks
aws
iam
iam-passrole
lab

Hi Team,

I am currently working on the AWS EKS lab and trying to create an Amazon EKS cluster using the AWS Management Console.

During cluster creation, I receive the following error:

User: arn:aws:iam::211125745405:user/kk_labs_user_609621 is not authorized to perform: iam:PassRole on resource: arn:aws:iam::211125745405:role/AmazonEKSClusterRole because no identity-based policy allows the iam:PassRole action.

I am using the AmazonEKSClusterRole provided in the lab and have not modified any IAM roles or policies.

Could you please help me with the following?

Is this a permission issue with the lab account?
Does my IAM user require the iam:PassRole permission to create an EKS cluster?
Could you please grant the required permission if it is missing?
Will I need to request this permission every time a new KK Labs environment is provisioned, or is there a permanent solution?

I have attached the screenshot of the error for reference.

Thank you.

Santosh_KodeKloud · August 3, 2026, 1:51pm

Please refer to our guide on creating an EKS cluster on Playgrounds.

raymond.baoly · August 5, 2026, 7:15am

We also have a note about IAM permissions in the playground. You can read more here:

github.com

kodekloudhub/community-faq/blob/main/docs/playgrounds.md#cloud-iam

# Playground mini-FAQ

KodeKloud playgrounds are available to PRO subscribers and allow you to try things out in sandboxed playgrounds at no additional cost.

* [Why can't I?](#why-cant-i)
* [Cloud IAM](#cloud-iam)
    * [AWS IAM](#aws-iam)
* [Kubernetes Clusters](#kubernetes-clusters)
* [How do I browse my service?](#how-do-i-browse-my-service)

## Why can't I?

The majority of questions we handle on the forums are questions like "*Why can't I do X on this playground?*", normally in relation to the cloud playgrounds. These playgrounds have *limited* functionality and *restricted* access, i.e. it's not like you signed up for your own cloud account where you have full admin rights to do anything. There is of course nothing to stop you from signing up for your own cloud accounts - they are all free to sign up to, but you personally pay for any resources created which can get expensive quickly, especially if you forget to delete resources you created or you leave a door open and a hacker starts a bitcoin mining operation on your account! Our sandboxes, while limited, protect you from nasty surprises!

There are 3 main reasons

1. **Cost**. Many services are expensive to run. Also various configurations of services you are allowed to run like AWS EC2 where it's possible without constraints to launch a single instance that costs over 200 US dollars an hour! If we did not limit what can be done on a cost basis, the subscription price for PRO membership would have to be significantly increased!
1. **Security**. We need to protect against privilege escalations, e.g. ability to create new users with more permissions than the user you log in as, and unacceptable use of resources. Hence the IAM is quite tightly locked down. Tighter control on IAM also enforces the cost control described above, preventing users from launching costly resources.
1. **Manageability**. Adding a service that isn't currently offered in the playground is not a simple case of "just switch it on". We maintain a pool of cloud provider accounts which are recycled at the end of every session. For each supported service, there is a lot of work involved in:
    * Planning what parts of that service can be enabled from a cost point of view.

This file has been truncated. show original

I hope it helps answer your question.