AWS Partner Network (APN) Blog
Implementing Zero-Trust Workload Security on Amazon EKS with Calico
By Andrew Park, Solutions Architect – AWS
By Dhiraj Sehgal, Director, Solution and Partner Marketing – Tigera
 |
| Tigera |
 |
DevOps, site reliability engineers (SREs), and cloud platform owners are selecting Amazon Elastic Kubernetes Service (Amazon EKS) as their platform of choice to build cloud-native applications because it’s easy to adopt and scale, and provides native integrations with core Amazon Web Services (AWS) technology.
Building and running cloud-native applications in Amazon EKS requires communication with other AWS and external third-party services. Additional security guardrails are required to meet compliance requirements and detect and protect from potential security threats.
The AWS Solutions Architecture team and Tigera Technical Experts team have been running hands-on workshops, during which we’ve been answering users’ questions about Amazon EKS and demonstrating how they can address their security needs with Calico Cloud and Calico Enterprise.
Workshop registrants and participants have emphasized the importance of having robust zero-trust workload access controls and microsegmentation for their multi-tenant workloads.
In this post, we‘ll dive into how you can apply zero-trust workload access controls along with microsegmentation for your workloads that run on Amazon EKS, and provide specific examples. Before we do that, let’s explore what implementing zero-trust workload access controls and identity-aware microsegmentation means for you.
Tigera is an AWS Competency Partner and the inventor and maintainer of open-source Calico. Tigera also delivers Calico Cloud, a pay-as-you-go software as a service (SaaS) for Kubernetes security and availability.
Implementing Zero-Trust Workload Access Controls
Establishing service-to-service connectivity within your Amazon EKS cluster is easy. But how do you enable some of your workloads to securely connect to services—like Amazon Relational Database Service (Amazon RDS) and Amazon ElastiCache—that are external to the cluster?
There are two things you should do:
- Implement a security model that enforces strict verification of access to and from workloads.
- Author domain name system (DNS) policies that implement fine-grained access controls between EKS workloads and the external services they need to connect to.
Implementing Microsegmentation
By default, Kubernetes is an open system with no built-in security controls. Without east-west controls like microsegmentation, a cyberattacker can gain unauthorized access and move laterally within a cluster in search of sensitive data and other high-value assets.
How can you reduce attack area within a Kubernetes cluster? There are a two things you should do:
- Ensure workload isolation so experimental changes to your development environment don’t affect your production environment.
- Make applications conform to the compliance requirements of the organization. You have to ensure other users don’t inadvertently override or intentionally tamper with your security controls, and that end users have full visibility for when issues come up.
Workshop Application
In Tigera’s AWS DevDay workshops, participants are provided with Online Boutique (previously known as Hipster Shop), an 11-tier microservice demo application, in an Amazon EKS environment and connected to Calico Cloud.
After Online Boutique is deployed, the associated microservices—including RecommendationService and ProductCatalogService as shown below—are monitored for breakdown, timeouts, and slow performance.
The deployment looks like this:
Figure 1 – Online Boutique microservices architecture.
Zero-Trust Workload Access Control for RecommendationService
Let’s take a look at specific examples from this workshop showing how you can apply zero-trust workload access controls and microsegmentation for your workloads running on Amazon EKS.
RecommendationService recommends products to the customer based on search and the product list they are searching for. In this scenario, RecommendationService is powered by an external third-party service such as machine learning on AWS. The service needs to be secure and have exclusive access to prevent tampering with the recommendations.
Scenario 1: Building the Security Policy
Whether or not the DevOps engineer understands the layout of their microservice architecture or the associated label schema for those workloads, once the application is introduced into the cluster we can make use of Calico Cloud’s “Recommend a policy” feature to automatically highlight flows between workloads.
Policy recommendation will aggregate the metadata of those flows to understand their full context, and suggest a policy (similar to the below example) that allow-lists traffic between existing workloads based explicitly on the port, protocol, and the label’s key-pair value match.
Once the zero-trust security policy is enforced between trusted workloads, the user can create a default-deny policy at the end of the namespace to deny unwanted lateral connections.
Scenario 2: Implement a Security Policy in Real Time
During the workshop, users leveraged Calico Cloud’s security policy recommendation engine, following these steps:
- Go to the Calico Cloud Policies Board page and click on Recommend a Policy.
Figure 2 – Policy board in Calico Cloud.
- Select the time range, namespace, and microservice name for policy recommendation and get the recommendation.
Figure 3 – Configuring for policy recommendation.
- If relevant flow logs are found within the selected time range for the workload endpoint, the recommended policy is displayed on the Create Policy screen.
Figure 4 – Policy creation in Calico Cloud.
- Users then assess the impact of the recommended policy using Preview and/or Stage to observe the effect on traffic without impacting actual traffic flows.
Tip shared by users: When multiple teams are involved, the preview option comes in handy as teams can collectively understand the impact from their respective roles, which can be developer, security, DevOps, or network engineer.
Scenario 3: Implement a Security Policy if a Threat is Detected
The first two scenarios outlined in this post detail best practices for limited trust between pods via security policy, followed by a default-deny network policy to automatically mitigate unknown workloads that could be injected into your cluster.
However, if the RecommendationService is vulnerable due to poor policy design, and an identified threat is able to probe that workload, Tigera recommends creating a quarantine policy to log and deny those flows at the earliest possible stage of the policy tier board.
Insert the manifest in the below command:
kubectl apply -f https://raw.githubusercontent.com/tigera-solutions/aws-howdy-parter-calico-cloud/main/policies/quarantine.yaml
In the above example YAML manifest, any workload with the key-pair label match of quarantine=true will have all ingress and egress traffic automatically denied, whilst logging those events to an external SIEM solution for additional forensics via the action:log.
Microsegmentation for ProductCatalogService and RedisCart
In this exercise, we focus on ProductCatalogService and RedisCart service. ProductCatalogService talks to RedisCart but under organizational rules.
RedisCart is the service that stores product catalog in Amazon ElastiCache for Redis. The ProductCatalogService’s purpose is to display the latest catalog, which changes with respect to newer product availability and existing product inventory.
Both services have distinct security requirements, as they are owned by different teams and contain different levels of confidential information.
Figure 5 – Storefront microservices architecture.
Storefront ‘Frontend’ and ‘Backend’ Workload Isolation for Compliance
In this scenario, we aim to create a zone-based architecture via a security policy similar to traditional firewall solutions. The frontend workload is given a label match of “fw-zone=dmz” (Demilitarized Zone).
Any workloads with the DMZ label match can receive ingress traffic from the public internet, and can then relay those flows to workloads in a trusted zone (service-1 and service-2):
The “trusted” zone is responsible for controlling flows between microservices within that zone, as well as securely allowing traffic to and from the DMZ and “restricted” zones.
We implement zero trust by only allowing traffic between these pods explicitly, based on label match, port, and protocol. That way, if a new workload is introduced into this network namespace, it would need to match all three of the above contexts in order for the packet to be allowed.
Figure 6 – Kubernetes insecure flat network design to rogue workloads.
Finally, we implement a “restricted” zone ensuring workloads handling sensitive data, such as databases or log event handlers, are only able to talk to workloads in a trusted zone. This applies to both ingress and egress traffic.
Under no circumstance could a rogue workload in our cluster talk to this database, nor could the database interface against any third-party services/APIs. The only way it could talk to any external IP is via this secure zone-based architecture.
Figure 7 – How Calico’s zone-based security policy design prevents threats.
Conclusion
This excerpt of one aspect of the workshop shows how DevOps, site reliability engineers (SREs), and platform owners can leverage Amazon EKS and Calico Cloud together to build zero-trust workload security in minutes against viruses and other malicious activities.
Amazon EKS and Calico Cloud’s combined solution also provides proof of security compliance to meet organizational regulatory requirements, allowing teams to generate compliance reports for regulatory requirements and policy violations.
Try Calico Cloud for yourself at calicocloud.io or join one of Tigera’s AWS DevDay workshops.
.
.
Tigera – AWS Partner Spotlight
Tigera is an AWS Competency Partner and the inventor and maintainer of open-source Calico. Tigera also delivers Calico Cloud, a pay-as-you-go software as a service (SaaS) for Kubernetes security and availability.