Why won't Boto commands run in UserData when outbound traffic permissions are locked down?

161 views Asked by At

I have a UserData script (in python) in an AWS Launch Configuration that’s associated with an AutoScale group. When new (ubuntu) instances are spun up this script is run on them to do whatever setup is needed.

Until now, I had the security groups configured more loosely. Outbound traffic to anywhere on the internet was allowed from these instances. The UserData script was working fine. But I just shut down that outbound rule to increase security. Now that UserData script randomly won’t execute at all or sometimes when it does execute, it fails. I can see this by examining the /var/log/cloud-init-output.log file. Has anyone seen this behavior? Any suggested solutions?

When the script fails, I can tell that it is failing on certain Boto calls that do network discovery such as boto.vpc.VPCConnection().get_all_vpcs(). It seems reasonable that this would fail if the outbound traffic rules prevent it from querying for this information. But what CIDR and port should I add to the security group rules that will allow Boto to do it's thing?

Below is what my Security Group's Egress rules look like when it doesn't work. The IP addresses are sensitive so I have blacked them out.

enter image description here

Below is what my Security Group's Egress rules look like when it works. As you can see I have allowed it to be open to the entire world. I feel like that's insecure. I want to lock it down.

enter image description here

You can see the /var/log/cloud-init-output.log file here when it fails.

You can see the associated /var/log/cloud-init.log file here.

1

There are 1 answers

0
John Rotenstein On

By default, Security Groups in Amazon EC2 are configured with:

  • No Inbound access
  • Full Outbound access

Inbound access requires the most protection, since this is a vector through which an instance could compromised. Only open the ports that you require, and preferably to a minimal range of IP addresses. For example, port 80 can be opened to the whole Internet, but lock down 22/3389 for SSH/RDP to only IP addresses that you will use.

Outbound access is generally safe to have open, since it will only work with traffic initiated from the instance itself. If you know the instance will only be used for limited purposes, the protocols and IP address range can be reduced.

If you're not happy with keeping the Outbound rules fully open, then you'll have to discover the protocols and IP addresses that are required to let your app function correctly.