Implementing Network Policies in GKE with Calico: A Hands-On Tutorial

Quick Summary

Table of Contents

Introduction

Managing network security within a Kubernetes cluster is essential for safeguarding sensitive data and ensuring smooth operations. Network policies serve as the backbone of this security framework, allowing administrators to control how pods communicate with each other. In Google Kubernetes Engine (GKE), Calico (an open-source networking and network security solution) provides solid support for implementing these network policies effectively. In this hands-on tutorial, we’ll explore how to set up and configure network policies in GKE with Calicoto to enhance the security of your cluster.

Understanding Network Policies

Network policies act as traffic rules within a Kubernetes cluster; by defining these policies, administrators can enforce strict controls over network traffic, ensuring data integrity.

Moreover, using network policies simplifies managing data hosting for different user groups in your app infrastructure. These rules separate pods and services in different namespaces, preventing unauthorized access between them. It boosts data security and makes managing multi-tenant setups easier, ensuring smooth operations and data integrity across your apps.

Also, with Calico in GKE, implementing these policies becomes streamlined and efficient.

Before we explore Network Policies, it’s essential to ensure that you have the necessary prerequisites in place:

Prerequisites

1. GCP Account

First and foremost, you must have a Google Cloud Platform (GCP) account. This account forms the cornerstone for accessing and overseeing the assets within your Google Cloud Environment.

2. gcloud CLI

gcloud is a command-line interface for Google Cloud that provides access to a wide range of Google Cloud services, including GKE. With gcloud, you can create and manage GKE clusters, interact with Kubernetes resources, configure authentication, and perform various other tasks related to the Google Cloud Platform. The gcloud CLI can be installed using the package format on Debian and Ubuntu systems.

Also, ensure your operating system meets the following requirements before installing the gcloud CLI:

a) Open a terminal window
b) Update the package list using the command:

c) Proceed to install the necessary dependencies

Now, for newer distributions, import the Google Cloud public key with the provided command.

Include the gcloud CLI distribution URI as a package source.

Refresh the package list and proceed with the installation of the gcloud CLI

If you have any other operating system, then you can refer to https://cloud.google.com/sdk/docs/install

3. kubectl

Kubectl is a command-line tool for interacting with Kubernetes clusters. It enables users to deploy and manage applications, inspect cluster resources, scale applications, and troubleshoot issues within Kubernetes environments.

Install kubectl binary in Linux system

Install kubectl

Check the version you installed is up-to-date:

To engage with Google Kubernetes Engine (GKE) clusters via kubectl or similar Kubernetes clients, you need an authentication plugin called gke-gcloud-auth-plugin. This plugin utilizes the Client-go Credential Plugins framework to simplify the retrieval of authentication tokens.

These tokens are essential for establishing secure communication channels between the Kubernetes client and GKE clusters. Users can securely authenticate and access their GKE clusters by utilizing this authentication mechanism, enabling seamless management and operation of containerized workloads within the Kubernetes environment.

To check the version of the gke-gcloud-auth-plugin binary, you can use the following command:

4. GKE Cluster

Ensure you have a GKE cluster in your Google Cloud project. If you haven’t created one yet, you can do it through the Google Cloud Console or the ‘gcloud’ command-line tool. Make sure the cluster is set up correctly with the settings you want, like the number of nodes, type of machines, and network options.

By ensuring that these prerequisites are met, you’ll be well-equipped to embark on the journey of configuring Network Policies within your GKE cluster, enhancing security and control over network communication for your containerized applications.

Authenticate with GCP Account

To authenticate with your Google Cloud Platform (GCP) account, you’ll need to use the gcloud CLI. “gcloud init” assists in configuring a new or existing configuration, tailoring properties within that configuration such as the current project, and optionally, specifying the default Google Compute Engine region and zone preferences.

To authenticate a user account with gcloud, run.

Set the default project.

Here, PROJECT_ID refers to the name of your project.

When you run this command in your terminal, it opens a web browser window where you can sign in to your Google account associated with your GCP account. After successful authentication, the Google Cloud SDK is granted access to your GCP resources using the credentials of the signed-in account. This authentication allows you to interact with and manage your GCP resources using the gcloud command-line tool from your local environment.

Access the GKE Cluster

To update the kubectl configuration to use the plugin and authenticate with a specific GKE cluster, you can use the following command:

Replace the placeholders with the actual values as follows:

• CLUSTER_NAME: Replace this with the name of your GKE cluster.
• COMPUTE_REGION: Replace this with the Compute Engine region where your cluster is located. If your cluster is zonal, use –zone=COMPUTE_ZONE instead and replace COMPUTE_ZONE with the specific zone where your cluster resides.

