[ec2-beta] some feedback on the i386 image

[Eric Hammond]

Mark Shuttleworth wrote:
> Regardless, there are only two pieces of information that we need to
> deliver to the instance:
>  - the user name
>  - the crypted, or digested, password
> We can easily set it up so that EACH of the mechanisms you describe,
> and others, deliver that data to something in the standard base image
> which uses it to get the right result.

The only way to pass custom information like this into a new EC2
instance is through the user-data field.  This is a single blob of data
of up to 16K.

There are a few issues I see with passing in username and encrypted
password through user-data:

1. In most of the methods used to start EC2 instances, the user-data is
entered by hand (or copy-paste) by the user, e.g., into a field on a web
form.

2. Asking the user to encrypt a password and paste it in to the
user-data every time they run an instance makes the launch process more
complicated instead of simpler, which is our current goal.

3. When a user is finding and selecting an AMI to run inside these
applications, there is no way to provide documentation of any sort to
the user on how the instance should be run or what is expected in
user-data.  No matter what, we need to have good, usable, secure default
behavior when user-data is empty.

4. Since there is only one user-data field, it needs to be available for
users' to pass their own information in to the instance.  I started the
trend of having the image run the user-data if it starts with "#!" but
this is still optional and the user can co-opt the field for their own use.

5. The content of the user-data passed in to the instance is not very
private.  It is available to any user on the instance and to any other
process which can initiate an HTTP connection from that instance.  The
user-data is accessed by the instance at this URL:

  http://169.254.169.254/latest/user-data/

If we were to pass in a username and encrypted password through
user-data, it would be the equivalent of making /etc/shadow world
readable, plus giving access to it through any poorly configured web
proxy or web application.

One random example: A web site which lets the user specify a URL to
upload an image and then presents that image to the user might be abused
by an attacker to view the user-data from outside of EC2 by tricking the
web site into accessing the user-data URL.


Yeah, I get frustrated with some of the limitations of EC2, but the
benefits are well worth it and Amazon is regularly releasing great
updates and new features which improve the rewards.


If I'm not understanding your vision or you don't think we're talking
about the same use cases, I would like to make sure we're on the same
page as far as the goals we're trying to achieve.

This is not the first time I've wished the folks involved were in the
same room with a whiteboard.

--
Eric Hammond
ehammond at thinksome.com