Closed kaiorafael closed 1 year ago
I'm not sure we would ever want to ship the ssm agent. At least in the past we have decided against it for similar things. See https://github.com/coreos/fedora-coreos-tracker/issues/95
There is also a ticket for GCP OSLogin but it looks like we were trying to figure out how to implement it without the full agent.
If we were to get past the "no agents" part there is still a technical hurdle in that we can't ship packages in FCOS that aren't in Fedora so you'd have to get the package into the Fedora repos first.
Does the software provided by the package have a history of CVEs?
I am aware of only one beside CVE-2022-29527
This is the perfect example of security issues that come with cloud agents.
As Fedora CoreOS uses the same set of packages for all platforms, we would also have to make sure that this agent does not start / does not create issues on non AWS platforms if we include it.
Overall, I'm -1 for adding platform specific agents by default. If you want it, you should be able to layer it or build a custom image using CoreOS layering.
As Fedora CoreOS uses the same set of packages for all platforms, we would also have to make sure that this agent does not start / does not create issues on non AWS platforms if we include it.
I get you point @travier thanks for the reply. However, is there any reason to use the same build across different environments? I was thinking each Cloud provider had it's own image build recipe.
No, we ship one exact bootable container image/ostree commit across every platform.
Layering or custom bootable container images are both options, as is asking AWS to containerize.
I would say though that you can also configure ssh in other ways to gain the benefits touted by SSM - for example, making it only accessible over a VPN is a big one.
that need to secure their EC2 instances.
It depends though, because SSM is also a giant backchannel into the OS.
We discussed this topic in the community meeting today.
12:46:41* dustymabe | #agreed We will not include the amazon-ssm-agent in Fedora CoreOS.
| We have generally not shipped cloud agents in the past and the
| package is only available from third party repos. If users want to
| layer this package they have that option.
What, if any, are the additional dependencies on the package? (i.e. does it pull in Python, Perl, etc)
It gives an error when using
--dry-run
However, I am able to install it without that option.
What is the size of the package and its dependencies?
What problem are you trying to solve with this package? Or what functionality does the package provide?
In many organizations, SSH is not allowed, even in a controlled firewall environment. This is because SSH exposes EC2 instances to the public internet, which can be a security risk. On the other hand, AWS SSM provides a more secure way to connect to EC2 instances, as it uses encryption, authentication, and authorization mechanisms to protect the connection. This makes AWS SSM a compliance-friendly solution for organizations that need to secure their EC2 instances.
Besides that, AWS SSM can help:
Can the software provided by the package be run from a container? Explain why or why not.
It can be run by a container, but for AWS EC2 instance, SSM-in into the host and not the container should help troubleshoot and investigate issues.
Can the tool(s) provided by the package be helpful in debugging container runtime issues?
Yes
Can the tool(s) provided by the package be helpful in debugging networking issues?
Yes
Is it possible to layer the package onto the base OS as a day 2 operation? Explain why or why not.
Yes
In the case of packages providing services and binaries, can the packaging be adjusted to just deliver binaries?
I am not sure.
Can the tool(s) provided by the package be used to do things we’d rather users not be able to do in FCOS?
No, it's an better and secure way to log into the system not using SSH.
Does the software provided by the package have a history of CVEs?
I am aware of only one beside CVE-2022-29527