It retrieves the authentication credentials for the specified GKE cluster from the Google Cloud Platform and updates the kubeconfig file on your local system. This kubeconfig file contains the cluster authentication information, including the cluster endpoint, authentication token, and other necessary details. With this account, you can authenticate and engage with the GKE cluster via kubectl commands.

Verify the cluster access,

The output is similar to the following:

Enable the Network Policy in the GKE cluster

By default, GKE clusters lack Network Policy enforcement, exposing your applications to potential unauthorized access or malicious actions. However, with Network Policy, you can define and enforce communication rules between pods, effectively creating a micro-segmentation strategy within your cluster.

Requirements and limitations

Enabling network policy enforcement necessitates the recreation of your nodes. If your GKE cluster currently falls within an active maintenance window, the nodes won’t undergo automatic recreation until the subsequent maintenance window. However, for more immediate implementation, you have the option to manually upgrade your cluster at any time, ensuring timely enforcement of network policies to bolster your cluster’s security posture.

For optimal performance and resource allocation, it’s recommended to have a minimum cluster size of three e2-medium instances when implementing network policy enforcement.

Clusters utilizing f1-micro or g1-small instances are not supported for network policy enforcement due to their limited resources, which may not meet the requirements for effective policy enforcement.

Steps To Enable the Network Policies in Google Kubernetes Engine(GKE) Cluster

To enable network policy enforcement for an existing cluster, follow these steps:

Replace CLUSTER_NAME with the name of the cluster.

Execute the command below to enable network policy enforcement on your cluster, subsequently initiating the recreation of your cluster’s node pools with network policy enforcement enabled:

After executing this command, GKE will recreate your cluster’s node pools network policy enforcement enabled

Verify that all your nodes were re-created:

Validate the Calico Configuration

To verify the Calico configuration using the gcloud describe cluster command and confirm that Calico is the network policy provider, you can follow these steps:

1. Open your terminal or command prompt.
2. Run the following command to describe your GKE cluster:

Replace [CLUSTER_NAME] with the name of your GKE cluster.

3. Look for the networkPolicy field in the output. If Calico is the network policy provider, you should see “networkPolicy”: “CALICO”.

Here’s an example of what the output might look like:

Install calicoctl

When applying network policies specifically managed by Calico within a Kubernetes cluster, you’ll need to use calicoctl instead of kubectl. Calico provides its own set of network policies, and while they are Kubernetes-native, they are managed through the Calico network policy API.

To install the Calicoctl binary on your Ubuntu host, follow these steps:

To set the Calicoctl binary file to be executable

Check the calicoctl version

Apply Network Policies in GKE with Calico

Calico network policy offers granular control over network traffic within Kubernetes clusters, allowing administrators to define policies based on labels, namespaces, IP addresses, and other criteria for precise access control. Moreover, Calico’s seamless integration with Kubernetes and other orchestration platforms ensures smooth deployment and management of network policies across diverse environments, promoting consistency and scalability in network security management.

Calico Network Policy

Calico network policy seamlessly integrates with Kubernetes network policies, offering flexibility in security management strategies. Organizations can leverage both Calico and Kubernetes network policies concurrently or independently, depending on their specific security requirements and operational preferences.

Calico network policies and Calico global network policies are implemented using calicoctl. Their syntax is similar to Kubernetes network policies, but there are a few key differences.

Refer to https://docs.tigera.io/calico/latest/reference/calicoctl/overview for more information.

In a multi-tenant Kubernetes setup, managing traffic within namespaces is simplified by labeling resources like pods, deployments, and namespaces. These labels enable Calico network policies to enforce rules on traffic flow, ensuring security and isolation.

This NetworkPolicy named “allow-test-only” is specifically designed for the “test” namespace within a Kubernetes cluster, aiming to control ingress traffic to pods labeled with “env=test” within that namespace. The CIDR ranges 35.191.0.0/16 and 130.211.0.0/22 likely correspond to the IP address ranges used by the application load balancer (ALB) for health checks.

You can refer to the link https://cloud.google.com/load-balancing/docs/firewall-rules for more information.

Global Network Policy

GlobalNetworkPolicy resources in Calico provide a powerful means to define network connectivity rules that span across namespaces and apply to both workload endpoints and host endpoints within a Kubernetes cluster. Unlike namespaced network policies, which are limited to specific namespaces, GlobalNetworkPolicy rules have a broader scope and can impact all endpoints in the cluster.

This GlobalNetworkPolicy allows incoming HTTP (port 80) and HTTPS (port 443) traffic. It denies all other incoming traffic. It allows all outgoing traffic.

Conclusion