<blockquote>
<p>What is the use case for creating an EKS cluster with <code>enable_cluster_creator_admin_permissions = false</code>?</p>
</blockquote>
<p>This is the default when creating a cluster and the recommended way to create it.</p>
<p>If set to <code>true</code> the principal that created the cluster has full admin access. This will probably violate your RBAC concept. Also since the cluster is usually created by a pipeline, this gives the pipeline's principal access to all cluster resources, which it will most probably not need and only increases the attack vector.</p>
<p>Best practice is to have a cluster admin principal be created with the cluster and added as cluster admin on creation.</p>
<pre><code>[...]
enable_cluster_creator_admin_permissions = false
access_entries = {
    cluster_admin = {
      kubernetes_groups = []
      principal_arn     = var.arn

      policy_associations = {
        cluster_admin = {
          policy_arn = &quot;arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy&quot;
          access_scope = {
            type = &quot;cluster&quot;
          }
        }
      }
    }
    dev_team_one = {
      [...]
    }
}
[...]
</code></pre>
<p>By that it becomes far easier to manage access control to your cluster resources.</p>
<p>You can grant the creator full admin access in PoC clusters. But other than that it should be disabled for various reasons.</p>
<p><strong>EDIT</strong></p>
<blockquote>
<p>But why no kubernetes groups... shouldn't you add it to system.masters?</p>
</blockquote>
<p><code>kubernetes_groups</code> is meant for custom groups. If you want to bind to <code>system:masters</code> rather use <code>policy_associations</code> as in the example above.</p>
<p><code>policy_associations.x.access_scope.policy_arn</code> is mapped to one of the <a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles" rel="nofollow noreferrer">user-facing roles</a></p>
<p>The example above would map to 'cluster-admin' to the <code>system:masters</code> group via <code>ClusterRoleBinding</code>.</p>
<p>You could probably also set the group there and don't set <code>policy_associations</code>. But I have not tested it. Point is, it does the same and is the recommended way.</p>

CC BY-SA 4.0
2024-09-13T12:33:30.657Z
Thank you!  But why no kubernetes groups... shouldn't you add it to system.masters?  My problem was that with `enable_cluster_creator_admin_permissions = false`, then even with an IAM principal with full admin access I was a t a dead end because I could not add any IAM principal to system.masters
Seth E
CC BY-SA 4.0
2024-09-13T13:19:16.420Z
I expanded the answer. Please consider accepting it, if it was helpful.
Chris
CC BY-SA 4.0
2024-09-14T16:48:01.323Z
very cool.  And here is where the `terraform-aws-eks` module executes that very same logic if `enable_cluster_creator_admin_permissions = true` - https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/main.tf#L154
Seth E
CC BY-SA 4.0
2024-09-21T16:28:54.557Z
can you please check with the IAM access for this cluster?
MD Nasirul Islam
CC BY-SA 4.0
2024-09-12T07:26:59.943Z
2024-09-13T13:18:18.140Z
2024-09-13T13:18:18.140Z
Chris
<h2>The Answer</h2>
<h4>Prerequisite</h4>
<p>Ensure the cluster API endpoint is accessible.</p>
<p>If <code>kubectl</code> returns an error like this:</p>
<pre><code>&quot;https://XXXXX.gr7.us-east-1.eks.amazonaws.com/api?timeout=32s&quot;: dial tcp 10.0.2.234:443: i/o timeout
</code></pre>
<p>...then one possibility preventing you from connecting to the API is <strong>API server endpoint access</strong>. You can either set it <em>public</em> with a CIDR access list, or must access it from inside the VPC.</p>
<p>see <code>cluster_endpoint_public_access</code> and associated settings <a href="https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest#input_cluster_endpoint_public_access" rel="nofollow noreferrer">here</a>.</p>
<h4>Solution</h4>
<p>Ensure the cluster creator has admin permissions.</p>
<p>This may be your issue if <code>kubectl</code> returns an error like this:</p>
<pre><code>the server has asked for the client to provide credentials
</code></pre>
<p>This one is the big &quot;gotcha&quot;, since when creating a cluster with <code>eksctl</code> it takes care of this for you. However, when creating an EKS cluster with Terraform the default for this setting is <code>false</code>. You need to actively configure it to <code>true</code>.</p>
<p><code>enable_cluster_creator_admin_permissions = true</code> - more info
<a href="https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest#input_enable_cluster_creator_admin_permissions" rel="nofollow noreferrer">here</a></p>
<h2>Why did I create this post?</h2>
<p>I created this question and answer because when I encountered this problem and researched it all of the answers seemed to assume that the cluster was created through <code>eksctl</code> and that the cluster creator already had admin privileges.</p>
<p>The answers I found all assumed that you could actually still issue <code>kubectl</code> and <code>eksctl</code> commands. In the case where you did <em>not</em> specify <code>enable_cluster_creator_admin_permissions = true</code>, <code>kubectl</code> will <em>not</em> work and many <code>eksctl</code> commands will not work and will fail with an error such as this:</p>
<pre><code>Error: getting auth ConfigMap: Unauthorized
</code></pre>
<p>Note that some <code>eksctl</code> commands will work, as they rely on the Amazon APIs and not the cluster API.  For example these will still work</p>
<p><code>aws eks --region &lt;region&gt;&gt; update-kubeconfig --name &lt;cluster_name&gt;</code></p>
<p><code>eksctl get cluster --name &lt;cluster_name&gt;</code></p>
<h2>The part I do not yet understand</h2>
<p>If you create an EKS cluster with the <code>enable_cluster_creator_admin_permissions</code> of <code>false</code> it appears to me that there is <em>no way forward</em> to reconfiguring your cluster to make it usable.</p>
<ul>
<li>You lack the privileges to add a user to <code>system:masters</code> through either the AWS console or <code>eksctl create iamidentitymapping</code>.</li>
<li>You cannot use <code>kubectl</code> and cannot access any resources (Cluster, workload, config, service, etc) through the AWS console.</li>
</ul>
<p>So my remaining question are:</p>
<ul>
<li>What is the use case for creating an EKS cluster with <code>enable_cluster_creator_admin_permissions = false</code>?</li>
<li>And if there are none, why is there even a <code>enable_cluster_creator_admin_permissions</code> setting, and why doesn't it default to <code>true</code>?</li>
</ul>

