| « PreviousNext » | |
   | Did this page help you? Yes | No | Tell us about it... |
Sharing AMIs Safely
Shared AMIs are AMIs that developers build and make available for other AWS developers to use. Building safe, secure, usable AMIs for public consumption is a fairly straightforward process if you follow a few simple guidelines.
For additional information about sharing AMIs safely, go to the following articles on the AWS Developer Resources website.
For information on building shared AMIs, see Protecting a Shared AMI (Linux/UNIX). For information on sharing AMIs, see Sharing AMIs.
Protecting a Shared AMI (Linux/UNIX)
Following these guidelines produces a better user experience, makes your users' instances less vulnerable to security issues, and helps protect you.
To build a shared AMI, follow these guidelines:
Update the AMI Tools at Boot Time
For AMIs backed by instance store, we recommend that your AMIs download and upgrade the Amazon EC2 AMI creation tools during startup. This ensures that new AMIs based on your shared AMIs have the latest AMI tools.
To update the AMI tools at startup on Fedora
Add the following to
rc.local:# Update the Amazon EC2 AMI creation tools echo " + Updating ec2-ami-tools" wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm && \ rpm -Uvh ec2-ami-tools.noarch.rpm && \ echo " + Updated ec2-ami-tools"
Use this method to automatically update other software on your image.
Note
When deciding which software to automatically update, consider the amount of WAN traffic that the update will generate (your users will be charged for it) and the risk of the update breaking other software on the AMI.
The preceding procedure applies to RPM-based distributions. For other distributions:
On most Red Hat systems, add these steps to your
/etc/rc.d/rc.localscript.On Gentoo systems, add them to
/etc/conf.d/local.local.On Ubuntu systems, add them to
/etc/rc.local.On Debian, you might need to create a start up script in
/etc/init.dand useupdate-rc.d <scriptname> defaults 99(where<scriptname>is the name of the script you created) and add the steps to this script.
Disable Password-Based Logins for Root
Using a fixed root password for a public AMI is a security risk that can quickly become known. Even relying on users to change the password after the first login opens a small window of opportunity for potential abuse.
To solve this problem, disable password-based logins for the root user. Additionally, we recommend you randomize the root password at boot.
To disable password-based logins for root
Open the
/etc/ssh/sshd_configfile with a text editor and locate the following line:#PermitRootLogin yes
Change the line to:
PermitRootLogin without-password
The location of this configuration file might differ for your distribution, or if you are not running OpenSSH. If this is the case, consult the relevant documentation.
To randomize the root password, add the following to your boot process:
if [ -f "/root/firstrun" ] ; then dd if=/dev/urandom count=50|md5sum|passwd --stdin root rm -f /root/firstrun else echo "* Firstrun *" && touch /root/firstrun
Note
This step assumes that a /root/firstrun file is bundled with the image. If the file was not created, the root password will never be randomized and is set to the default.
Restrict Access to the Root Account
When you work with shared AMIs, it is a known best practice to have a secure environment; one of the elements associated with a secure environment is ensuring the root password is not empty. To do this, log into your running instance and issue the following command to lock the root password:
sudo passwd -l root
Note
This does not impact the use of sudo.
Remove SSH Host Key Pairs
If you plan to share an AMI derived from a public AMI, remove the existing SSH host key
pairs located in /etc/ssh. This forces SSH to generate new unique
SSH key pairs when someone launches an instance using your AMI, improving
security and reducing the likelihood of "man-in-the-middle" attacks.
The following list shows the SSH files to remove.
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
Important
If you forget to remove the existing SSH host key pairs from your public AMI, our routine auditing process notifies you and all customers running instances of your AMI of the potential security risk. After a short grace period, we mark the AMI private.
Install Public Key Credentials
After configuring the AMI to prevent logging in using a password, you must make sure users can log in using another mechanism.
Amazon EC2 allows users to specify a public-private key pair name when launching an
instance. When a valid key pair name is provided to the
RunInstances API call (or through the command line API
tools), the public key (the portion of the key pair that Amazon EC2 retains on the server
after a call to CreateKeyPair or
ImportKeyPair) is made available to the instance through an
HTTP query against the instance metadata.
To log in through SSH, your AMI must retrieve the key value at boot and append it to
/root/.ssh/authorized_keys (or the equivalent for any other user
account on the AMI). Users can launch instances of your AMI with a key pair and
log in without requiring a root password.
if [ ! -d /root/.ssh ] ; then
mkdir -p /root/.ssh
chmod 700 /root/.ssh
fi
# Fetch public key using HTTP
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
cat /tmp/my-key >> /root/.ssh/authorized_keys
chmod 700 /root/.ssh/authorized_keys
rm /tmp/my-key
fi
This can be applied to any user account; you do not need to restrict it to root.
Note
Rebundling an instance based on this image includes the key with which it was
launched. To prevent the key's inclusion, you must clear out (or delete) the
authorized_keys file or exclude this file from rebundling.
Disabling sshd DNS Checks (optional)
Disabling sshd DNS checks slightly weakens your sshd security. However, if DNS resolution fails, SSH logins still work. If you do not disable sshd checks, DNS resolution failures prevent all logins.
To disable sshd DNS checks
Open the
/etc/ssh/sshd_configfile with a text editor and locate the following line:#UseDNS yes
Change the line to:
UseDNS no
Note
The location of this configuration file can differ for your distribution or if you are not running OpenSSH. If this is the case, consult the relevant documentation.
Identify Yourself
Currently, there is no easy way to know who provided a shared AMI because each AMI is represented by an account ID.
We recommend that you post a description of your AMI, and the AMI ID, in the Amazon EC2 developer forum. This provides a convenient central location for users who are interested in trying new shared AMIs. You can also post the AMI to the Amazon Machine Images (AMIs) page.
Protect Yourself
The previous sections described how to make your shared AMIs safe, secure, and usable for the users who launch them. This section describes guidelines to protect yourself from the users of your AMI.
We recommend against storing sensitive data or software on any AMI that you share. Users who launch a shared AMI might be able to rebundle it and register it as their own. Follow these guidelines to help you to avoid some easily overlooked security risks:
Always delete the shell history before bundling. If you attempt more than one bundle upload in the same image, the shell history contains your secret access key.
Bundling a running instance requires your private key and X.509 certificate. Put these and other credentials in a location that is not bundled (such as the instance store).
Exclude the ssh authorized keys when bundling the image. The Amazon public images store the public key used to launch an instance with its ssh authorized keys file.
Note
Unfortunately, it is not possible for this list of guidelines to be exhaustive. Build your shared AMIs carefully and take time to consider where you might expose sensitive data.
Protect Paid AMIs
The simplest way to prevent users from rebundling paid AMIs that you create is to not provide root access to the AMI and to pay attention to security announcements that involve privilege escalations. Amazon EC2 requires you to have root access on any AMI that you rebundle.
If you must provide root access to an AMI, Amazon EC2 tools are designed to protect the product code. Although this is effective, it is not guaranteed and users might create AMIs using other tools.
To ensure users cannot rebundle your paid AMIs, we recommend that you configure your application to check the instance metadata to verify that the product code is intact.
Sharing AMIs
Amazon EC2 enables you to share your AMIs with other AWS accounts. This section describes how to share AMIs using the Amazon EC2 management console and the command line tools.
Note
Before proceeding, make sure to read the security considerations of sharing AMIs in the Protecting a Shared AMI (Linux/UNIX) section.
Sharing an AMI Using the Management Console
To share an AMI using the management console
Open the Amazon EC2 console at https://console.aws.amazon.com/ec2/.
In the navigation pane, click AMIs.
Select your AMI in the list, then click Actions and select Edit.
Expand the Permissions area and ensure that the Private radio button is selected.
Click Add Permission, and type the AWS Account Number of the user with whom you want to share the AMI in the AWS Account Number field. Click Save (the checkmark button).
To share this AMI with multiple users, click Add Permission again and repeat the above step until you have added all the required users.
To allow create volume permissions for snapshots, check Add "create volume" permissions to the following associated snapshots when creating permissions.
Accessing Shared AMIs Using the Amazon EC2 Console
If another AWS user has shared an AMI with you, you can access it using the Amazon EC2 console.
To access a shared AMI using the console
In the navigation pane, click AMIs.
In the Filter list, select Private Images. All AMIs that have been shared with you are listed.
Using Bookmarks
If you have created a public AMI, or shared an AMI with another AWS user, you can create a bookmark that allows a user to access your AMI and launch an instance in their own account immediately. This is an easy way to share AMI references, so users don't have to spend time finding your AMI in order to use it.
Note that your AMI must be public, or you must have shared it with the user to whom you want to send the bookmark.
To create a bookmark for your AMI
Type a URL with the following information, where
<region>is the region in which your AMI resides, and<ami_id>is the ID of the AMI:https://console.aws.amazon.com/ec2/home?region=
<region>#launchAmi=<ami_id>For example, this URL launches an instance from the ami-2bb65342 AMI in the us-east-1 region:
https://console.aws.amazon.com/ec2/home?region=us-east-1#launchAmi=ami-2bb65342
Distribute the link to users who want to use your AMI.
To use a bookmark, click the link or copy and paste it into your browser. The Launch Wizard opens, and the CHOOSE AN AMI page is pre-populated with the AMI's details.
Sharing an AMI Using the Command Line Tools
This section explains how to share an AMI using the command line tools.
AMIs have a launchPermission property that controls which
AWS accounts, besides the owner's, are allowed to launch instances of that AMI. By
modifying an AMI's launchPermission property, you can allow all
AWS accounts to launch the AMI (make the AMI public) or only allow a few
specific accounts to launch the AMI.
The launchPermission attribute is a list of accounts and
launch groups. Launch permissions can
be granted by adding or removing items from the list. Explicit launch permissions
for accounts are granted or revoked by adding or removing their AWS account IDs.
The only launch group currently supported is the all group, which
makes the AMI public. The rest of this section refers to launch groups simply as
groups. Launch groups are not the same as security groups and the two should not be
confused. An AMI can have both public and explicit launch permissions.
Note
You are not billed when your AMI is launched by other AWS accounts. The accounts launching the AMI are billed.
Making an AMI Public
This section explains how to make an AMI public.
Note
Images with an AWS Marketplace product code cannot be made public.
To make an AMI public
Add the
allgroup to the AMI'slaunchPermission.PROMPT>ec2-modify-image-attribute<ami_id>--launch-permission -a allThe
<ami_id>parameter is the ID of the AMI.
To check the launch permissions of an AMI
Enter the following command, where
<ami_id>is the ID of the AMI.PROMPT>ec2-describe-image-attribute<ami_id>-l
To make an AMI private again
Remove the
allgroup from its launch permissions, where<ami_id>is the ID of the AMI.PROMPT>ec2-modify-image-attribute<ami_id>-l -r allThis does not affect any explicit launch permissions for the AMI or any running instances of the AMI.
Example
This example makes the ami-2bb65342 AMI public.
PROMPT>ec2-modify-image-attributelaunchPermission ami-2bb65342 ADD group allami-2bb65342--launch-permission -a all
This example displays the launch permissions of the ami-2bb65342 AMI.
PROMPT>ec2-describe-image-attributelaunchPermission ami-2bb65342 group allami-2bb65342-l
This example removes the all group from the permissions of
the ami-2bb65342 AMI, making it private.
PROMPT>ec2-modify-image-attributelaunchPermission ami-2bb65342 REMOVE group allami-2bb65342-l -r all
Sharing an AMI with Specific AWS Accounts
You can share an AMI with specific AWS accounts without making the AMI public. All you need is the account ID.
To grant explicit launch permissions
Enter the following command:
PROMPT>ec2-modify-image-attribute<ami_id>-l -a<user_id>The
<ami_id>is the ID of the AMI and<user_id>is the account ID, without hyphens.
To remove launch permissions for an account
Enter the following command:
PROMPT>ec2-modify-image-attribute<ami_id>-l -r<user_id>The
<ami_id>is the ID of the AMI and<user_id>is the account ID, without hyphens.
To remove all launch permissions
Enter the following command to remove all public and explicit launch permissions:
PROMPT>ec2-reset-image-attribute<ami_id>-lThe
<ami_id>is the ID of the AMI.
Note
The AMI owner always has rights to the AMI and is unaffected by this command.
Example
The following example grants launch permissions to the AWS account with ID 111122223333 for the ami-2bb65342 AMI:
PROMPT>ec2-modify-image-attributelaunchPermission ami-2bb65342 ADD userId 111122223333ami-2bb65342-l -a111122223333
The following example removes launch permissions from the AWS account with ID 111122223333 for the ami-2bb65342 AMI:
PROMPT>ec2-modify-image-attributelaunchPermission ami-2bb65342 REMOVE userId 111122223333ami-2bb65342-l -r111122223333
The following example removes all public and explicit launch permissions from the ami-2bb65342 AMI:
PROMPT>ec2-reset-image-attributelaunchPermission ami-2bb65342 RESETami-2bb65342-l
Publishing Shared AMIs
After you create a shared AMI, you can publish information about it in the Amazon EC2 Resource Center.
To publish your AMI
Post it in the Public AMIs Folder of the Amazon Web Services Resource Center, and include the following information:
AMI ID
AMI name (for Amazon EBS-backed AMIs) or AMI manifest (for Amazon EC2 instance store-backed AMIs)
Publisher
Publisher URL
OS / Distribution
Key Features
Description
Daemons / Services
Release Notes
If you want to, you can paste the following information into the document. You must be in HTML edit mode.
<strong>AMI ID: </strong>[ami-id]<br /> <strong>AMI Manifest: </strong>[myawsbucket/image.manifest.xml]<br /> <h2>About this &AMI;</h2> <ul> <li>Published by [Publisher] (<a href="http://www.example.com">[http://www.example.com]</a>).<br /> </li> <li>[Key Features] <br /> </li> <li>[Description]</li> <li>This image contains the following daemons / services: <ul> <li>[Daemon 1]</li> <li>[Daemon 2]</li> </ul> </li> </ul> <h2><strong>What's New?</strong></h2>The following changes were made on [Date].<br /> <ul> <li>[Release Notes 1]</li> </ul> <span style="font-size: x-small; font-family: courier new,courier"> - [Note 1]</span><br /> <span style="font-size: x-small; font-family: courier new,courier"> - [Note 2]</span><br /> <span style="font-size: x-small; font-family: courier new,courier"> - [Note 3]</span><br /> <!--<ul>-->
