Containers-roadmap: SSM agent pre-installed on the EKS-optimized AMI
Community Note
- Please vote on this issue by adding a 馃憤 reaction 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
Tell us about your request
SSM agent pre-installed on the EKS-optimizd AMI. The latest EKS-Optimized AMIs do not have the SSM agent installed and running at boot. However, SSM Agent is installed, by default, on Amazon Linux 2 AMI (base AMIs).
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?
Security and Compliance departments in enterprises and small businesses are often checking for SSM agents installed and running on machines at all times and report on non-compliant systems. The ability to patch quickly (critical patches) may still be a requirement by internal security teams prior to Amazon releasing any new EKS-Opt AMI.
Are you currently working around this issue?
Having to SSH from an admin machine or use Systems Manager to install/apply SSM agent on EKS Optimized AMI worker nodes is additional work that is not required on base Amazon Linux 2 base AMIs.
AndrewMcFarren
All 3 comments
Related issue in amazon-eks-ami repo https://github.com/awslabs/amazon-eks-ami/issues/404
and https://github.com/awslabs/amazon-eks-ami/issues/127
Based on previous discussion, it's unlikely to have SSM agent with EKS AMIs, however, few workarounds were mentioned. I myself have been using this https://github.com/mumoshu/kube-ssm-agent
sayboras
on 3 Apr 2020
max-rocket-internet
on 6 Apr 2020
Beyond just "me too", I have two specific reasons I think this is important:
1) It is inconsistent to put forward an AMI with SSM as a best practice for general compute and not to do the same with EKS optimized AMIs. Either SSM on the default AL2 AMI is bloat and it shouldn't be there or it's good practice and it should be included in the EKS version. This lack of consistency also leads to problems when people don't read the fine print and can't figure out why their EKS nodes aren't showing up. TL;DR: it's bad user experience and reduces confidence in either SSM or EKS (or both).
2) SSH server is on by default. sure you've gotta set up security groups to allow access, but the same is true for SSM - even if the agent is running nothing can use it if the right permissions aren't granted. it makes more sense to encourage people to use SSM than SSH and people would probably push back hard against not including an SSH server on the AMI by default. But it would honestly make more sense than the situation we have today.
underrun
on 27 Aug 2020
Related issues
pauldougan
路
3Comments
adlemich
路
3Comments
inductor
路
3Comments
talawahtech
路
3Comments
chungath
路
3Comments
Most helpful comment
Beyond just "me too", I have two specific reasons I think this is important:
1) It is inconsistent to put forward an AMI with SSM as a best practice for general compute and not to do the same with EKS optimized AMIs. Either SSM on the default AL2 AMI is bloat and it shouldn't be there or it's good practice and it should be included in the EKS version. This lack of consistency also leads to problems when people don't read the fine print and can't figure out why their EKS nodes aren't showing up. TL;DR: it's bad user experience and reduces confidence in either SSM or EKS (or both).
2) SSH server is on by default. sure you've gotta set up security groups to allow access, but the same is true for SSM - even if the agent is running nothing can use it if the right permissions aren't granted. it makes more sense to encourage people to use SSM than SSH and people would probably push back hard against not including an SSH server on the AMI by default. But it would honestly make more sense than the situation we have today.