CC BY-SA 4.0
2024-09-07T20:45:06.207Z
2024-09-07T20:45:06.207Z
Seth E
<p>I had this issue after I launched an EKS cluster with Terraform</p>
<p>In order to hack your way into the cluster you will need to:</p>
<ol>
<li>Use this command to find the user/role used to create the cluster</li>
</ol>
<pre><code>aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateCluster --region &lt;region&gt;
</code></pre>
<ol start="2">
<li>Update the above role's trust relationship document and add your Principal like so:</li>
</ol>
<pre><code>&quot;arn:aws:iam::0123456789123:user/terraform&quot;
</code></pre>
<ol start="3">
<li>Use aws cli to assume the above user/role with code like this:</li>
</ol>
<pre><code>aws sts assume-role \
    --role-arn &quot;arn:aws:iam::0123456789123:role/devops&quot; \
    --role-session-name &quot;eks-access-session&quot;
</code></pre>
<ol start="4">
<li>Use the output key secret-key and token like so:</li>
</ol>
<pre><code>export AWS_ACCESS_KEY_ID=ASxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=&quot;Rsdfdfsfsfsfsfsfsfsdfsf&quot;
export AWS_SESSION_TOKEN=&quot;IsafadfafsdafasfasfafsafafVeryLongTokennnnn&quot;
aws eks --region &lt;region&gt; update-kubeconfig --name my-cluster
</code></pre>
<ol start="5">
<li>If done correctly, now you should be able to run:</li>
</ol>
<pre><code>kubectl get nodes
</code></pre>

CC BY-SA 4.0
2024-10-14T18:35:24.593Z
2024-10-17T04:55:00.673Z
2024-10-17T04:55:00.673Z
Asher Aber
<h2>This question seeks a solution for the following errors</h2>
<p>If you create an EKS cluster using terraform, and then use the <em>same</em> credentials you used to create the cluster, but see these errors, then what can you do to fix the issue?</p>
<h4>AWS Console</h4>
<pre><code>Your current IAM principal doesn’t have access to Kubernetes objects on this cluster.
This may be due to the current user or role not having Kubernetes RBAC permissions to describe cluster resources or not having an entry in the cluster’s auth config map
</code></pre>
<p>Which includes a not-so-helpful link to <a href="https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting_iam.html#security-iam-troubleshoot-cannot-view-nodes-or-workloads" rel="nofollow noreferrer">Learn more</a></p>
<h4><code>kubectl</code></h4>
<pre><code>the server has asked for the client to provide credentials
</code></pre>
<h4><code>eksctl</code></h4>
<pre><code>Error: getting auth &lt;object&gt;&gt;: Unauthorized
</code></pre>

<kubernetes><amazon-web-services><kubectl><eks>
I created an Amazon EKS Kubernetes cluster using Terraform, but now I do not have access to any of the resources, and kubectl fails due to credentials
Seth E
# I created an Amazon EKS Kubernetes cluster using Terraform, but now I do not have access to any of the resources, and kubectl fails due to credentials

(Asked by: username_0 on 2024-09-07)

This question seeks a solution for the following errors
If you create an EKS cluster using terraform, and then use the same credentials you used to create the cluster, but see these errors, then what can you do to fix the issue?
AWS Console
Your current IAM principal doesn’t have access to Kubernetes objects on this cluster.
This may be due to the current user or role not having Kubernetes RBAC permissions to describe cluster resources or not having an entry in the cluster’s auth config map

Which includes a not-so-helpful link to Learn more
kubectl
the server has asked for the client to provide credentials

eksctl
Error: getting auth >: Unauthorized

**Tags:** kubernetes, amazon-web-services, kubectl, eks


---

## 3 answers

### Answer by username_1 on 2024-09-12. Score: 1 | Accepted answer

What is the use case for creating an EKS cluster with enable_cluster_creator_admin_permissions = false?

