Elastic Security

Icon

Security for the Cloud

AWS Security Announcements

Within one day, Amazon Web Services (AWS) announced two important security features: AWS Virtual Private Cloud and Multi-Factor Authentication. This is good to hear – and shows two things in my opinion:

  • Security is beginning to drive Amazon’s roadmap
  • Amazon considers hybrid deployments, i.e. the combination of internal IT with public clouds,  as an important scenario for cloud adoption in the enterprise market.
VPC (Source: Amazon)

VPC (Source: Amazon)

The VPC is effectively extending the perimeter of the customers’ datacenters into the public cloud. Amazon speaks of isolation at the network level. I wonder if they can guarantee that instances running on the VPC do not share virtual machines with other instances outside the VPC. It would be great to provide isolation at the AMI instance level as well to avoid problems of side channel attacks between images executing on the same virtual machine, such as the attacks described here.

Update from Amazon:  “We don’t make any such guarantee at present. Over time, if customers ask for this, we’ll certainly do our best to meet their needs.

Since Chrismas is approaching fast, two things I would like to add on my wishlist:

  • it would be great to know more about the traffic isolation within VPC
  • to be able to use security groups on VPC as well

More reading on Amazon’s recent security announcements:

Filed under: AWS, Discussions

EC2 Design Patterns (1): ExternalConsole

First pattern from our series about EC2 Design Patterns.

Intent

Give API access to an EC2 instance created from a publically available virtual image (AMI).

Motivation

Sometimes it is necessary that a server deployed on the EC2 platform has access to the EC2 API itself. Examples include access to persistent storage, instantiate other machine images to scale an application, reassign IP addresses, monitor other instances, change security groups, create key pairs, create snapshots for backup, and more. Any access to the API requires the EC2 credentials. Those credentials allow complete control over the whole platform of an Amazon account and must therefore be stored and communicated in a secure and reliable manner.  Amazon EC2 provides a console via a web-interface that allows to deploy and startup Amazon Machine Images, but it does not allow to pass AWS credentials to the upstarting image.

Since the image is public and can be instantiated by many different accounts, the credentials cannot be stored on the image itself. Credentials can be passed as so called user data when an image is started via the API.

Applicability

Use ExternalConsole when

  • you want to apply an AMI that needs access to the EC2 API
  • you want to facilitate deployments and especially avoid any manual interventions for the user who deploys the image  (e.g. avoid starting the image using API command line tools, edit configuration files on the image, etc.)

Participants

  • External Console: piece of software running outside Amazon EC2 with access to the EC2 credentials (by asking the user to enter them or by retrieving it from a database, for example). The main task of the external console is to deploy a virtual image on EC2 while passing the AWS credentials to it.
  • AMI: Amazon Machine Image, e.g. a virtual image that needs access to the EC2 API.
  • AMI Instance: the actual virtual machine instance resulting from deploying the AMI. The AMI Instance
  • Image Provider: a person or organism that create the AMI
  • Image User: a person or organism that deploys the AMI and manages AMI instances

Collaborations

  • The Image User that wants to deploy an image connects to the External Console and instructs it to deploy a certain AMI
  • The External Console retrieves the AWS credentials (e.g. from a database), connects to the EC2 API, and deploys the selected AMI while passing the AWS credentials to the upstarting AMI instance
  • The AMI instance gets the AWS credentials as user data and stores them on local storage. It uses the credentials to perform API methods (e.g. to have access to persistent storage). Upon a reboot, it retrieves the credentials from its storage

Consequences

The ExternalConsole offers the following benefits:

  • From the perspective of the image provider: flexibility to provide abstraction to the image users from all possible EC2 dependencies. The External Console component is under the control of the software provider and can be adapted transparently for the end-user to any API modifications or new features
  • From the perspective of the image user: ease of use. The credentials must be entered only once

At the other hand, it may have the following drawbacks:

  • From the perspective of the image provider: additional costs to implement and run software outside EC2
  • From the perspective of the image user, the AWS Credentials are given into the hand of an external provider and its measures to secure the access to the credentials

Known Uses

A couple of companies specialiced on managing EC2 deployments, life-cycle of images, and ease of configuration by providing an alternative web-interface to Amazon EC2 Console. All those companies have in common to store the AWS credentials on behalf of the user in their own database and use it for all operations involving the EC2 API. A list of those companies include RightScale, Enstratus, CloudKick, or Kaavo. Their approach uses the ExternalConsole pattern.

Note: this is work in progress. Any feedback, questions, or corrections is welcome and might be integrated in an updated version. If you use this pattern, let me know!

Filed under: Discussions, Solutions,

EC2 Design Patterns

Design Patterns

Design patterns are an established tool in the design and development of software systems. The basic idea behind is to identify common solutions to well-described and contextualized problems. Ideally, they allow to reuse working solutions to problems in similar contexts and to facilitate communication in a domain via a pattern language. The idea emerged from the work of an architect (Christoph Alexander) and was applied to software development in the late eightees before it gained a lot of traction with the popularity of object oriented programming.

Design patterns for EC2

When I started looking on EC2 – the API, the various existing tools, and the architectural pieces and features Amazon’s cloud infrastructure platform provides – I felt in the same situation as I was when I started developing communication systems in Java. Many other people have already be confronted with the same problem space, seeking for help in forums, and finally cobbling together their own solutions. Unfortunately, it is not easy to benefit from those other people’s work, because their ideas are dispersed over blogs and forums and are not available in a structured form using a common domain language. It is not always obvious to know if someone tried to solve the same problem if the beast gets a different name every time. That’s why I think it would make sense to start collecting solutions on EC2 and transform them into reusable design patterns.

You can find a list of Patterns below. We adhere to the conventions by the GoF. We would be happy to integrate in our series design patterns that you have come across during you work with EC2. You can leave a comment below or use the contact form for a private message here.

Collection of EC2 Patterns

  • ExternalConsole: Give API access to an EC2 instance created from a publically available virtual image (AMI)
  • TrustedGateway: Give API access to an EC2 instance created from a publically available virtual image (AMI) without the help of an external service

Filed under: AWS, Solutions

Cloud Computing Use Cases whitepaper

The Cloud Computing Use Cases group just released the final version of their whitepaper:
http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper

Filed under: Discussions

Twitter Updates

Follow

Get every new post delivered to your Inbox.