TLDR
我们在单个安全组中有很长的 IP 地址列表,很难管理。AWS 让您感觉您可以拥有嵌套组,但您不能。我对吗?
背景
我在配置和使用安全组方面没有任何问题。问题更加微妙,这设置了背景。
我们将安全组配置为对开发实例/服务的访问列入白名单。由于我们的配置模式是白名单,因此我们必须一直添加新的 IP 地址,具体取决于团队成员的工作地点。以及没有静态 IP 地址的蹩脚 ISP。
这不是问题。但是想象一下越来越多的 IP 地址。
问题
有时我们喜欢删除这个白名单(因为糟糕的 ISP),并确保 IP 地址是相关的、最新的并且应该仍然在白名单上。
我们发现自己不愿意这样做,因为目前有效“清理”白名单的唯一方法是分箱并重新开始。
AWS 似乎没有提供一种在安全组规则中标记记录或允许嵌套安全组的简洁方法。
当前的解决方法
拥有大量(可能数百个)独立的安全组,并确保它们始终连接到相关服务。
优点:易于标记/识别 IP 地址(例如 Bob 的家庭 IP),因此 Bob 可以删除旧 IP 地址并替换为新 IP 地址。
缺点:必须将每个安全组附加到相关实例,并且此列表可能会变得很长。
保留单独的 IP/查找列表,并拥有一个安全组
Pro:意味着您只需要一个安全组。
缺点:必须保持两个列表是最新的,这不是很实用,而且会出现不匹配的情况。
某种自动化。构建一个定期检查安全组的服务,并将这些 IP 与一些基本的 geo-ip/ISP 信息一起存储在 DynamoDB 中。用作参考。
优点:与#2 类似,但自动化。不是 100% 准确,因为地理 IP 查找从来都不是。
缺点:必须为感觉应该已经存在的东西编写和维护实用程序。
有希望的解决方案
子/嵌套安全组。AWS 配置界面实际上暗示您可以做到这一点 - 但它没有按预期工作。EG 主安全组具有允许来自其他安全组的入站流量的规则——这些安全组又将 IP 地址逻辑分组在一起。
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
当您将安全组指定为规则的源时,这将允许与源安全组关联的实例访问该安全组中的实例。(请注意,这不会将来自源安全组的规则添加到此安全组。)
我发现该文档有点矛盾。从实验来看,它不起作用。
标记每条记录。这显然不存在,将是 AWS 的功能请求。
我错过了什么吗?其他人如何管理大型安全组?