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.
-
Clone this repository in your Azure Cloud Shell.
git clone https://github.com/tigera-solutions/cc-aks-implementing-network-security.git && \ cd cc-aks-implementing-network-security
-
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.
Connect to Calico Cloud GUI. From the menu, select Service Graph > Default
. Explore the options.
-
In the left navbar in Manager UI, click Policies, Recommendations.
-
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.
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.
-
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 onAdd Policy
- In the
Create Policy
page enter the policy name:default-deny
- On the
Applies To
session, clickAdd Namespace Selector
First, lets apply only to thecatfacts
namespace- Select Key...
kubernetes.io/metadata.name
- =
- Select Value...
catfacts
- Select Key...
- On the field
Type
select both checkboxes: Ingress and Egress. - You are done. Click
Stage
on the top-right of your page.
- In the
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.
- Go to the
-
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.
-
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, clickPolicies
. -
View the active policies in Policy Recommendations.
Click on the
Active
tab inPolicy 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 can move recommended staged policies in the
namespace-isolation
tier to any user-created tiers to customize it further if desired. - 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