This post has been republished via RSS; it originally appeared at: Containers articles.
Hello, we would like to feature our partners from Tigera Calico that we teamed up with to co-author a blog on Zero-Trust security for Windows container-based applications with Calico. Below are the names of the partners that co-authored the blog.
Dhiraj Sehgal Jen Luther Thomas
Enterprises are increasingly integrating Windows containers into their Kubernetes workflow and much like Linux containers they are looking to strengthen their Windows container based application’s security posture by explicitly authorizing and verifying every communication request and minimizing trust assumptions. Zero-trust workload security restricts communication between pods and services at a very fine-grained level, resulting in multiple benefits that include:
- Enhanced Security: Ensures each pod has limited and authorized communication access, preventing potential threats from spreading across the cluster.
- Compliance: Achieves compliance requirements by enforcing strict access controls and data isolation.
- Isolation of Sensitive Data: Isolates sensitive data from other less sensitive workloads to reduce the risk of unauthorized access.
- Workload Communication Visibility: Provides better visibility into workload-workload communication and security gaps, including network security policies.
As the number of Windows container-based workloads and associated pods running in the cluster grows, building security posture requires zero-trust workload access security with the following:
- Egress access controls: Secure access from individual pods running Linux or windows containerized workloads in a Kubernetes cluster to external resources, including cloud services, databases, and 3rd-party APIs.
- DNS Policies: Enforce DNS policies at the source pod so that fully qualified domain names (FQDN/DNS) can be used to allow access from a pod or set of pods (via label selector) to external resources—eliminating the need for a firewall rule or equivalent.
- Global and Namespaced Network Sets: Automatically update access controls for all IPs described by the CIDR notation using IP subnet/CIDR in security policies.
- Identity-Aware Microsegmentation: Segment workloads using workload identities to achieve workload isolation and limit lateral communication.
- Application-Layer Policy: Apply security controls at the application level to secure pod-to-pod traffic, including HTTP methods and URL paths. Eliminate the operational complexity of deploying an additional service mesh.
Let's go through an example to build zero-trust security for the demo application Online Boutique (previously known as Hipster Shop), an 11 microservice demo application, in a Azure Kubernetes Service 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: Online Boutique microservices architecture
Zero-trust workload access control for CartService:
We will explore two scenarios to secure CartService that carries products for the checkoutservice after product selection from the Redis database has happened. CartService is powered by an external third-party service. The service needs to be secure and have exclusive access from checkout to prevent tampering with the changes in the cart.
Scenario 1: Building the security policy for CartService
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, the team can make use of Calico Cloud’s ‘Recommend a policy’ feature to automatically highlight flows between workloads as seen below:
Policy recommendation will aggregate the metadata of those flows to understand their full context and suggest a policy that allow-lists traffic between cartservice and checkoutservice based explicitly on the port, protocol, and the label’s key-pair value match.
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.
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. DevOps engineer or Developer can enforce their policy after understanding its impact on network flow. Further, they can also download Kubernetes CR YAML and check into their git repo to apply it as part of their code deployment. Even if the environment is rebuilt, the policies being part of code are directly applied to the services.
Once the zero-trust security policy is enforced between trusted workloads of cartservice and checkoutservice, the user can also create a default-deny policy at the end of the namespace to deny unwanted lateral connections.
Scenario 2: How to implement a security policy (if a threat is detected and CartService is vulnerable)
If the CartService is vulnerable due to poor policy design, and an identified threat is able to probe that workload, DevOps can create a quarantine policy to log and deny those flows at the earliest possible stage of the policy tier board in Calico Cloud.
Implement identity-aware microsegmentation for Frontend and ShippingService
Frontend talks to ShippingService, but under organizational rules. Shippingservice is the service that stores all mailing information for all customers. The Frontend purpose is to provide customer login and interact with other services 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. Let’s simplify it to the next figure, where frontend and backend are in different zones and have controlled communication among them.
Figure 1: Storefront microservices architecture
How to make sure that ‘frontend’ and ‘backend’ microsegmentation happen according to organizational requirements
In this scenario, DevOps can 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 (i.e. service-1)
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. Team can 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 namespace, it would need to match all three of the above contexts in order for the packet to be allowed.
Figure 2: Kubernetes insecure flat network design to rogue workloads
Finally, the team implements a “restricted” zone that ensures 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.
Conclusion
Windows on AKS can be extended with partner solutions, just like Linux by utilizing Calico's recommended policies, policy board, and tiering, teams can reduce the attack surface of deployed Windows-based containers in a namespace and implement microsegmentation to prevent lateral movement of threats across different workloads within a namespace to strengthen their application’s security posture.
Try it yourself here in self-paced workshop.