This is the default when creating a cluster and the recommended way to create it.
If set to true the principal that created the cluster has full admin access. This will probably violate your RBAC concept. Also since the cluster is usually created by a pipeline, this gives the pipeline's principal access to all cluster resources, which it will most probably not need and only increases the attack vector.
Best practice is to have a cluster admin principal be created with the cluster and added as cluster admin on creation.
[...]
enable_cluster_creator_admin_permissions = false
access_entries = {
    cluster_admin = {
      kubernetes_groups = []
      principal_arn     = var.arn

      policy_associations = {
        cluster_admin = {
          policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
          access_scope = {
            type = "cluster"
          }
        }
      }
    }
    dev_team_one = {
      [...]
    }
}
[...]

By that it becomes far easier to manage access control to your cluster resources.
You can grant the creator full admin access in PoC clusters. But other than that it should be disabled for various reasons.
EDIT

But why no kubernetes groups... shouldn't you add it to system.masters?

kubernetes_groups is meant for custom groups. If you want to bind to system:masters rather use policy_associations as in the example above.
policy_associations.x.access_scope.policy_arn is mapped to one of the user-facing roles
The example above would map to 'cluster-admin' to the system:masters group via ClusterRoleBinding.
You could probably also set the group there and don't set policy_associations. But I have not tested it. Point is, it does the same and is the recommended way.

> **Comments:**
> **username_0**: Thank you!  But why no kubernetes groups... shouldn't you add it to system.masters?  My problem was that with `enable_cluster_creator_admin_permissions = false`, then even with an IAM principal with full admin access I was a t a dead end because I could not add any IAM principal to system.masters  
> **username_1**: I expanded the answer. Please consider accepting it, if it was helpful.  
> **username_0**: very cool.  And here is where the `terraform-aws-eks` module executes that very same logic if `enable_cluster_creator_admin_permissions = true` - https://github.com/terraform-aws-modules/terraform-aws-eks/blob/master/main.tf#L154  
> **username_2**: can you please check with the IAM access for this cluster?  

---

### Answer by username_0 on 2024-09-07. Score: 1

The Answer
Prerequisite
Ensure the cluster API endpoint is accessible.
If kubectl returns an error like this:
"https://XXXXX.gr7.us-east-1.eks.amazonaws.com/api?timeout=32s": dial tcp 10.0.2.234:443: i/o timeout

...then one possibility preventing you from connecting to the API is API server endpoint access. You can either set it public with a CIDR access list, or must access it from inside the VPC.
see cluster_endpoint_public_access and associated settings here.
Solution
Ensure the cluster creator has admin permissions.
This may be your issue if kubectl returns an error like this:
the server has asked for the client to provide credentials

This one is the big "gotcha", since when creating a cluster with eksctl it takes care of this for you. However, when creating an EKS cluster with Terraform the default for this setting is false. You need to actively configure it to true.
enable_cluster_creator_admin_permissions = true - more info
here
Why did I create this post?
I created this question and answer because when I encountered this problem and researched it all of the answers seemed to assume that the cluster was created through eksctl and that the cluster creator already had admin privileges.
The answers I found all assumed that you could actually still issue kubectl and eksctl commands. In the case where you did not specify enable_cluster_creator_admin_permissions = true, kubectl will not work and many eksctl commands will not work and will fail with an error such as this:
Error: getting auth ConfigMap: Unauthorized

Note that some eksctl commands will work, as they rely on the Amazon APIs and not the cluster API.  For example these will still work
aws eks --region > update-kubeconfig --name 
eksctl get cluster --name 
The part I do not yet understand
If you create an EKS cluster with the enable_cluster_creator_admin_permissions of false it appears to me that there is no way forward to reconfiguring your cluster to make it usable.

You lack the privileges to add a user to system:masters through either the AWS console or eksctl create iamidentitymapping.
You cannot use kubectl and cannot access any resources (Cluster, workload, config, service, etc) through the AWS console.

So my remaining question are:

What is the use case for creating an EKS cluster with enable_cluster_creator_admin_permissions = false?
And if there are none, why is there even a enable_cluster_creator_admin_permissions setting, and why doesn't it default to true?


---

### Answer by username_3 on 2024-10-14. Score: 1

I had this issue after I launched an EKS cluster with Terraform
In order to hack your way into the cluster you will need to:

Use this command to find the user/role used to create the cluster

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateCluster --region 


Update the above role's trust relationship document and add your Principal like so:

"arn:aws:iam::0123456789123:user/terraform"


Use aws cli to assume the above user/role with code like this:

aws sts assume-role \
    --role-arn "arn:aws:iam::0123456789123:role/devops" \
    --role-session-name "eks-access-session"


Use the output key secret-key and token like so:

export AWS_ACCESS_KEY_ID=ASxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY="Rsdfdfsfsfsfsfsfsfsdfsf"
export AWS_SESSION_TOKEN="IsafadfafsdafasfasfafsafafVeryLongTokennnnn"
aws eks --region  update-kubeconfig --name my-cluster


If done correctly, now you should be able to run:

kubectl get nodes


---

