The easiest ways to create, test and deploy security policies for EKS clusters

Amazon’s Elastic Kubernetes Service (EKS) is a popular managed Kubernetes option that allows customers to benefit from both an offloaded Kubernetes management plane, and the wide range of services that AWS offers.

Managed or unmanaged, securing cluster traffic is always critical and, although AWS Security Groups can secure the cluster nodes, securing pod traffic requires something closer to the application data-path.

This is where Calico Policy comes into its own, allowing you to secure, segment and micro-segment your applications at the pod level inside of the EKS cluster.

In this blog post I will lay out 5 essential tips for creating, testing and deploying Calico Security Policies for EKS clusters.

Creating Calico Policies

TIP 1: Automate Policy Creation with Calico’s Policy Recommendation Engine

A new application has been deployed into the cluster but the details on needed ingress and egress flows have not been fully communicated. This can leave administrators with a discovery task to determine what application traffic needs to be secured and, of course, this needs to be done without impacting the running application.

Solving this problem is one of the key traits of the Calico Policy Recommendation Engine. Once enabled, the Calico Policy Recommendation Engine dynamically learns the traffic patterns for each namespace in a cluster and will suggest Calico Staged policies (more on this later) based on these flows.

Administrators can then review these policies and apply them to the cluster to be monitored before pushing into the dataplane.

TIP 2: Provide Developers with Ability to Create Application-level Policies without compromising Enterprise Security Guardrails with Policy Tiers

With Kubernetes Network Policies, there is no concept of an ordering structure because Kubernetes Network Policies are seen as additive. This means that, since there is no way to explicitly deny traffic, Kubernetes Network Policies can be viewed as a collective “stacked whitelist”.

Calico Policy includes the entire feature set of Kubernetes Network Policy and more, such as the ability to make DENY, LOG and PASS actions.

Adding Calico Tiering to the mix allows for even more flexibility when architecting your cluster security posture.

Calico Tiering divides Calico, and Kubernetes, Network Policies into an ordered set of Tiers. Tiers are processed from left to right and policies in Tiers are processed from top to bottom.

This gives administrators the ability to:

• Group Policies based on function or scope
  • Group policies that affect the entire cluster in a Security Tier
  • Group policies that affect the platform, like DNS, storage, Ingress, in a Platform Tier
• High-level guardrails
  • In the higher precedence tier, policies can be used to define the type of flows are expected in relation to specific applications, and then deny all other flows
  • This enforce policy rules in higher precedence tiers that cannot be circumvented by policies in lower precedence tiers
• RBAC
  • Developers can be given rights to create and manage Calico Policies in specific tiers, along with further restrictions to namespaces that their policies can secure.
  • The Calico Policy Recommendation Engine can also help users to determine the correct Calico Policies for their application without deep-diving into the logic behind Calico Policies

Testing Calico Policies

TIP 3: Test Policies in a Live Environment with Staged Policies

So you now have the means to create and organize Calico Policies, but you still need to test any impact before deploying into production. But how do you test for impact without affecting your running pods, be they in production or test/dev? This is exactly what Calico Staged Policies were designed for. Calico Staged Policies allow you to deploy a policy, gather all of the data on how traffic would have been impacted (via flow-logs), but without actually impacting your cluster workloads and applications.

TIP 4: Monitor Workload-to-Workload Communication and Security Policies and Gaps with Dynamic Service and Threat Graph

As we alluded to in the previous tip, Calico flow-logs are essential in allowing administrators to observe the EKS cluster and to ensure applications are working as they should.
After deploying a Calico Policy, be it Staged or Enforced, it is the Observability tools Calico provides that will allow administrators to make accurate decisions when iterating through their policy lifecycle.

With Calico on EKS, administrators have a plethora of tools to observe the impact, or potential impact, a Staged or Enforced Policy would have on their cluster. If we take the example of the Staged Policy used in the previous tip, the potential denied flow can be viewed in multiple ways.

Service-Graph

Service-Graph indicates that, although the flow was allowed, it reports that a staged policy would have denied this traffic if the policy was enforced in the datapath.

Flowviz

With Flowviz you can quickly filter interesting flows and in this case we can see, again, that staged policies would have dropped this traffic had they been enforced on the datapath.

Kibana

And finally Kibana gives administrators the choice of using a Calico curated dashboards (as shown above) or create your own to model the exact data you need.

Deploying Calico Policies

TIP 5: Leverage GitOPs model to deploy Policy as code

We have discussed creating, organizing, testing and observing our Calico Policies, but the final step is to actually deploy these Policies into our EKS cluster. As Kubernetes allows for both declarative and imperative modes of operation, an obvious choice would be to use kubectl to apply all of our policies from a yaml file.

Another way to do this would be to take a GitOps approach and to house all of our Calico policies in a git repo that acts as a single source of truth. This allows us to declare our clusters’ desired state from a git repo and allow a tool like Flux or argoCD to ensure this state is maintained by constantly comparing the live cluster with the source-of-truth git repo.

Conclusion

Securing your Kubernetes application traffic in EKS is a critical, but daunting, task to undertake. Calico Enterprise simplifies securing your EKS cluster by means of automated policy recommendations, non-disruptive policy testing and high-value flow information to enable well informed decision making, leaving nothing to chance.

Ready to get started? Try Calico Cloud for free.