EC2 Design Patterns (2): Trusted Gateway

Second pattern from our series about EC2 Design Patterns.

Intent

Give API access to an EC2 instance created from a publically available virtual image (AMI) without the help of external services or applications.

Motivation

The motivation is the same as for the External Console pattern: a EC2 server instance needs access to the EC2 API for reasons of configuration, automation, or monitoring of other instances. 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.

Applicability

Use TrustedGateway when

  • you want to apply an AMI that needs access to the EC2 API
  • you want to facilitate deployments and especially minimize 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.)
  • you want no other external service to manage your credentials. All credentials should be managed within EC2

Participants

  • Trusted Gateway: EC2 instance that needs the EC2 credentials for configuration or monitoring purpose
  • Controlled Instance(s): virtual instances resulting from AMI instantiation and supposed to be controlled by the Trusted Gateway
  • Admin: a person or organism that deploys the AMI and manages AMI instances
  • Trusted EBS: An instance of Amazon’s elastic block storage that is encrypted and used by the Trusted Gateway

Collaborations

  • Initial Startup
    • The Admin deploys the Trusted Gateway as any other AMI
    • The Admin connects securely (SSH/HTTPS) to the Trusted Gateway and passes the EC2 credentials to the Trusted Gateway
    • The Trusted Gateway stores the EC2 credentials encrypted with any locally stored key-pair
    • The Trusted Gateway connects to the EC2 API and retrieves all relevant information about Controlled Instances to perform his tasks
    • The Trusted Gateway uses the EC2 credentials to encrypt the Trusted EBS storage and store all relevant information needed to perform his tasks
  • Reboot
    • The Trusted Gateway retrieves and decrypts the EC2 credentials stored locally
    • The Trusted Gateway connects to the EC2 API and retrieves all relevant information about Controlled Instances to perform its tasks
  • Recover
    • When the Trusted Gateway instance was completely destroyed (due to termination or a fatal AWS error), a new instance without the stored EC2 credentials is instantiated by the Admin
    • The Admin connects securely (SSH/HTTPS) to the Trusted Gateway, passes the EC2 credentials to the Trusted Gateway, and selects the EBS that was used before
    • The Trusted Gateway stores the EC2 credentials encrypted with any locally stored key-pair
    • The Trusted Gateway recovers by using the information on the Trusted EBS and continues his tasks

Consequences

The Trusted Gateway offers the following benefits:

  • No external service is needed to manage the platform and the security credentials; thus no additional security risk
  • User does not need to intervene when the Trusted Gateway is rebooted (that is in normal operation)

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

  • Initially and for recovery, the user needs to provide the credentials
  • No strong security: the credentials are stored on the instance and encrypted with a key on the machine itself (security by obscurity)

Known Uses

  • An Amazon User wrote a Script to mount EBS at startup that includes that pattern
  • Shlomo Swidler describes a couple of techniques of passing EC2 credentials securely to instances including this pattern (“How to Put AWS Credentials on EC2 Instance”, point 6)

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

3 thoughts on “EC2 Design Patterns (2): Trusted Gateway

    • I fully agree. The TG could not only act as the endpoint for a central management console, but also as an API endpoint for other instances. This makes a lot of sense, since it should take away the pain of dealing with EC2 internals for the other instances. Now is this just a variation of TG, an extension or even a separate design pattern? I would tend to call it a variation with regard to collaboration of the participants, but let me reflect a moment on it…

  1. Pingback: The Crux with the Creds « Elastic Security

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s