问题描述
在使用GitHub Actions部署服务到EC2实例时，当前已经将SSH访问权限开放给所有IP，但希望将访问权限限制为仅允许GitHub Actions运行器使用的IP。然而，默认情况下，AWS限制入站规则为60个IP地址范围，或者可以申请增加到最多1000个范围。而GitHub Actions的IP列表目前约为1900个范围，所以即使将限制增加到1000个也无法满足需求。用户想知道其他人是如何解决这个问题的，是创建多个包含60个不同IP范围的安全组？还是创建包含最多1000个IP范围的较少安全组？或者是动态创建入站规则以适用于特定的运行器IP地址，并在运行完成后删除规则？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
在解决这个问题时，可以考虑以下几种方案：
方案1：动态更新安全组规则
如果GitHub Actions运行器能够获得自己的IP地址，可以通过GitHub Actions的一个步骤，将该IP地址作为输入变量传递给AWS CLI或Terraform命令，以更新应用于目标EC2实例的安全组，然后在任务完成后删除该规则。
以下是一种通过GitHub Actions动态更新安全组规则的步骤示例：
- 创建一个GitHub Actions工作流，用于部署服务到EC2实例。
- 在工作流中的某一步骤，获取GitHub Actions运行器的IP地址。
- 使用AWS CLI或Terraform命令，将这个IP地址添加到适当的安全组的入站规则中，允许SSH访问。
- 在工作流的最后一步中，使用相同的AWS CLI或Terraform命令，删除刚才添加的入站规则，以确保安全组不会保留不必要的规则。
这种方法允许根据实际需要动态更新安全组规则，但需要注意安全性，确保只有GitHub Actions运行器能够触发规则更新操作。
方案2：多个安全组
另一种方法是创建多个安全组，每个安全组包含60个不同的IP范围。这样，你可以将多个安全组分配给EC2实例，以覆盖所需的所有GitHub Actions运行器IP范围。然而，这可能会导致管理上的复杂性增加。
以下是通过创建多个安全组来解决问题的步骤示例：
- 创建多个安全组，每个安全组包含一个或多个允许SSH访问的入站规则。
- 将这些安全组分配给目标EC2实例，以确保涵盖了所有GitHub Actions运行器IP范围。
- 如果GitHub Actions的IP列表发生变化，需要手动更新这些安全组的规则。
这种方法简化了规则更新，但需要管理多个安全组，同时需要考虑每个安全组中的规则数是否超过AWS的限制。
根据实际情况和管理需求，你可以选择合适的方案来满足需求。