A member of your operations team who has access to the key leaves so you have to change the key. Or, you need to change the existing key as a matter of some internal security policy.

How do you do it?You

Generate a new keypair

Add the public key to the EC2 instances' <login user's home dir>/.ssh/authorized_keys

Remove the old public key from the same authorized_keys file

Done. The old key is useless now.

This is not actually revocation

Some things to note about AWS keypairs

EC2 metadata for the instance(s) will continue to show the original keypair name it was created with, whatever keys you add or remove from authorized_keys. The original public key may not even exist on the instance anymore, if you have gone through the steps above, but the metadata will still show it. This is because AWS has no way of knowing that you changed the authorized_keys file.

You can upload keys generated by yourself to the AWS console and they will be available for use while launching EC2 instances. Your generated keys have to be RSA keys of 1024, 2048 or 4096 bits.

AWS keypairs are said to be confined to a single region. This is true only if you consider the default state of affairs. You can get around it.

For keys that you generate, you can import them to all the regions you want using the AWS console or the CLI tools.

For keys that AWS generates, you can take the public key from an EC2 instance launched with that key, and import that in a similar manner to all the regions you want. The private key is available for download when you generate the key.

Friday, 27 September 2013

Amazon Web Services is the largest IaaS provider, according to this Gartner report, in terms of compute capacity. AWS also has a wider geographical presence than other similar companies.

AWS offers an option to have a private cloud inside their public
cloud. You can run this as a small personal cloud, or use one of
Amazon's connectivity offerings to connect it securely to your existing
infrastructure. This is an overview of the private cloud options with AWS, followed by an overview of the various connectivity options.

Private Cloud OptionsWhen
you launch a regular EC2 instance, it has a public IP address. It is
always reachable from the public internet whether you want it or not.
You can configure the instance's AWS security group (the inbuilt
firewall) to allow access to specific ports only, but this may not serve
your security needs. You might want traffic to flow only between your
instances and not from the internet.The obvious way to do this is to not have IP addresses which are
reachable from the internet, i.e., use private IP addresses. Which is
exactly what VPC offers.

IP RangesA VPC is
like a private network inside Amazon's cloud where you can create
smaller subnets and instances inside them. While creating a VPC, you'll
need to define the range of IP addresses that the VPC will cover.

SubnetsThe basic unit of a VPC is a subnet - a logical network where you
can create instances, define the range of private IP addresses that the
instances inside it will have and create routing tables to define how
traffic is routed to and from the subnet.

Kinds of Subnets

There are two kinds of subnets you can create inside a VPC

Private : EC2 instances created inside it cannot talk to the internet and vice versa.

Public : EC2 instances created inside it can access the internet and can also be made accessible from the internet.

Private
and public are just names and not inbuilt properties. What actually
makes them "private" and "public" are the routing tables you create and
assign to the subnets. So you must first create the subnets, then create
the tables, assign them to the subnets and finally give them descriptive
names. If you use the VPC wizard, it will do this for you. You can
create multiple subnets of each type.

Communication between a public subnet and the internet

If
you want your instances to access the internet, you have an option of
adding an "internet gateway" to a subnet. The internet gateway here is
an AWS abstraction. You would add this to your public subnet (or
subnets). Once you assign a gateway, you must assign an elastic IP to an
instance inside that subnet. This instance is the one that would be
able to communicate with the outside world.

VPC places a
limit on the number of elastic IPs (5). If you have many instances
which need to access the internet, you would put all of them behind a
single instance with an EIP instead of assigning each an EIP, and use
NAT to access the internet from the "hidden" instances.

Communication between a private and a public subnet

Setting up communication between a private and a public subnet is a straightforward configuration in the routing table.A typical example of using both private and public subnets in a VPC is from the AWS documentation:

Here, the database servers are extra-secure inside a private subnet, while the webservers are in the public subnet, as they have to serve traffic to end users.

The
"private" nature of a VPC is not limited to the network alone.
Inside a VPC, you have the option of launching a regular EC2 instance,
which is a virtual machine on a host shared with other guest VMs. You
can also choose to launch a dedicated instance - which is a truly
dedicated machine used only by your instance, giving you isolation at the hardware level as well. Costs are slightly higher
for dedicated instances.

A VPC lets you setup your own private cloud with
isolation at the hardware and the network levels. I'll explore the
various connectivity options between VPCs and your own datacenter in the
next post.