Enhancing Kubernetes Security with Integrated Network Policies in Amazon VPC CNI

By default, Kubernetes allows unrestricted communication between pods, potentially exposing your cluster to security risks. Fortunately, Kubernetes Network Policies provide a solution. They function like a virtual firewall, letting you define and enforce rules for pod-to-pod traffic flow.

Network Policies offer granular control by specifying ingress (incoming) and egress (outgoing) traffic rules based on:

• Pod labels
• Namespaces
• IP addresses
• IP blocks (CIDR ranges)
• Ports

Previously, implementing network policies required third-party plugins, introducing management overhead. Thankfully, Amazon VPC CNI now offers integrated network policy functionality, simplifying cluster configuration and deployment.

Restricted traffic flows lead to a more secure cluster posture without compromising scalability. This makes Amazon VPC CNI an attractive option for managing and securing your Kubernetes deployments.

Benefits of Using Network Policies with Amazon VPC CNI:

• Enhanced Security: By restricting traffic flows, you can significantly reduce the attack surface within your cluster, making it more difficult for unauthorized access or lateral movement by malicious actors.
• Simplified Management: The integration of Network Policies within Amazon VPC CNI eliminates the need for third-party plugins, reducing complexity and management overhead.
• Granular Control: Network Policies offer a high degree of granularity, allowing you to define precise rules based on specific pod labels, namespaces, or network addresses.
• Scalability: Network Policies can be applied effectively even in large-scale deployments without compromising performance.

Why are Kubernetes Networking Policies Required?

Traditional networks typically implement firewalls to restrict communication between different segments. However, Kubernetes environments by default allow all pods to communicate freely. This open communication poses several security challenges:

• Security by Default: Unrestricted communication creates a vulnerability, as a compromised pod could exploit access to other pods in the cluster. Network Policies address this by letting you define firewalls for pods, restricting communication based on your security needs.
• Lack of Segmentation: Without Network Policies, your cluster operates as a single, large network. This makes it difficult to isolate pods based on function or application, increasing the attack surface. Network Policies enable logical segmentation, minimizing the potential damage from a security breach.
• Compliance Requirements: Many security regulations and compliance frameworks mandate network segmentation and restricted communication paths. Network Policies provide a way to implement these controls within your Kubernetes environment.

By implementing Network Policies, you can enforce least privilege communication within the cluster, leading to a more secure and controlled environment for your applications.

This revised section first explains what Network Policies are and then dives into the reasons why they are crucial for securing your Kubernetes deployments.

Prerequisites:

To leverage the integrated network policy functionality in Amazon VPC CNI, your environment needs to meet the following minimum requirements:

• Cluster Version: Kubernetes version 1.25 or later (refer to the previous section for checking the version).
• Amazon VPC CNI Version: Version 1.14 or later. The command to check your current version is provided within the article. If you need to upgrade, refer to the instructions for "Updating the Amazon EKS add-on. Amazon EKS documentation: vpc-add-on-update
• Linux Kernel Version: Kernel version 5.10 or later on your cluster nodes. You can verify this with the uname -r command. Using the latest Amazon EKS optimized AMIs (Amazon Linux, accelerated Amazon Linux, and Bottlerocket) is recommended as they typically meet this requirement.

Additional Recommendations:

• Kube-proxy: While not strictly a requirement, it's recommended to use the latest stable version of kube-proxy for optimal performance and security. You can find information on checking and updating kube-proxy in the Amazon EKS documentation managing-kube-proxy

To configure your cluster to use Kubernetes network policies:

1. Enable network policy in the VPC CNI

Using the AWS Management Console:

1. Navigate to your EKS cluster: Log in to the AWS Management Console and access the Amazon EKS service (https://console.aws.amazon.com/eks/home).
2. Select the cluster: In the left navigation pane, choose "Clusters" and then select the specific cluster where you want to enable network policies.
3. Access add-on settings: Locate the "Add-ons" tab and click on it.
4. Edit the VPC CNI add-on: Find the "VPC CNI" add-on and click the checkbox next to it. Then, choose "Edit" from the available options.
5. Configure network policy: On the "Configure" page, select a version number equal to or greater than "v1.14.0-eksbuild.3" from the "Version" dropdown menu.Expand the "Optional configuration settings" section.
6. Inside the "Configuration values" field, enter the following JSON code

{ "enableNetworkPolicy": "true" }        

The following screenshot shows an example of this scenario

2. Confirm that the aws-node pods are running on your cluster.

kubectl get pods -n kube-system | grep 'aws-node\|amazon'        

An example output is as follows.

aws-node-gmqp7                                          2/2     Running   1 (24h ago)   24h
aws-node-prnsh                                          2/2     Running   1 (24h ago)   24h        

Network Policy: demo-app-deny-all

This Kubernetes NetworkPolicy, named "demo-app-deny-all", is designed to restrict all incoming network traffic to pods labeled with "app: demo-app". The policy effectively denies all ingress traffic to pods matching this label selector. This can be useful for isolating specific application components or enforcing strict access controls within a Kubernetes cluster. By defining a policyType of "Ingress", this NetworkPolicy explicitly focuses on regulating incoming traffic, providing a foundational element for securing the "demo-app" workload.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: demo-app-deny-all
spec:
  podSelector:
    matchLabels:
      app: demo-app
  policyTypes:
  - Ingress        

Network Policy: demo-app-allow-another-ns

This Kubernetes NetworkPolicy, named "demo-app-allow-another-ns", facilitates communication between pods labeled with "app: demo-app" and pods residing in another namespace specified by "another-ns". By leveraging the ingress rule, it allows inbound traffic from pods within the selected namespace, thus enabling inter-namespace communication for the designated application components. This policy offers granular control over network traffic, enabling secure and targeted communication across namespaces while maintaining isolation and minimizing potential attack surfaces.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: demo-app-allow-another-ns
spec:
  podSelector:
    matchLabels:
      app: demo-app
  ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: another-ns        

Network Policy: demo-app-allow-samens-client-one

This Kubernetes NetworkPolicy, named "demo-app-allow-samens-client-one", permits inbound traffic to pods labeled with "app: demo-app" specifically from pods labeled with "app: client-one" within the same namespace. By utilizing the ingress rule with a podSelector, it enables communication between designated application components while maintaining strict access controls within the same namespace. This policy enhances security by restricting network traffic to only the necessary communication paths, ensuring that only authorized pods can initiate connections to the "demo-app" pods labeled with "app: client-one".

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: demo-app-allow-samens-client-one
spec:
  podSelector:
    matchLabels:
      app: demo-app
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: client-one        

Network Policy: demo-app-allow-samens

This Kubernetes NetworkPolicy, titled "demo-app-allow-samens," facilitates communication between pods labeled with "app: demo-app" and pods within the default namespace. By leveraging the ingress rule alongside a namespaceSelector, it permits inbound traffic from pods residing in the specified namespace, in this case, the default namespace. This policy streamlines inter-namespace communication for the designated application components, enabling secure interactions across namespaces while maintaining network segmentation and access controls.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: demo-app-allow-samens
spec:
  podSelector:
    matchLabels:
      app: demo-app
  ingress:
  - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: default        

Network Policy: demo-app-deny-all

This Kubernetes NetworkPolicy, named "demo-app-deny-all," enforces strict ingress traffic restrictions for pods labeled with "app: demo-app." By setting the policyType to "Ingress" and not specifying any ingress rules, this policy effectively denies all inbound network traffic to the specified pods. This approach enhances security by implementing a default deny-all rule, ensuring that no unauthorized connections can be established with the "demo-app" pods. It provides a foundational layer of protection for the application components, minimizing potential attack vectors and maintaining network integrity within the Kubernetes cluster.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: demo-app-deny-all
spec:
  podSelector:
    matchLabels:
      app: demo-app
  policyTypes:
  - Ingress        

Network Policy: deny-traffic-for-specific-namespace

This Kubernetes NetworkPolicy named "deny-from-worknamespace" is configured to restrict network traffic to pods within the default namespace. It specifically targets incoming traffic (Ingress) and denies any connections originating from pods within the "worknamespace" namespace.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-from-worknamespace
  namespace: default
spec:
  podSelector: {} #selects all podsin the default namespace
  policyTypes:
  - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: kubernetes.io/metadata.name
              operator: NotIn
              values: ["worknamespace"] #Excludes the worknamespace namespace        

Network Policy: Allow-traffic-from-specific-namespace

This Kubernetes NetworkPolicy named "allow-from-specific-namespace" is designed to control incoming network traffic to pods within the default namespace. It specifies a policy that allows incoming traffic only from pods in specific namespaces: "default", "monitor", and "kube-system".

apiVersion: networking.k8s.io/v1
metadata:
  name: allow-from-specific-namespace
  namespace: default
spec:
  podSelector: {} #selects all podsin the default namespace
  policyTypes:
  - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchExpressions:
            - key: name
              operator: In
              values: ["default", "monitor", "kube-system"]         

For more information about creating NetworkPolicy objects, see Network Policies in the Kubernetes documentation.

Conclusion

Network Policies, combined with Amazon VPC CNI, provide a powerful and efficient way to secure communication within your Kubernetes clusters on Amazon EKS. This approach simplifies deployment and management while offering granular control over pod-to-pod traffic, ultimately leading to a more secure and robust environment for your applications.