2

We have a bunch of 50-odd external (non-AWS) servers that we need to whitelist across many (~50) security groups (vpc). Apart from the constraint on the number of rules, adding and removing entries to/from all the groups one by one is a pain.

I tried adding all the external IPs to a separate SG and whitelisting that SG in other SGs but apparently that works only for internal (AWS) instances1.

[1] Can't give access to all servers belonging to a security group in AWS

Is there any other way to achieve this?

Community
  • 1
galactocalypse
  • 133
  • 1
  • 7
  • Listing security group X in a rule in security group Y does nothing with regard to the rules in security group X. The rules in group Y that list group X as the source only apply to traffic initiated by instances in security group X when they try to connect to instances in security group Y. It's not an "include." – Michael - sqlbot Sep 16 '16 at 00:05
  • Yes, I understand. My problem is that you can whitelist public IPs that are members of X in Y. Only private AWS IPs are allowed. I need a way to whitelist multiple public IPs using a single rule. – galactocalypse Sep 16 '16 at 09:44
  • 1
    I think @Tim has the right idea -- what he is saying create a separate security group with these rules and attach it to the appropriate instances -- not include it in their existing security group. [Each instance network interface can be a member of up to 5 security groups](http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html#vpc-limits-security-groups). – Michael - sqlbot Sep 16 '16 at 12:11
  • 1
    *"Only private AWS IPs are allowed."* No. None of the IP addresses and rules in group X are used when you create a rule in group Y with group X as the source. The rule in group Y applies to the instances that are actually members of the actual group X -- group X is attached to the instance directly -- not to be confused with instances whose addresses are listed in rules in group X. The sg-xxxxxxxx identifier becomes a magic list of source interfaces (not IP addresses). This is a bit tricky to express clearly. Apologies for that. – Michael - sqlbot Sep 16 '16 at 12:21
  • Thanks for clarifying that. Makes sense. This should be better documented. Any links you could share that I could circulate within my team? – galactocalypse Sep 16 '16 at 14:40

1 Answers1

3

When you say you "whitelisting that SG in other SGs" what exactly do you mean?

I would simply create a single security group with these rules and assign that security group to all instances. An instance can have multiple security group, and rules are additive in a permissive sense. ie default deny, unless any rule in any security group allows access. You will have to create new instances to change the security groups associated with an EC2 instance, but once it's associated with the groups any changes made are done in real time.

You could also do it with network ACLs, which work at a subnet level. NACLs are like a firewall, they run at the subnet level, though each NACL can apply to multiple subnets. They can add more "deny" rules that apply to all instances in the subnet but can't open up ports that security groups have closed. Remember they're stateless so you need to add incoming and outgoing rules.

Note that the question/answer you linked to is a very specific situation which doesn't apply to you, regarding using private or public IPs. Security groups apply to private EC2 IPs or public IPs. For example I have security groups set up that allow access only by my CDN provider and my home IP address, which are definitely public IPs.

Tim
  • 30,383
  • 6
  • 47
  • 77
  • By whitelisting that SG I mean whitelisting all its members in a target SG on a specific port using a single rule. What you're suggesting will not work for public IPs. I can't use private IPs since the machines are not on AWS. As far as the problem is concerned, it seems identical to the linked question. – galactocalypse Sep 16 '16 at 09:46
  • Network ACLs won't help -- they don't override security groups for "allow" -- only "deny." But creating a separate security group and making the target instances members of this, an additional security group for each of them is the right idea. +1 – Michael - sqlbot Sep 16 '16 at 12:15
  • @Michael-sqlbot I forgot to mention that, I'll add it thanks. – Tim Sep 16 '16 at 19:15