Lecture 247: Security Group in EKS - Node and Pod level
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：10:42
- 来源：Udemy Lecture 35813150
- Slide 数量：7
- 画面切换：00:55、03:22、04:48、06:08、07:11、09:18
扫描说明
逐条读取了 Transcript 面板中的 230 条英文 cue，并按播放器进度同步全长约 10:42 的视频。依据 SG/ENI 基础、EKS Cluster SG、Custom SG、Node-level SG Problem、NetworkPolicy、Trunk/Branch ENI、Compatibility Notes 划分为 7 个小节。7 张截图来自真实课程 Slide，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. Security Group 绑定 ENI，普通 Pod 默认继承 Node ENI 的边界
时间范围：00:00–00:55
总结 / Summary
中文
AWS Security Group 关联在 ENI 上，而不是任意 IP Object 上。经典 VPC CNI IPv4 模式中，多个 Pod 只使用同一 Node ENI 的 Secondary IP，因此这些 Pod 共同受该 ENI/Node Security Group 规则约束；无法仅凭 Secondary IP 给每个普通 Pod 单独绑定 SG。EKS 又包含 Control-plane ENI、Node Primary/Secondary ENI 与 Pod Flow，排障时必须先定位 Packet 实际经过哪块 ENI、哪组 SG、方向是 Inbound 还是 Outbound。
English
AWS security groups attach to ENIs, not arbitrary IP objects. In classic VPC CNI IPv4 mode, multiple pods use secondary addresses on the same node ENI, so they share that ENI or node security-group boundary; a security group cannot be attached independently to each ordinary secondary pod address. EKS also involves control-plane ENIs, node primary and secondary ENIs, and pod flows, so troubleshooting begins by identifying the ENI, attached security groups, and inbound or outbound direction traversed by the packet.
Transcript
00:00 Hello and welcome to this lecture,
00:02 Security Groups in EKS.
00:04 Now this is also one of the important topics
00:07 with respect to the exam because you should understand
00:10 how the security group works
00:11 when it comes to the EKS nodes or pods, right?
00:15 And it essentially works a little differently
00:18 because you know that on one node you have multiple pods,
00:23 but, so far what you might have learned
00:25 that the security groups are attached
00:28 to the Elastic Network Interfaces.
00:30 And now we are assigning the multiple IP addresses
00:34 from the same ENIs to multiple pods,
00:36 which essentially means that all those pods
00:39 should be following the rules from the security group
00:42 which is attached to the corresponding ENIs, right?
00:46 Now, with respect to that, let's understand how it works,
00:50 what's the problem, and then how could you solve
00:52 some of those problems.
00:54 Okay.
2. EKS 自动创建 Cluster Security Group，并关联 Cluster ENI 与 Managed Node
时间范围：00:55–03:22
总结 / Summary
中文
创建 Cluster 时，EKS 创建 Cluster Security Group（CSG）：默认 Inbound 允许来自自身 SG 的 All Traffic，Outbound 允许全部 IPv4/IPv6。CSG 关联 EKS-owned Control-plane ENI，也会关联 Managed Node Group Node ENI，使 Control Plane、kubelet 与 Node/Pod 基础通信可建立。若收紧 Egress，课程给出的最小参考是到 CSG 的 TCP 443（Kubernetes API）、TCP 10250（kubelet）以及 TCP/UDP 53（DNS）；实际还需为 Inter-node、ECR/S3、STS、CloudWatch、Package Repository 与 Application Dependency 增加规则或 VPC Endpoint。
English
When a cluster is created, EKS creates a cluster security group. It initially allows all inbound traffic from itself and all outbound IPv4 and IPv6 traffic. The CSG attaches to EKS-owned control-plane ENIs and to managed-node-group node ENIs, enabling baseline control-plane, kubelet, node, and pod communication. If egress is tightened, the lecture's minimum reference is TCP 443 for the Kubernetes API, TCP 10250 for kubelet, and TCP or UDP 53 for DNS to the CSG. Real clusters also need rules or VPC endpoints for inter-node traffic, ECR and S3, STS, CloudWatch, package repositories, and application dependencies.
Transcript
00:55 So this is the diagram that now you should be familiar with.
00:59 You have the EKS Control Plane in the AWS Managed VPC,
01:03 and then EKS Data Plane in the Customer Managed VPC.
01:07 For management of the network, EKS provisions,
01:11 EKS owned ENI in the customer VPC.
01:14 So that Control Plane can communicate
01:15 with the Data Plane. Right.
01:18 Okay. Now, when it comes to the EKS cluster,
01:20 when you create the EKS cluster,
01:22 it also creates the security groups.
01:24 And these security groups have some default rules.
01:28 You know that security group contains
01:29 inbound and outbound rules.
01:31 So by default, all the inbound rules
01:34 are allowed for the self.
01:36 That means, whichever entity would have
01:38 that security group attached,
01:40 all the traffic between those will be allowed.
01:43 And as an outbound rules, the destination for all
01:47 IPv4 addresses and IPv6 addresses is allowed.
01:51 Now, this is a default security group which EKS creates,
01:55 and what it does it also associates the security group with,
01:59 of course, the EKS owned ENI,
02:02 and also the managed nodes in the managed node groups.
02:06 So it attaches this default security group to these ENIs.
02:11 Now this works well, however, for security reasons,
02:15 you might want to restrict the outbound traffic, right?
02:19 You don't want to allow outbound traffic from these ENIs
02:22 to any IPv4 or IPv6 addresses.
02:25 So at bare minimum, what you can do is,
02:27 you can restrict the outbound access to port 443.
02:31 Now this is required to hit the API server
02:35 of the Kubernetes,
02:36 and that's where this 443 port is required.
02:39 10250 is required for the kubelet APIs.
02:43 So you know that the Control Plane also communicates
02:45 with the kubelets on the worker nodes,
02:48 so it listens at this port.
02:50 So also outbound traffic for this port is required
02:53 and 53s for DNS queries.
02:55 So bare minimum, these outbound ports are required.
02:59 And if your node and port needs to communicate to,
03:03 for example, to the internet directly,
03:05 or you know, download some packages,
03:07 in that case, you might need port 80 as an outbound.
03:10 So all those rules apply if you want to extend
03:13 the connectivity beyond, you know, EKS cluster.
03:16 So, this is a default behavior when it comes
03:19 to the security group of EKS cluster.
3. Additional Cluster SG 只自动关联 Control-plane ENI，Node SG 需单独管理
时间范围：03:22–04:48
总结 / Summary
中文
CreateCluster 时可通过 VPC Config 提供 Additional Security Group；EKS 把它关联到 Cluster/EKS-owned ENI，但不会因此自动把同一 Additional SG 关联到 Managed Node Group。Node Group/Launch Template 必须单独配置 Node SG，并确保与 CSG 之间允许必要 Flow。EKS 为维持 Cluster 可用性，可能在 Update 时重新加入被删除的 CSG Self-inbound Rule；Outbound Rule 则由用户负责。收紧前应建立 Flow Logs、Connectivity Test 与 Rollback，避免 Node Join、Webhook、DNS 或 Image Pull 被误封。
English
An additional security group may be supplied in the cluster VPC configuration. EKS attaches it to cluster or EKS-owned ENIs, but does not automatically attach that additional group to managed-node-group ENIs. Node groups or launch templates must configure node security groups separately and permit required flows with the CSG. To preserve cluster operation, EKS can re-add a deleted CSG self-referencing inbound rule during updates, while outbound rules remain the user's responsibility. Tightening should use flow logs, connectivity tests, and rollback planning to avoid breaking node join, webhooks, DNS, or image pulls.
Transcript
03:22 Okay. And optionally, what you can also do is
03:24 you could have your own security group,
03:26 and when creating the EKS cluster,
03:28 you may provide that security group as one of the input,
03:32 and then EKS will also attach that security group
03:35 to the EKS owned ENIs.
03:38 But EKS doesn't attach it to the Managed Node group ENIs
03:42 if you provide your own security group.
03:44 One thing to also understand that these inbound rules
03:47 are very much required for EKS to function.
03:51 And by chance, if you remove all these inbound rules
03:55 from the security group,
03:57 then whenever EKS updates itself,
03:59 it will re-add this inbound rule into the EKS security group
04:04 because it needs that to function.
04:07 Similarly for outbound rules, this is under your control.
04:11 And as we said, at bare minimum,
04:13 you require few outbound rules here, which are listed here.
04:16 And additional outbound rules like
04:18 node to node communication,
04:19 talking to the S3 or VPS interfaces,
04:22 or maybe for pulling the {indistinct} images from outside.
04:26 But at bare minimum, these rules are required,
04:29 and you should always test, right,
04:32 whether your ports and EKS is working fine
04:35 by removing the outbound rules.
04:38 And those are not automatically added
04:40 because EKS doesn't understand what rules you need
04:43 into your security groups.
04:44 So these are few things that you need to keep in mind.
4. Node-level SG 粒度不足：同 ENI 上的 Web、App、DB Pod 被迫共享规则
时间范围：04:48–06:08
总结 / Summary
中文
Primary/Secondary ENI 上的 SG 会覆盖使用其 Secondary IP 的所有普通 Pod。若同一 Node 混合 Web、Application、Database 等不同 Trust Zone，就无法在 Node SG 层对每个 Pod 设置独立 Port/CIDR Rule；放宽给一个 Workload 的访问面会连带暴露同 ENI 的其他 Workload。可以通过 Node Group/Placement 把 Workload 分层，但会降低 Scheduling Flexibility 与 Utilization。更细粒度控制需要 Kubernetes NetworkPolicy 或 AWS Security Groups for Pods。
English
A security group on a primary or secondary ENI covers all ordinary pods using that ENI's secondary addresses. If one node mixes web, application, and database workloads from different trust zones, node security groups cannot assign independent port or CIDR rules to each pod; access opened for one workload also affects others on the same ENI. Workloads can be separated into node groups or placement domains, but that reduces scheduling flexibility and utilization. Finer-grained control requires Kubernetes NetworkPolicy or AWS security groups for pods.
Transcript
04:48 Okay, with that, let's move to the next part of it.
04:51 What is the problem here, right?
04:52 So, you have Worker Node,
04:54 you have Primary ENIs and Secondary ENIs,
04:57 you attach it to the node, and then, as you know,
04:59 the secondary IPs from the ENIs are assigned to the pods.
05:03 This works well, right?
05:05 Now, when it comes to the SG,
05:07 these are attached to the ENIs, not to the individual pods,
05:11 because security group works at the ENI level.
05:13 You know that already.
05:15 Due to that, what happens,
05:16 there will be two security groups,
05:18 either same security group you can attach to the two ENIs,
05:21 or maybe you want different rules in this security groups.
05:24 So you would have two different security groups here.
05:28 Now do you see some problem here?
05:30 Of course, because now all these ports
05:32 might have different purpose,
05:35 some may be a web server, some may be database,
05:38 some may be application server, and every service
05:41 would have different kind of firewall requirements.
05:44 But, if you are using this kind of setup,
05:47 which means that all these ports
05:49 will have the same firewall rules, right?
05:51 And that's a drawback.
05:53 Ideally, what you would want is every port
05:56 gets their own security group or their own firewall
05:59 so that you can have the granular control
06:01 over inbound and outbound traffic from that Pod.
06:03 But with this architecture, it is not possible.
06:06 So what's the solution there?
5. NetworkPolicy 控制 Kubernetes East-West Flow，与 AWS SG 层互补
时间范围：06:08–07:11
总结 / Summary
中文
Calico 等 NetworkPolicy Engine 可依据 Namespace、Pod Label、Port 与 CIDR 控制 Ingress/Egress，让 Policy 跟随 Workload 而不是 Node。课程用 iptables 解释实现；现代 Plugin 也可能使用 eBPF 等 Data Plane，语义应以所选 CNI/Policy Engine 为准。NetworkPolicy 适合 Kubernetes-native East-West Segmentation，但不等同于 VPC SG：它通常不直接复用 SG Reference、VPC Flow Log Identity 或 AWS-managed Resource Integration。两层可组合使用，但 Flow 必须同时被两层允许。
English
Network-policy engines such as Calico control ingress and egress by namespace, pod label, port, and CIDR, so policy follows the workload rather than the node. The lecture explains an iptables implementation, while modern plugins may use eBPF or another data plane; semantics should follow the selected CNI or policy engine. NetworkPolicy provides Kubernetes-native east-west segmentation but is not the same as a VPC security group: it generally does not directly reuse SG references, VPC Flow Log identity, or AWS-managed-resource integration. Both layers can be combined, and a flow must be permitted by each applicable layer.
Transcript
06:08 Now, Kubernetes is an extensible framework as you know,
06:12 and there are a lot of third party providers
06:14 who have implemented their own CNI plugins,
06:16 and they're building the network policies
06:19 on top of that plugin.
06:21 One such policy engine is Calico network from Tigera.
06:25 We had briefly touched about this
06:27 in earlier lecture, as well.
06:29 So Calico provides you the network policies
06:31 with which you can control basically the firewall
06:35 at the port level, right?
06:36 Not at the node level or the ENI level.
06:39 And it does that using the IP table rules.
06:42 So this is what you can do
06:44 if you're using external policy engine like Calico.
06:47 But if you want to do this natively with the EKS,
06:51 then EKS provides a functionality called
06:54 Trunk and Branch ENIs.
06:56 Now, let's try to understand in the next slide
06:58 what is Trunk and Branch ENIs, but essentially,
07:01 idea is to give or provide the security group
07:05 to individual port, rather than sharing the security group
07:09 across multiple ports, right?
6. Security Groups for Pods：Trunk ENI 承载 Branch ENI，并把 SG 赋给选中的 Pod
时间范围：07:11–09:18
总结 / Summary
中文
启用 Amazon VPC CNI 的 ENABLE_POD_ENI=true 后，EKS VPC Resource Controller 会在兼容 Node 上创建 Trunk ENI；匹配 SecurityGroupPolicy 的 Pod 获得 Branch ENI/Private IP，并把指定 SG 关联到该 Branch ENI。于是 Selected Pod 可拥有独立于 Node/其他 Pod 的 VPC Firewall Identity。并非每个 Pod 都自动占用 Branch ENI，只有被 Policy 选择且成功调度的 Pod 使用；Branch ENI Quota 与 Instance Trunking Limit 会影响 Pod Density。Node SG 与 Pod SG 的实际组合/Flow Path 还取决于 VPC CNI 版本和 POD_SECURITY_GROUP_ENFORCING_MODE。
English
After Amazon VPC CNI sets ENABLE_POD_ENI=true, the EKS VPC resource controller creates a trunk ENI on compatible nodes. Pods selected by a SecurityGroupPolicy receive a branch ENI and private address, and the specified security groups attach to that branch ENI. Selected pods therefore gain VPC firewall identities separate from the node and other pods. Not every pod automatically consumes a branch ENI; only selected, successfully scheduled pods do. Branch-ENI quotas and instance trunking limits affect pod density. The interaction between node and pod security groups also depends on VPC CNI version and POD_SECURITY_GROUP_ENFORCING_MODE.
Transcript
07:11 So what is Trunk and Branch ENI?
07:13 Basically, Amazon EKS and ECS supports
07:15 Trunk and Branch ENI feature.
07:18 We are not really getting too deep into what is
07:21 trunk ENI, branch ENI.
07:22 This is a networking concept very similar
07:24 to how you have one network and subdivide that network
07:28 into secondary networks.
07:31 And how it is done for this trunk ENIs and branch ENIs,
07:34 you have to have the add-on added to your EKS,
07:39 and that add-on is Amazon-vpc-resource-controller-k8s,
07:42 and it manages this trunk and branch network interfaces.
07:46 So what happens when you enable the Pod ENI feature to true,
07:50 and there is a command to do that in Kubernetes,
07:53 this VPC resource controller will create
07:56 a special network interface called trunk network interface,
08:00 and then it will attaches it to the node.
08:02 So very similar to the standard interfaces that you create
08:06 and attach to the node, but this is called trunk ENI.
08:10 And the benefit is, once you create the trunk ENI,
08:14 you can create now something called branch ENI.
08:16 So this is like a tree. Tree has a trunk
08:18 and then multiple branches.
08:20 So this is a trunk ENI, and then you can create
08:22 multiple branch ENIs on top of this trunk ENIs,
08:26 something like this.
08:27 And every ENI would have their private IP addresses,
08:30 as we have seen.
08:31 So these are the same ENIs that you attached to the nodes,
08:35 but the benefit is,
08:37 these ENIs you can directly attach to the Pod, right?
08:40 Earlier it wasn't possible, they were attached to the node.
08:43 So you can create now branch ENIs
08:45 which are connected to the trunk ENIs.
08:48 Now if you look at the Pod distribution here, now,
08:51 you have this worker node,
08:53 you have primary ENI on top of it,
08:55 you create the trunk ENI,
08:57 and then you create multiple branch ENIs,
09:00 because now every pod has their own ENI.
09:04 Of course, you can apply the security group per pod now,
09:08 because we know that the SGs are assigned to the,
09:12 or associated to the ENIs.
09:14 So this is a solution where security groups can be used
09:16 at the Pod level.
7. Compatibility 与 Operational Caveat 必须核对当前 EKS/VPC CNI Support Matrix
时间范围：09:18–10:42
总结 / Summary
中文
本讲录制时的限制包括：Security Groups for Pods 不支持 Windows Node；IPv6 Cluster 仅在 Fargate 路径支持；EC2 需使用 Trunking-compatible Nitro Instance，部分 T Family 不在范围内，可在 VPC CNI limits.go/AWS Support Matrix 检查 IsTrunkingCompatible。这些属于会随版本变化的状态型结论，实施前应核对当前 Region、Kubernetes/EKS Version、VPC CNI Version、AMI、Instance Type 与 Fargate Support。启用前还应评估 Branch ENI/IP Capacity、Startup Latency、Health Check、SNAT/Client IP 行为和 NetworkPolicy Interactions。
English
At recording time, the lecture lists these limitations: security groups for pods do not support Windows nodes; IPv6 clusters support the feature only through Fargate; and EC2 requires trunking-compatible Nitro instances, with some T-family types excluded. Compatibility can be inspected in VPC CNI limits.go or the AWS support matrix through IsTrunkingCompatible. These stateful limitations can change, so verify the current region, Kubernetes and EKS version, VPC CNI version, AMI, instance type, and Fargate support. Also evaluate branch-ENI and IP capacity, startup latency, health checks, SNAT and client-IP behavior, and NetworkPolicy interactions.
Transcript
09:18 Okay, few things to just note
09:20 that this cannot be used with Windows nodes as of now.
09:24 And if you're using IPv6 address family,
09:27 then this feature is only available for Fargate,
09:30 not available for EC2 Node,
09:32 typically supported by the nitro-based systems only.
09:35 And in that, also some of the instance families,
09:38 like t families, are not included.
09:40 And if you want to really check which type of
09:43 the instance supports the trunk and branch ENIs,
09:47 then there is a GitHub link
09:49 and there is a file called limits.go
09:52 in that you can see list of
09:54 all {indistinct} instances and corresponding flag,
09:57 which say "is trunking compatible."
09:58 If it is true, then only that type of the instance family
10:03 would support the trunking and branching of the ENIs.
10:07 Okay, with that, just understand that EKS supports
10:11 the security group, typically it attached to the nodes,
10:14 but that's a problem, because then all ports
10:17 would have to use the same security group.
10:19 One of the solution is to use third party solution
10:22 like Calico network policies.
10:23 But if you want to do it natively using EKS,
10:26 then you can use trunk and branch ENI feature,
10:29 where every port gets their own ENI,
10:31 and then you can have different security groups
10:33 attached to those ENIs.
10:35 Okay, so I hope that's clear and that's it for this lecture.
10:38 And now we'll get into the next lecture.
10:40 Thanks for watching.
整讲总结 / Overall Summary
中文
EKS Security Group 设计有三层：Cluster SG 保障 Control Plane 与 Managed Node 基础通信；普通 Pod 默认继承 Node ENI SG，粒度是 ENI/Node；需要 Per-Pod VPC Firewall 时，可通过 SecurityGroupPolicy、Trunk ENI 与 Branch ENI 为选中的 Pod 关联 SG。NetworkPolicy 则提供 Kubernetes-native Label/Namespace Segmentation。实际规则与兼容性必须结合当前 VPC CNI Enforcement Mode、Quota 和 Support Matrix 验证。
English
EKS security-group design has three layers: the cluster security group supports baseline control-plane and managed-node communication; ordinary pods inherit node-ENI security groups at ENI or node granularity; and selected pods can receive per-pod VPC firewall identities through SecurityGroupPolicy, trunk ENIs, and branch ENIs. NetworkPolicy provides Kubernetes-native label and namespace segmentation. Actual rule behavior and compatibility must be verified against the current VPC CNI enforcement mode, quotas, and support matrix.