Using SUSE Linux Enterprise On Demand In An AWS VPC Setup

At long last a more or less comprehensive look at different scenarios of using SUSE Linux Enterprise Server on demand images in an AWS EC2 VPC setup.

Let’s get the easy, for me, part out of the way. If you route all your traffic across a direct link or via VPN tunnel from EC2 through your own data center and then back out to the world at large (the Internet) registration with the SUSE operated update infrastructure is not going to work, sorry. The update infrastructure provides updates to on demand instances only if the network traffic originated from an IP address that can be verified to be from the IP address set Amazon hands out. Given that the routing design through a private data center is most likely due to security concerns and that such a routing configuration allows you to examine the traffic leaving your network more closely there is a solution that will hopefully meet your security requirements.

Update 2017-01-31: A few days ago Amazon announced the broad and general availability of IPv6 capabilities in a VPC. At this time any instance that accesses the SUSE update infrastructure must have an IPv4 address to do so. We are working with Amazon to support IPv6.

Using a NAT Gateway

The VPC NAT Gateway is really the solution to all the VPC problems and eliminates the need to use NAT instances or Proxy servers. NAT gateways have the advantage that they do not present a bottle neck on your network unlike NAT instances can be and they do not require any configuration in the instance as the use of a Proxy does. Also a NAT Gateway can be locked down with relatively little configuration effort to only accept and route traffic to the SUSE update infrastructure and thus you are ensured that the traffic that flows through the configured NAT gateway only reaches trusted servers.

A basic requirement for using the NAT gateway is that you need to have a public subnet be part of your VPC configuration. This may be of concern to you if you fall into the group that has only private VPC subnets that route all traffic through your data center to the outside world. However, consider that you do not have to run anything other than the NAT gateway in the public subnet of your VPC and thus there is really no inbound route, nor any outbound route that you have not configured.

I will make the assumption that you already have a VPC configured and that the VPC has a public subnet. You can get started with a VPC using the Setup Wizard. Note if you use the VPC Setup Wizard and choose a configuration that has a public subnet, as is needed for a NAT gateway you will need an “Elastic IP Allocation ID” to create the VPC.

The first step in setting up your NAT gateway is to allocate an Elastic IP address (EIP). I will show the appropriate commands here, but all actions can be performed using the AWS Web Console.

aws ec2 allocate-address –domain vpc –region THE_EC2_REGION

This returns something like this:

{
“PublicIp”: “203.0.113.0”,
“Domain”: “vpc”,
“AllocationId”: “eipalloc-64d5890a”
}

which is needed when we create the NAT gateway.

aws ec2 create-nat-gateway –subnet-id THE_SUBNET_ID –allocation-id THE_ALLOCATION_ID_FROM_PREVIOUS_STEP –region THE_EC2_REGION

The SUBNET_ID can be obtained using the describe-subnets  command.

With the NAT gateway created lets configure it such that it only handles traffic to the SUSE update infrastructure. The update infrastructure does not depend on DNS, which implies that within your VPC you do not need to ensure that external DNS resolution works. Having access to all region servers is necessary as access to the region servers is non deterministic. Getting the IP addresses is only a pint  away:

pint amazon servers –regionserver

The information returned provides the IP addresses of the region servers and all those should be added to the routing table for the NAT gateway. Use the “describe-route-tables” command for “ec2” and locate the NatGatewayID that was returned from the “create-nat-gateway” command in the previous step. In this block you will find the RouteTableId that is needed to add a route. Before adding the new routes lets get rid of the default route that routes everywhere.

aws ec2 delete-route –route-table-id THE_ROUTE_TABLE_ID_FOR_THE_PUBLIC_SUBNET –destination-cidr-block 0.0.0.0/0 –region THE_EC2_REGION

At this point our NAT gateway will not route any traffic. You can verify this by again querying the routing tables with the “describe-routes” command. Now we want to add the region servers to our NAT gateway:

aws ec2 create-route –route-table-id THE_ROUTE_TABLE_ID_FOR_THE_PUBLIC_SUBNET –nat-gateway-id NAT_GATEWAY_ID –destination-cidr-block IP_ADDRESS_FROM_PINT_OUTPUT/32 –region THE_EC2_REGION

rinse and repeat for each IP address. Now you can decide whether you want to allow traffic to all update servers or only the region local update servers.

pint amazon servers –smt

provides the IP addresses for all update servers in Amazon EC2 and you can create routes for your routing table as you did for the region servers. If you only want to find the update servers in a specific region

pint amazon servers –smt –region THE_EC2_REGION

will deliver that information.

With the NAT gateway configured you can now launch an instance from an on demand SLES image into your private VPC subnet and it will automatically connect to the SUSE update infrastructure. If you fall into the group of people that sends their traffic back through their own data center you might need to do some more network fiddling.

Using a NAT Instance

Conceptually there is nothing really different between using a NAT instance or a NAT gateway. As with the NAT gateway your NAT instance runs in a public subnet of your VPC. The NAT instance however automatically gets an external IP address from the EC2 DHCP infrastructure, while for the NAT Gateway it is necessary to allocate an Elastic IP first. Once the NAT instance is up and running (which by the way takes a bit longer than the creation of a NAT gateway) the setup is basically the same as for the NAT gateway.

