module-2-ztac-ns-isolation.md

Module 2 - Zero-Trust Workload Access Control with Namespace Isolation Recommendation

One of the best ways to make your Kubernetes cluster more secure is to use network policy to isolate namespaces. This means that you only allow the communication between namespaces that is absolutely necessary, and you block everything else. This helps to reduce the risk of an attacker moving from one part of your cluster to another if they manage to get in.

Calico Cloud makes it simple for platform operators to set up namespace isolation. You don't need to be an expert in writing network policies or know the details of how your applications communicate. Calico Cloud looks at the flow logs generated by your workloads. Then, it automatically suggests and sets up policies for each namespace. These policies can be used to isolate your namespaces from each other.

During this workshop, we will use the Cat Facts Application as an example to work on. In this module, we will learn how to use Calico to recommend and set up network policies to control access to and from a namespace. Once the application is deployed, we will enable the policy recommandations and then review and activate the policies.

1. Clone this repository in your AWS CloudShell.

   git clone https://github.com/tigera-solutions/cc-eks-zero-trust-workshop.git && \
   cd cc-eks-zero-trust-workshop

2. Install the example application stack:

   From the cloned directory, execute:

   kubectl apply -f pre

Included in the pre folder, there is the application that will be used in the exercises during the workshop. The diagram below shows how the applications' microservices communicate between themselves.

There are also other objects that will be created. We will learn about them later in the workshop.

Important

Wait until all the pods are up and running to move to the next step.

Service Graph

Connect to Calico Cloud GUI. From the menu, select Service Graph > Default. Explore the options.

Enable policy recommendations

1. In the left navbar in Manager UI, click Policies, Recommendations.

2. On the opt-in page, click Enable Policy Recommendations.

   The Policy Recommendations board is automatically displayed.

   

Note

• A policy recommendation is generated for every namespace in your cluster (unless namespaces are filtered out by an Admin using the selector in the PolicyRecommendationScope resource).
• Flow logs are continuously monitored for policy recommendations.
• Recommended policies are continuously updated until you Add to policy board or Dismiss policy using the Actions menu.
• Policy recommendations are created as staged network policies so you can safely observe the traffic before enforcing them.
• Traffic originating from the recommended policy's namespace is used to generate egress rules, and traffic destined for the namespace is used to define ingress rules.
• To stop policy recommendations from being processed and updated for a namespace, click the Action menu, Dismiss policy.

The Zero Trust approach

A global default deny policy ensures that unwanted traffic (ingress and egress) is denied by default. Pods without policy (or incorrect policy) are not allowed traffic until the appropriate network policy is defined. Although the staging policy tool will help you find the incorrect or the missing policy, a global deny policy helps mitigate other lateral malicious attacks.

By default, all traffic is allowed between the pods in a cluster. Let's start by testing connectivity between application components and across application stacks. All of these tests should succeed as there are no policies in place.

We recommend creating a global default deny policy after you complete reviewing the policy for the traffic you want to allow. Use the stage policy feature to get your allowed traffic working as expected, then lock down the cluster to block unwanted traffic.

1. Create a staged global default-deny policy. It will show all the traffic that would be blocked if it were enforced.

   • Go to the Policies Board
   • On the bottom of the tier box default click on Add Policy
     • In the Create Policy page enter the policy name: default-deny
     • On the Applies To session, click Add Namespace Selector First, lets apply only to the catfacts namespace
       • Select Key... kubernetes.io/metadata.name
       • =
       • Select Value... catfacts
     • On the field Type select both checkboxes: Ingress and Egress.
     • You are done. Click Stage on the top-right of your page.

   The staged policy does not affect the traffic directly but allows you to view the policy impact if it were to be enforced. You can see the denied traffic in the staged policy.

Review and activate policy recommendations

1. Review the policy recommendations

   After a few minutes, you will be able to see the policy recommendation. Take a minute to review the rules being suggested and ensure they align with your intentions.

   

2. Activate policy recommendations

   From the Policy Recommendation board, select a policy recommendation (or bulk select) and select, Add to policy board. You can now view the active policies in the Policies Board. In the left navbar, click Policies.

   

3. View the active policies in Policy Recommendations.

   Click on the Active tab in Policy Recommendations. Active policies were recommendations that were moved to the policy board.

   

   Policy recommendations are added to the namespace-isolation tier. Note the following:

   • Staged network policy recommendations work like any other staged network policy.
   • You cannot move recommended staged policies in the namespace-isolation tier.
   • The name of the namespace-isolation tier is fixed and cannot be changed

   You are now ready to observe traffic flows in Policies board to verify that the policy is authorizing traffic as expected. When a policy works as expected, you can safely enforce it.

---

➡️ Module 3 - Workload Isolation with Microsegmentation

⬅️ Module 1 - Connect the AKS cluster to Calico Cloud
↩️ Back to Main