Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EKS] [request]: Add AdminRole option at cluster creation #554

Closed
inductor opened this issue Oct 31, 2019 · 5 comments
Closed

[EKS] [request]: Add AdminRole option at cluster creation #554

inductor opened this issue Oct 31, 2019 · 5 comments
Labels
EKS Amazon Elastic Kubernetes Service Proposed Community submitted issue

Comments

@inductor
Copy link

inductor commented Oct 31, 2019

Tell us about your request
Currently you have to create a cluster with a user/role that you actually use for cluster administration(for initializing processes at least).
It'd be nicer if EKS had an option to select "which role you want make an admin for this EKS cluster" especially when creating a cluster with CloudFormation.

Ref. https://docs.aws.amazon.com/eks/latest/userguide/troubleshooting.html

When an Amazon EKS cluster is created, the IAM entity (user or role) that creates the cluster is added to the Kubernetes RBAC authorization table as the administrator (with system:master permissions). Initially, only that IAM user can make calls to the Kubernetes API server using kubectl. For more information, see Managing Users or IAM Roles for your Cluster. Also, the AWS IAM Authenticator for Kubernetes uses the AWS SDK for Go to authenticate against your Amazon EKS cluster. If you use the console to create the cluster, you must ensure that the same IAM user credentials are in the AWS SDK credential chain when you are running kubectl commands on your cluster.

Which service(s) is this request for?
EKS

I'm trying to use CloudFormation for creating clusters without eksctl for some reason and can't use kubectl after creating a CFn Stack with CFn role of my company.

@inductor inductor added the Proposed Community submitted issue label Oct 31, 2019
@inductor inductor changed the title [EKS] [request]: Add AdminRole option at creating a cluster [EKS] [request]: Add AdminRole option at cluster creation Oct 31, 2019
@ellenthsu ellenthsu added the EKS Amazon Elastic Kubernetes Service label Nov 6, 2019
@TBeijen
Copy link

TBeijen commented Nov 25, 2019

We run into similar issues using Terraform, which in our case isn't executed locally but instead by a platform which assumes a certain role in the account.

Even when I have admin privileges in the account, I need to go through some crazy hoops (assuming the same role as is assumed by the Terraform platform) to be able to set-up aws-auth.

Furthermore, afaik the cluster creator is completely invisible. You can't deduce it from aws eks describe-cluster or AWS API, which seems odd.

Making the cluster creator a first-class property of the AWS EKS API would make a lot of sense imho.

@rzamana
Copy link

rzamana commented Oct 1, 2020

This would help our scenario where we create the EKS Cluster using CloudFormation/CDK in the CodeBuild.

The administrator of the Cluster ends to be the Role assumed by the CodeBuild, and I faced some problems with this because I would end deploying from my machine, and the CodeBuild didn't had access to it.

Having this option I could end deploying from my machine and giving the CodeBuild the administrator access.

Where I can give a 👍 for this feature?

@robgott
Copy link

robgott commented Nov 17, 2020

might be worth combining/closing #378 as it is a request for the same feature

@mikestef9
Copy link
Contributor

This will be solved by #185. You'll be able to view/edit/remove the cluster creator access entry just like any other user after cluster creation, it will no longer be hidden

@mikestef9
Copy link
Contributor

Addressed with #185

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EKS Amazon Elastic Kubernetes Service Proposed Community submitted issue
Projects
Status: Shipped
Development

No branches or pull requests

6 participants