Use the “describe-vcps” sub-command for “aws ec2” to describe your VPCs and locate the VpcId that is associated with the VPC you want to use. Use the “describe-subnets” command to get the SubnetId of the Public subnet in your VPC. Last but not least use the “describe-route-tables” command to find the RouteTableId and the GatewayId for the Public subnet of your VPC.

Get rid of the “route to everywhere” rule for the public and private subnets

aws ec2 delete-route –route-table-id THE_ROUTE_TABLE_ID_FOR_THE_PUBLIC_SUBNET –destination-cidr-block 0.0.0.0/0 –region THE_EC2_REGION

aws ec2 delete-route –route-table-id THE_ROUTE_TABLE_ID_FOR_THE_PRIVATE_SUBNET –destination-cidr-block 0.0.0.0/0 –region THE_EC2_REGION

and add the routes specific for the SUSE update infrastructure to the public subnet.

aws ec2 create-route –route-table-id THE_ROUTE_TABLE_ID_FOR_THE_PUBLIC_SUBNET –gateway-id THE_INTERNET_GATEWAY_ID –destination-cidr-block IP_ADDRESS_FROM_PINT_OUTPUT/32 –region THE_EC2_REGION

Now for the private subnet you want to basically do the same thing with the exception that all the routes should point to your NAT instance.

aws ec2 create-route –route-table-id THE_ROUTE_TABLE_ID_FOR_THE_PRIVATE_SUBNET –instance-id THE_INSTANCE_ID_OF_THE_NAT_INSTANCE –destination-cidr-block IP_ADDRESS_FROM_PINT_OUTPUT/32 –region THE_EC2_REGION

With this, traffic can only exit your network to the trusted SUSE update infrastructure servers. Even if an instance were to run in your public subnet, other than the NAT instance there is no way for the traffic to go anywhere else. As far as routing is concerned what happens is that traffic in the public subnet that is destined to the SUSE update infrastructure will hit the Internet Gateway while all other traffic has no place to go. Traffic from the private subnet destined to the SUSE update infrastructure will get routed to the NAT instance, get the NAT treatment, and from there pass through the Internet Gateway. All other traffic will take it’s regular route; presumably stay within the private subnet or go back to your data center.

That’s really pretty much it. As you can see, this is a bit more complicated than the NAT gateway. In addition the disadvantages of a NAT instance vs. a NAT gateway are that you have to maintain the instance yourself. Additionally the NAT instance might present a network bottleneck, and if it ever goes away for some reason you are on the hook to get it back running. When using a NAT gateway the platform takes care of all of this for you and thus the NAT gateway is definitely the way to go.

Using a Proxy

Using a Proxy basically has the same effects than using NAT from a network perspective, i.e. the isolation of resources behind the Proxy from the world at large. As with a NAT instance using a Proxy has the disadvantage that you need to maintain an instance as compared to the NAT gateway. In the case of a Proxy this instance maintenance becomes a bit more interesting as you you are not only responsible for the instance itself but also the Proxy implementation you choose, i.e. the security of the Proxy code itself. If you are using Squid  and there is a security vulnerability you are on the hook to get it updated and the service restarted. With the NAT gateway these problems are all on the shoulders of the framework, i.e. Amazon. Also there exists a network routing issue where the instance behind the Proxy unfortunately gets the metadata of the Proxy instance rather than it’s own metadata. Therefore, until the metadata issue is sorted out in EC2 a setup behind a Proxy only works if the Proxy instance is also a SLES on demand instance.

As with the NAT gateway and the NAT instance you want to have a public subnet in your VPC. Using a Proxy has the advantage, over a NAT instance, that you can use an Elastic Load Balancer  and manage the proxy instance(s) in an Autoscaling Group such that the Proxy does not become a network bottleneck.  A reference implementation describes such a setup.

The process of configuring the routing tables is basically identical to the setup with a NAT instance. The difference is that the target of the traffic from the private subnet is the Proxy server. Implied here is that all your proxy servers need to get a public IP address from EC2. The setup of Squid as a Proxy server is covered in the SLES Administration Guide.

Last but not least using a Proxy server requires changes in the guest, i.e. the instance that is started in the private subnet has to be made aware of the proxy. This somewhat defeats the purpose of automatic registration in that when the instance starts, from a SUSE published image there is no proxy configuration. One has to login, set up the proxy information and then force a new registration cycle. The option exists to inject the proxy information via cloud-init user data. The YaST module that handles proxy configuration has a command line and thus a series of “yast proxy …” commands bundled in a script can do the trick. However, I will not go into the details as this route clearly is way more complicated than it needs to be to get automatic registration with the update infrastructure in a VPC to work.

Public IPs For All

The final option to get all of this to work is to set the VPC up such that all instances get a public IP address. Then with appropriate security group settings one can keep incoming traffic from the world at large out, while allowing traffic form the VPC itself to let machines properly interconnect. However in the end this somewhat defeats the purpose of the “network self management” feature a VPC provides.

The Caveat

Using a NAT gateway, the preferred solution, or a NAT instance only works with the latest images. The image ids can be found with

pint amazon images –active –filter ‘name\!byos’

In Summary

With the introduction of the NAT gateway getting automatic registration to the SUSE update infrastructure to work is only a few commands away and has become really simple while at the same time keeping your network protected from the preying eyes of the world at large.