aws / aws/containers-roadmap

[EKS] [request]: EKS Support without SSH/SSM

Open
#399 3 comments 4 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

**Tell us about your request**

Better debugging info/ support process around EKS.

**Which service(s) is this request for?**
EKS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

The main issue is that AWS EKS Support pretty much requires SSH-ing into the worker nodes for any support requests that are more involved.

As soon as a more serious support ticket is created, [eks-logs-collector](https://github.com/nithu0115/eks-logs-collector) needs to be ran on an instance having issues. This collector requires either SSHing into the instance **or** running the command through AWS SSM.
Of course, AWS SSM is not installed by default in the AWS-provided AMI, but can be installed with a DaemonSet( https://github.com/awslabs/amazon-eks-ami/issues/127 has the discussion on that).
Unfortunately, the AWS SSM IAM Policy wants `s3:*` permissions which is pretty much a dealbreaker in some industries.

Is this really the way we have to do things? Can logs from things be pushed to CloudWatch? Can we get some more visibility into pieces that are running?

Is improving this part of any plan at AWS?

**Are you currently working around this issue?**
Unclear. Right now we're pretty much stumped. We'll likely do some semi-automated AWS SSM policy attachment, AWS SSM install, run the commands, and then uninstall and detach everything.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the EKS support scenario described in the issue, including eks-logs-collector, AWS SSM, the AWS-provided AMI, and the linked DaemonSet discussion. Define what a support process without SSH or SSM should provide, including log visibility and permissions, then verify that the proposed approach covers serious support tickets without requiring broad s3:* access.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.