Lots of great questions and I encourage folks to keep raising and exploring these issues. Since security depends in part on sysadmins doing their job (and knowing what their job is), I think we're always going to have issues, especially since many less experienced folks don't realize they are sysadmins. Here are partial responses to some of the points you brought up:
- Though you bring up a lot of great security issues, I'm not sure many of them are that much more prevalent in environments like EC2 than they are in other data centers around the world. How many non-EC2 sysadmins are keeping their running servers up to date with the latest security patches?
- You ask: "If a publicly shared AMI like alestic's Gutsy image reaches EOL (this month)...do all the private derived images based on that AMI reach EOL as well or do they live on without access to security updates? How long do they live on?"
=> Perhaps I wasn't entirely clear in the wording: It's not the image that is reaching EOL, but Ubuntu 7.10 Gutsy itself. There will be no further security updates released for Gutsy after the 18th, so I recommend not using it.
=> The Gutsy AMI and any other AMIs based on it have no time bombs built in. They will continue to be available and run just like any distribution CD. You just *shouldn't* use them.
- You ask: "When public AMI's are revved for security, are the people running private AMI's derived from that public AMI encouraged to rev their private AMI as well or do people patch forward manually?"
=> I think different people take different approaches to this. Both methods are valid, though I think folks should be doing normal updates more often than new AMIs are released.
- You ask: "Does the EC2 pricing model encourage or discourage frequent revving of AMIs to include security updates?"
=> Not as such. It's financially inexpensive to store multiple AMIs. However, it tends to be expensive in terms of human labor to build and customize AMIs, which is one reason I encourage folks to write scripts to automate it so that it can be done easily in the future.
- You ask: "Do AMI cataloguing have any sort of "heritage" or "series" metric so that you can tell how individually registered AMIs relate to each other?"
=> Amazon's AMI catalog on http:/ec2ami.notlong.com hasn't changed much over time and definitely needs an update. I've tried to document the relationship of the base AMIs I built on pages like http://ec2hardy.notlong.com
but this is a lot of manual effort to maintain (See the "History" section).
- One point which you didn't mention but which does relate to security on EC2: It is not possible for normal users to patch kernels when security updates come out. We can only run the kernels provided by Amazon or trusted partners like Red Hat and Canonical. As far as I can tell, Amazon does not have a practice of releasing new kernels when security patches come out. I don't even think it would be possible for them to do so in such a way as to affect existing AMIs which default to the old kernel.
Also, since I happen to build the AMIs listed on http://alestic.com
, I thought I'd answer a few questions about them:
- The images on http://alestic.com
follow the standard Amazon EC2 security approaches with the root password disabled, only allowing ssh access using the keypair specified at launch.
- The images include the latest security patches as of the day they were built.
- Though it's impossible to "update" an existing image on EC2 and keep the same AMI id, I do release regular updated images with all security patches, and encourage folks to always start with the latest release (and still perform further updates after running it).
- I choose to not delete older images because there may still be companies depending on them. Even though we might think that they are wrong to start with old software, deleting the image would be like Canonical or Red Hat building a time bomb into their software where the entire OS shut down and would not reboot when the release reached EOL.