Network segmentation and hardening - Architecting for HIPAA Security and Compliance on Amazon EKS

Network segmentation and hardening

For network segmentation and hardening, such as network Routing Control, network Connection Control, and more, you should consider installing and maintaining a firewall to protect PHI data and should ensure that systems be protected from unauthorized access. Firewall, in this context, means inbound and outbound access is restricted to only approved ports and services.

An individual AWS account provides the highest level of segmentation boundary that can be achieved on AWS. By design, all resources provisioned within an AWS account are logically isolated from resources provisioned in other AWS accounts, even within your own AWS Organizations. Consider using an isolated account for HIPAA workloads to establish access segmentation when designing your PHI data protection to run on the AWS Cloud.

Amazon Virtual Private Cloud (Amazon VPC) and subnets provide further logical isolation of HIPAA-related resources. You can deploy a VPC and subnets that meet the Amazon EKS requirements through manual configuration, or by deploying the VPC and subnets using eksctl, or an Amazon EKS provided AWS CloudFormation template. Both eksctl and the AWS CloudFormation template create the VPC and subnets with the required configuration. For more information, see Creating a VPC for your Amazon EKS cluster.

By default, all pod-to-pod communication is allowed within a Kubernetes cluster. Kubernetes network policies provide a mechanism to restrict network traffic not only between pods but also between pods and external services. Kubernetes network policies operate at layers 3 and 4 of the Open Systems Interconnection (OSI) model. Network policies use pod selectors and labels to identify source and destination pods, but can also include IP addresses, port numbers, protocol numbers, or a combination of these.

Network policies can be scoped to namespaces, pods, service accounts, or globally. When policies are scoped to a service account, it associates a set of inbound/outbound rules with that service account. With the proper Kubernetes rule-based access control (RBAC) rules in place, you can prevent teams from overriding these rules, allowing IT security professionals to safely delegate administration of namespaces. When you first provision an EKS cluster, there is no enforcement of network policies. To use network policies, configure the Amazon VPC CNI or an add-on such as Calico.

Within AWS, security groups act as a virtual firewall and provide stateful inspection. You can use security groups to restrict communications by IP address, port, and protocol. It is important to note that, by default, security groups allow all outbound communications. As a result, you should configure outbound connection rules to conform with HIPAA.

Amazon EKS uses Amazon VPC security groups to control the traffic between the Kubernetes control plane and the cluster's worker nodes. Security groups are also used to control the traffic between worker nodes, external IP addresses, and other VPC resources. It is strongly recommended that you use a dedicated security group for each control plane (one for each cluster). The minimum and suggested rules for the control plane and node group security groups can be found in Amazon EKS security group considerations.

To control communication between services that run within the cluster and services that run outside of the cluster, consider security groups for pods, which integrate Amazon EC2 security groups with Kubernetes pods. You can use Amazon EC2 security groups to define rules that allow inbound and outbound network traffic to and from pods that you deploy to nodes running on many Amazon EC2 instance types. For a complete list of supported instances, see Amazon EC2 supported instances and branch network interfaces. Your nodes should be one of the supported instance types. Before deploying security groups for pods, consider the limits and conditions discussed in the Amazon EKS User Guide.

AWS Fargate runs each pod in its own dedicated kernel runtime environment and does not share CPU, memory, storage, or network resources with other pods, which helps ensure improved workload isolation and security. However, because Kubernetes is a single-tenant orchestrator, potential pod-level intercommunication still exists. You should group sensitive workloads that need complete security isolation using separate Amazon EKS clusters.

You can only use security groups for pods with pods running on AWS Fargate if your cluster is 1.18 with version eks.7 or later, 1.19 with version eks.5 or later, or 1.20 or later. Before deploying security groups for pods, consider the limits and conditions discussed in the Amazon EKS User Guide.

Containerized workloads should be grouped based on data sensitivity levels to more easily facilitate network segmentation. Additionally, Kubernetes namespaces allow for resource segmentation inside the Kubernetes cluster with logical isolation from each other. Namespaces provide scope for pods, services, and deployments in the cluster, so that users interacting with one namespace will not see content in another namespace. However, namespaces within the same cluster don't restrict communication between namespaces. You would need network policies for granular control and to restrict such communications between namespaces.

AWS VPC Flow Logs captures metadata about the traffic flowing through a VPC, such as source and destination IP address and port along with accepted/dropped packets. This information could be analyzed to look for suspicious or unusual activity between resources within the VPC, including Pods. However, since the IP addresses of pods frequently change as they are replaced, Flow Logs may not be sufficient on its own. You should reach out to your account team for more information on 3rd party tools which may make it easier to decipher the traffic flows between pods.

It is a best practice to encrypt PHI both at-rest and in-transit. There are multiple methods (or a combination of them) to encrypt data while it is in transit. Traffic exchanged between the following Nitro instance types - C5n, G4, I3en, M5dn, M5n, P3dn, R5dn, and R5n - is automatically encrypted by default. When there's an intermediate hop, like a transit gateway or a load balancer, the traffic is not encrypted. Encryption in transit can also be implemented with a service mesh like App Mesh. AppMesh supports mTLS with X.509 certificates or Envoy's Secret Discovery Service(SDS).

Ingress controllers are a way for you to intelligently route HTTP/S traffic that emanates from outside the cluster to services running inside the cluster. Oftentimes, these Ingresses are fronted by a layer 4 load balancer, like the Classic Load Balancer or the Network Load Balancer (NLB). Encrypted traffic can be terminated at different places within the network, such as at the load balancer, at the ingress resource, or the Pod.

To summarize, consider the following when working to isolate containerized application communications:

  • Isolate pods on separate nodes based on sensitivity of services and isolate HIPAA- related workloads in a separate cluster with a dedicated Security group.

  • Use AWS security groups to limit communication between nodes and control plane and external communications.

  • Implement micro-segmentation with Kubernetes network policies and consider usage of service mesh, Networking and Cryptography library (NaCI) encryption and Container Network Interfaces (CNIs) to limit and secure communications.

  • Implement a network segmentation and tenant isolation network policy. Network policies are similar to AWS security groups in that you can create network ingress and egress rules. Instead of assigning instances to a security group, you assign network policies to pods using pod selectors and labels. For more information, see Configuring your cluster for Kubernetes network policies.

  • Encrypt data in transit using Container Network Interfaces, Service mesh etc. and use Ingress Controllers and Load Balancers to terminate your SSL connection and intelligently route HTTP/S traffic as dictated by your organization's network security policy and regulatory compliance.