At CTO2B, network security is a shared responsibility between the CTO2B engineering team and the clients deploying workloads on the managed Kubernetes clusters. While CTO2B provides the underlying infrastructure, VPC design, and default policy enforcement, clients are expected to define fine-grained network policies for their applications to control intra- and inter-service communication securely.
This guide outlines best practices for managing Kubernetes Network Policies on Amazon EKS, helping clients secure workloads running in CTO2B-hosted AWS environments.
A default-deny posture aligns perfectly with the Zero Trust security model — where, by default, no access is allowed unless explicitly granted. This model applies to network traffic, identity and access permissions, and inter-service communications. By denying all traffic and access by default, you drastically reduce the number of potential vectors an attacker could exploit.
Begin by explicitly denying all ingress and egress traffic and then allow traffic as needed:
apiVersion: v1
kind: NetworkPolicy metadata:
name: default-deny
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress Default deny policy:
Network policies should target pod labels, not IPs, for maintainability.
podSelector:
matchLabels:
app: frontend
Use both ingress and egress rules to fully define allowed traffic paths.
policyTypes:
- Ingress
- Egress
EKS supports security groups for pods, allowing you to enforce traffic-level controls at the ENI (Elastic Network Interface) level.
By default, security groups in EKS apply at the node level. This means all pods on a node share the same network security controls. With Security Groups for Pods, AWS lets you associate ENIs (Elastic Network Interfaces) directly with pods, enabling:
aws ec2 create-security-group \
--group-name sg-for-sensitive-pod \
--description "SG for app" \
--vpc-id <your-vpc-id>Add inbound/outbound rules as required, for example:
aws ec2 authorize-security-group-ingress \
--group-id <sg-id> \
--protocol tcp \
--port 443 \
--cidr <source-ip-range>Create a Kubernetes pod-eni annotation in the pod spec or via a Kubernetes :
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
annotations:
k8s.v1.cni.cncf.io/networks: |
[{
"name": "aws-cni",
"interface": "eth0",
"ips": ["<ip-optional>"],
"securityGroups": ["sg-xxxxxxxx"]
}]
spec:
containers:
- name: secure-container
image: nginx
Benefits of Using Security Groups for Pods
| Benefit | Description |
|---|---|
| Fine-grained isolation | Separate front-end, back-end, and sensitive services at network level. |
| Least privilege networking | Only explicitly allowed traffic is permitted to/from each pod. |
| Better auditability | Use VPC Flow Logs and CloudTrail to monitor pod-specific traffic. |
| Compliance support | Helps meet regulations requiring strict segmentation. |