aws / aws/containers-roadmap

[EKS] [request]: Auto-apply node role labels securely

Open
#1,381 10 comments 11 reactions 0 assignees View on GitHub
EKS Proposed
Dominant language
Shell
Stars
5.4k
Forks
334
PR merge metrics
No merged PRs in 30d

Description

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

### Idea

Since Kubernetes 1.16, the Kubelet is not allowed anymore to provide node labels by itself [due to security reasons](https://github.com/kubernetes/kubernetes/issues/84912#issuecomment-551362981). However, with Cluster Autoscaler or with a [maximum EC2 instance lifetime](https://aws.amazon.com/about-aws/whats-new/2019/11/amazon-ec2-auto-scaling-supports-max-instance-lifetime/) it is not feasible to label every node by hand. There is a discussion going on how to [auto-label nodes based on tags](https://github.com/kubernetes/cloud-provider-aws/issues/110), but I don't think this is the right approach, because it would re-introduce the security issue why this change was made.

To apply the node role label both _automatically_ and _securely_, the node must provide an identity evidence – it's IAM identity – to a cluster component, which would perform the labelling. So here are a few ideas I have how this could be built:

Create a `DaemonSet` retrieves the node's IAM role and a custom resource to specify which node labels should be applied to that IAM role. Based on that information, the operator can perform the automatic labelling.

Or you build that directly into the EKS control plane with a new IAM action like `eks:LabelNode`, which would be performed when the Kubelet starts up. As there is already some authentication mechanism in place when the node joins the cluster, it could be integrated there, too. Instead of creating a custom resource, the `aws-auth` config map could be extended, too.

Looking forward to type `kubectl get nodes` and to quickly identify my node roles again :-)

❗ _Update: This feature request applies especially to nodes that are managed outside EKS, sometimes called unmanaged nodes._

Contributor guide

Open the contributing guide

Research direction

No repository files, tests, or entry points are identified. Start by reviewing the security rationale and compare the proposed DaemonSet/custom-resource approach with the EKS control-plane and aws-auth alternatives. Done requires a decided implementation path, defined scope, and acceptance criteria for securely applying IAM-based node role labels.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kubernetes
Domain
cloud, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.