安全组白名单适用场景及EKS环境下安全组白名单配置失效问题咨询

1. 何时需要为安全组设置白名单？ #

设置安全组白名单的核心逻辑是最小权限原则——只给资源开放必要的访问权限，避免不必要的暴露。常见的场景包括：

• 保护敏感资源：比如数据库、存储用户隐私数据的服务器，必须严格限制访问来源，不能随便开放给全网（0.0.0.0/0）。
• 跨资源访问控制：当你有多组关联的云资源（比如EKS工作节点和数据库实例），用安全组关联作为白名单，比手动维护一堆IP地址更灵活——后续资源扩容、IP更换时，不用反复修改白名单规则。
• 合规要求：某些行业规范（比如金融、医疗）明确要求必须限制资源的访问范围，设置白名单是满足合规的必要操作。
• 内部系统访问：比如公司的内部管理后台，只允许办公区IP段或者公司内部的资源安全组访问，防止外部人员随意进入。

2. 为什么关联安全组白名单不生效，但显式加IP就可以？ #

这个问题我之前也碰到过类似的坑，结合AWS安全组的工作逻辑和EKS的网络特性，核心原因大概率是Pod流量的源IP对应的网络接口没有被纳入Apple安全组的范围，具体拆解一下：

首先，AWS安全组里“允许安全组A访问安全组B”的规则，本质是放行来自安全组A所关联的所有网络接口的私有IP的流量。而在使用AWS VPC CNI（EKS默认网络插件）的集群中，Pod的网络有个特殊点：

• 每个Pod会从VPC子网获取独立的私有IP，这个IP绑定在工作节点EC2实例的辅助弹性网卡上。
• 默认情况下，这些辅助网卡会继承节点主网卡的安全组（也就是你的Apple安全组），但如果你的CNI配置被修改过，或者创建节点组时没正确指定安全组，辅助网卡可能没关联Apple安全组——这就导致Pod的IP不在Apple安全组的允许范围内，Mango安全组的规则自然不会放行这些流量。

那为什么显式加工作节点的IP就正常？因为不管Pod的流量是用自身IP还是被SNAT成节点主IP（比如kube-proxy的iptables模式），这个节点IP肯定是关联在Apple安全组里的，Mango的规则能识别并放行。

另外，你可以排查几个小细节确认：

• 检查Apple安全组的出站规则：如果不是默认的“允许所有出站流量”，那即使Mango允许Apple，Apple的出站规则若没放行数据库端口（比如TCP 3306）也会失败。不过你加IP能访问，这个可能性较低，但可以快速确认下。
• 查看工作节点的辅助网卡：在AWS控制台找到你的EKS工作节点EC2实例，查看它的辅助弹性网卡，确认这些网卡的安全组是否包含Apple安全组。如果没有，就需要调整VPC CNI的配置，让它给辅助网卡关联Apple安全组。
• 核对安全组规则的端口/协议：确保Mango安全组的入站规则里，允许Apple安全组访问的是数据库实际使用的端口和协议，虽然你加IP能访问说明这个大概率没问题，但再确认一遍更稳妥。

内容的提问来源于stack exchange，提问作者Red Bottle