It's funny. Been playing with amazon web services quite a bit over the past few weeks and didn't give much attention to security groups. It's only now, after this past weekend have I developed a strong appreciation and respect for them. Some background:
The way amazon operates is quite interesting. All instances get a dynamic internal IP. That IP stays for the duration of that machine being on. If you restart, the IP changes. Now, you can pay for an elastic IP which maps to the instance ... and that never changes. But it's mapped. The instance never really knows anything about it. It always has this internal IP .... 10.10.10.10 one day, reboot, 10.20.10.20 the next ....
Now, security groups. It's one big glorified access list. You have to specify which security group your instance belongs to. Fair enough. By default, it's deny all. You can start opening things up, saying that 0.0.0.0/0 can access your instance on TCP/80. That means the world can get to that instance on port 80.
With me so far?
So what if you wanted to deploy a multi-tier LAMP application to AWS:
2 x web server
2 x application server
2 x mysql ....
How would the security groups look then?
security group 1: web servers
security group 2: application servers
security group 3: database servers
Simple! You then configure your access lists ... right? Sort of. If you want to do it properly, you define that only TCP/80 & TCP/443 are open to 0.0.0.0/0 for security group 1.
Security group 1 should have access to security group 2 on some ports .. like 8080 or 80 or 8443 ....
Security group 2 should have access to security group 3 on some ports ... like 3306 (mysql)
Normal instinct would say, let's put in the IP's of each machine ( 10.20.10.20/32 and 10.10.10.10/32) for example ... well ... in the AWS world, this isn't correct. When you restart your machine, the IP will change and your rules will not be valid.
Now unfortunately, the way to get around this is not available through the AWS management console. The only way I've found so far (limited amount of looking) is to download the ec2 client tools, generate an X509 key pair, and use the tools:
ec2-authorize us-app -P tcp -p 8080 -o us-www
What this does, is says that the security group "us-app" allows the origin "us-www" on TCP/8080
You are defining the policies with other groups. This is great because you can then add new instances into whatever group you want, or restart an instance, and the policies will still be valid.
Hopefully this is of use to someone one day. I'm glad I've stumbled upon it now after some small pain points and not later when the pain points would be much higher ....!
-sd
1 comment:
One definite pain point with security groups is that you can't change an instance's group membership after it's created. Say you put a server in the www group, but decided later you also wanted to run mysql on it, you can't add it to the mysql group afterwards.
Post a Comment