3 ms·
> EC2 has also been this way for ages, but it has also always had security groups. If you open something up on EC2 Classic to 10.0.0.0/0, any other customer wit
by nirvdrum 12y ago
> EC2 has also been this way for ages, but it has also always had security groups. If you open something up on EC2 Classic to 10.0.0.0/0, any other customer within that region will be able to access your services.
Except that's not how anyone did it. You could define rules that used a security group as the source. And since every instance belonged to a default security group, locking down access to other machines you owned was quite trivial -- you only added rules to allow access from that default security group. If you wanted to add subnet rules, that was usually limited to special cases you would have to actively think about.
> Welcome to #SysadminLife ;)
> I do agree that everyone could be clearer about this, Rackspace, Linode, Digital Ocean, and Amazon. A substantial motivation is to keep your inter-VM traffic off the edge routers.
My source of issue was with the grandparent blaming people that get burned by it. As long as the only way to learn this stuff is to get burned by it, it's counterintuitive to blame people for getting burned by it. And in this case, there are measure DigitalOcean could take to make things easier on everyone. E.g., configure the droplets to save and restore iptables rules on shutdown/power-on and lock the instances down by default to only have port 22 publicly exposed.
- justizin 12y ago> Except that's not how anyone did it. I can affirmatively tell you that more than one of my employers, successful startups several years in, _did_ do this when I started. Anyway, I don't blame people that get burned by this, very little in hosting is obvious. That's a great example of why people need skilled ops help. Understanding how one computer connected to a cablemodem works and understanding what happens inside of a datacenter are very different things.