Profile Applicability:
 • Level 1

Description:
 There are various CNI (Container Network Interface) plugins available for Kubernetes clusters. If the CNI plugin in use does not support network policies, it may not be possible to effectively manage and restrict traffic within the cluster. Network policies are a core component of Kubernetes security, and ensuring that the CNI plugin supports both ingress and egress network policies is crucial.

Rationale:
 Kubernetes network policies are implemented and enforced by the CNI plugin in use. Without network policy support from the CNI plugin, it becomes challenging to control and restrict traffic flows, potentially exposing the cluster to unauthorized access or malicious activities. Ensuring that the CNI plugin supports network policies allows the cluster to follow a least-privileged access model, improving security.

Impact:
 Pros:

  • Enables granular control over traffic flow within the cluster.

  • Increases security by restricting unwanted network traffic based on policies.

  • Provides the ability to enforce isolation between pods and namespaces.

Cons:

  • Not all CNI plugins natively support network policies. Switching to a compatible CNI plugin may require additional configuration.

Default Value:
 This depends on the CNI plugin in use. Some CNI plugins, such as Calico, support network policies, while others like Flannel do not unless combined with additional tools.

Pre-requisites:

  • Access to the cluster’s configuration to determine which CNI plugin is in use.

  • Review of documentation for the CNI plugin to confirm support for network policies.

Remediation

Test Plan:

Using AWS Console:

  1. Review the CNI plugin in use in the EKS cluster.

  2. Check the documentation for the CNI plugin to ensure it supports both ingress and egress network policies.

  3. Verify that the CNI plugin can be configured to enforce network policies.

Using AWS CLI:

  1. To check the CNI plugin in use, run the following command:

kubectl get pods -n kube-system -l k8s-app=aws-node -o yaml

  1. Review the output for the CNI plugin being used, and check if the plugin supports network policies (e.g., Calico, Cilium, etc.).

  2. Confirm that the necessary configuration is in place to enable network policies.

Implementation Plan

Using AWS Console:

  1. If the CNI plugin does not support network policies, consider switching to a plugin that does, such as Calico or Cilium.

  2. For EKS clusters using the default CNI plugin (Amazon VPC CNI), ensure that Calico or another supported CNI is installed for network policy enforcement.

Using AWS CLI:

  1. If the CNI plugin is compatible with network policies, configure the cluster’s network policy settings.

  2. If using Calico, ensure that Calico is configured to enforce both ingress and egress policies.

  3. To install Calico (if not already installed), you can use the following:

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

    4. After installation, create a default deny-all network policy for namespaces

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: <namespace>
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

5. Apply the policy

kubectl apply -f default-deny-all.yaml

Backout Plan

Using AWS Console:

  1. If enabling network policies causes issues, remove the policy configurations or switch back to a previous CNI plugin that does not use network policies (if possible).

  2. Revert the cluster back to its original network settings.

Using AWS CLI:

  1. If the new CNI plugin causes issues, uninstall or revert to the previous plugin.

  2. Remove any created network policies if they cause disruptions.

References:

  1. Kubernetes CNI Plugins
  2. Calico Documentation
  3. CIS EKS Benchmark v1.6.0