[EKS] [request]: EKS Support without SSH/SSM
- 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
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