Turnkey Network Security and Continuous Compliance for Your Amazon EKS Cluster

By Vince Lau, Director of Product Marketing at Tigera
By Carmen Puccio, Principal Solutions Architect at AWS

As customers look to modernize their applications, many have turned to containers because of the benefits containerized workloads bring to their organization. They look to achieve things like environmental consistency, developer productivity, and operational efficiency, to name a few.

By leveraging containers, customers quickly realize their applications can deploy not only in a rapid manner but also in a reliable manner regardless of the environment. Customers are also turning to Kubernetes since it allows them to automate deployment, scaling, and management of their workloads.

When Amazon Web Services (AWS) released Amazon Elastic Container Service for Kubernetes (Amazon EKS), it allowed customers to focus more on their applications because they no longer needed to stand up or maintain their own Kubernetes control plane. Amazon EKS removes the pain of managing cluster operations and administration tasks by ensuring management infrastructure is properly provisioned, highly available, backed up, and updated.

Customers were also excited that Amazon EKS ensures their infrastructure is secure because the communication channels are automatically set up between your worker nodes and the managed control plane using encryption.

While a managed Kubernetes offering provides a tremendous business advantage for time-to-market when deploying new applications, customers still need to think about securing their applications. Implementing Kubernetes clusters on AWS is now easy, and enabling security and auditing all the way down to the application level should be the same. DevOps and security teams must work together by using integrated Amazon EKS tools during implementation to ensure this crucial step is in the front of an application design and not an afterthought.

In this post, we explore how AWS Partner Network (APN) Advanced Technology Partner Tigera and their Tigera Secure Cloud Edition (CE) helps ensure your containerized applications running in Kubernetes are secure and auditable.

Microservices Churn: A New Attack Surface

Microservices and containers have moving parts and new security implications, particularly around East-West network traffic and the potential for lateral movement. The microservices and containers that comprise a cloud-native application architecture are dynamic and have a much larger attack surface. Containerized architectures generate exponentially greater network churn when compared to traditional or VM-based architectures, and that churn is driven by two factors: container proliferation and container lifespan.

• Container Proliferation: Monolithic and VM-based applications are relatively stable with few instances to protect, while containerized applications use many more instances. A recent survey of Docker deployments showed a median of 10 containers per host. However, some users went up to 95 containers per host. Ten containers per host means 10x the number of instances that IT security needs to watch compared to a monolithic application.

• Container Lifespan: Containers and microservices-based applications running in containers are dynamic and usually ephemeral. For organizations running Docker, the typical lifetime of a container is less than a day. Compare that to traditional and cloud-based VMs that have an average lifespan of 23 days. This translates into around 25x shorter lifespan.

When you combine 10x instances with a 25x shorter lifespan, for example, you get 250x more network churn. This means 250x the number of workloads being created, IP addresses being dynamically assigned and advertised, workloads being destroyed, and IP addresses being recycled.

Automating EKS Network Security and Continuous Auditing

Traditional security solutions that grew up with less dynamic infrastructure need to learn how to adapt to the dramatically more dynamic Kubernetes and Amazon EKS ecosystem. IT security strives to protect this new attack surface by controlling lateral movement while dynamically enforcing policy to meet security and compliance mandates. Traditional IT security approaches using custom automation and manual firewall provisioning were designed for an era before Kubernetes and Amazon EKS.

Solutions like perimeter security, static firewall rules, and network locality models like micro-segmentation are inadequate and can leave security holes, particularly in conventional security mechanisms originally designed for the VM generation fall short. The underlying network, workloads, and the rest of the infrastructure have to be assumed to be potentially compromised and untrustworthy, as every container needs to be protected from the network and every host has to be protected from containers running on it.

Given the containers themselves are very dynamic with a short lifespan, approaches have to be dynamic and enable changes to security policies that instantly ripple through a system. Every device, user, and network flow must be authenticated and authorized. All data flowing between microservices has to be encrypted. Policies must be dynamic and calculated from as many sources of data as possible.

Tigera Secure Cloud Edition

Tigera Secure Cloud Edition (CE) was designed from the ground up to manage microservices and container churn. The solution provides container-optimized security built on Zero Trust Network Security to defend against lateral movement threats for modern applications running in Amazon EKS. Tigera Secure CE provides security and compliance controls for public cloud-based application deployments with the following four major functionalities.

AWS Security Groups and Kubernetes Policy Integration

Your Kubernetes pods may need to communicate with other resources in your Amazon Virtual Private Cloud (Amazon VPC), like Amazon Relational Database Service (Amazon RDS) or Amazon Machine Images (AMI). AWS Security Groups is the standard approach to network security for Amazon VPC resources, while Kubernetes Network Policy is the model for Kubernetes workloads.

When deploying Kubernetes on AWS, all Kubernetes pods have the same Security Groups as the host/node they are on (and vice-versa). Additionally, a Kubernetes policy is not aware of non-Kubernetes workloads or Security Groups. Tigera Secure CE provides you with a more fine-grained policy control. All namespaces, service accounts, and pods can be added to a list of Security Group IDs, enabling you to define which Security Groups are applied to which pods with an Role-Based Access Control (RBAC) model. This capability lets you to use Kubernetes Network Policy in conjunction with Security Groups to secure the entire application with a universal approach to security policy.

Figure 1 – Fine-grain access control for all resources inside your VPC.

Network Monitoring with Workload Metadata

Traditional network logging methods do not capture denied traffic at the container level. These dated methods only capture limited 5-tuple flow logs that require additional context and correlation. Tigera Secure CE solves both of these issues by capturing at the container level and appending workload metadata to the flow logs. The solution also integrates with existing security operations center threat analytic and log aggregation systems.

For Kubernetes environments like Amazon EKS, bi-directional flow logs are generated for all pods as well as host connections and include workload identity as well as pod and host labels. By default, flow logs are sent to a specified Amazon CloudWatch group.

Figure 2 – Tigera flow logs provide insight beyond traditional 5-tuple flow log data.

Suspicious Activity Identification

Tigera Secure CE provides network visibility and compliance monitoring, and monitors the network for illegitimate traffic while identifying indicators of compromise (IoC). These incidents are optionally integrated with a security incident and event management (SIEM) solution or a threat analytics platform for further analysis and enrichment by a security analyst. Network Flow and Change Logs simplify troubleshooting and provide the data required for PCI, HIPPAA, GDPR, and other compliance frameworks.

Figure 3 – Gain visibility for your security and compliance teams.

Automated Encryption

A critical compliance requirement is to encrypt all data in motion. Tigera Secure CE enables you to meet this requirement using host to host encryption. All traffic within and between clusters is encrypted.

Figure 4 – All pod-to-pod traffic is IPSEC encrypted between host and nodes.

Try Tigera Secure Cloud Edition (CE) for 90 Days

Tigera Secure Cloud Edition enables users to deploy applications to Amazon EKS with enterprise-grade network security and continuous compliance for the Amazon EKS environment. Sign up to try Tigera Secure CE with 90 days of credit on AWS and Amazon EKS.

.

Tigera – APN Partner Spotlight

Tigera is an APN Advanced Technology Partner. They provide Zero Trust Network Security and continuous compliance for modern applications. Tigera Secure Cloud Edition (CE) builds on open source projects sucha as Kubernetes, Calico, and Istio, which Tigera engineers maintain and contribute to as active members of the cloud-native community.

Contact Tigera | Solution Overview | Free Trial

*Already worked with Tigera? Rate this Partner

*To review an APN Partner, you must be an AWS customer that has worked with them directly on a project.