Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-09-13T12:33:30.657Z
Answers: 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
Answers: Seth E
Answers: CC BY-SA 4.0
Answers: 2024-09-13T13:19:16.420Z
Answers: I expanded the answer. Please consider accepting it, if it was helpful.
Answers: Chris
Answers: CC BY-SA 4.0
Answers: 2024-09-14T16:48:01.323Z
Answers: 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
Answers: Seth E
Answers: CC BY-SA 4.0
Answers: 2024-09-21T16:28:54.557Z
Answers: can you please check with the IAM access for this cluster?
Answers: MD Nasirul Islam
Answers: CC BY-SA 4.0
Answers: 2024-09-12T07:26:59.943Z
Answers: 2024-09-13T13:18:18.140Z
Answers: 2024-09-13T13:18:18.140Z
Answers: Chris
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-09-07T20:45:06.207Z
Answers: 2024-09-07T20:45:06.207Z
Answers: Seth E
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2024-10-14T18:35:24.593Z
Answers: 2024-10-17T04:55:00.673Z
Answers: 2024-10-17T04:55:00.673Z
Answers: Asher Aber
Body: <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>
  
Tags: <kubernetes><amazon-web-services><kubectl><eks>
Title: 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
UserDisplayName: Seth E
ThreadText: # 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](https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting_iam.html#security-iam-troubleshoot-cannot-view-nodes-or-workloads)
  
  #### `kubectl`
  
  ```
  the server has asked for the client to provide credentials
  
  ```
  
  #### `eksctl`
  
  ```
  Error: getting auth <object>>: 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](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#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](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest#input_cluster_endpoint_public_access).
  
  #### 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](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest#input_enable_cluster_creator_admin_permissions)
  
  ## 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 <region>> update-kubeconfig --name <cluster_name>`
  
  `eksctl get cluster --name <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:
  
  1. Use this command to find the user/role used to create the cluster
  
  ```
  aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateCluster --region <region>
  
  ```
  
  2. Update the above role's trust relationship document and add your Principal like so:
  
  ```
  "arn:aws:iam::0123456789123:user/terraform"
  
  ```
  
  3. 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"
  
  ```
  
  4. 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 <region> update-kubeconfig --name my-cluster
  
  ```
  
  5. If done correctly, now you should be able to run:
  
  ```
  kubectl get nodes
  
  ```
  
  
  ---
  
  