AI Space

DevOps & Tooling / Knowledge library

Calico

kubernetes pod networking and workload traffic policy

Network and network-policy platform

Why learn Calico?

Useful for workload connectivity and isolation. Network policies should be tested with expected allow and deny cases before broad rollout.

Where it came from

Calico provides networking and security policy for containerized workloads and other supported environments. It offers multiple networking and data-plane options.

Build your understanding

Work through these exercises in order. Try the task before opening a reference.

  1. Identify the cluster's selected networking mode.
  2. Inspect a test workload's network identity.
  3. Write a policy allowing one required connection.
  4. Verify an unrelated connection is denied.
  5. Diagnose a policy mismatch using observed traffic.

Documentation and sources

Catalog research notes

Connect the ideas

Alternatives

Cilium

Explore next

KubernetesLinux

Real World Example

Illustrative business scenario · AI-generated from linked documentation · Not a measured customer case study

Securing Microservices in a Multi-Tenant E-commerce Platform

A multi-tenant e-commerce provider hosting various vendor storefronts on a shared Kubernetes cluster.

The business problem

The platform faces significant security risks due to lateral movement, where a compromised pod in one vendor's namespace could potentially access sensitive data or services in another vendor's namespace.

How this topic solves it

Calico Network Policies provide granular, label-based traffic control that allows the platform to enforce a zero-trust architecture, ensuring that pods can only communicate with explicitly authorized services regardless of their physical location on the cluster.

  1. Install Calico Open Source on the Kubernetes cluster to enable the CNI and policy enforcement engine.
  2. Define a GlobalNetworkPolicy to implement a default-deny posture for all inter-namespace traffic.
  3. Apply specific NetworkPolicy resources using label selectors to whitelist traffic between authorized microservices.
  4. Utilize Calico's staged policies to preview the impact of new security rules on existing traffic flows before final enforcement.
Calico Policy Enforcement Flow · Process flow

This diagram illustrates how Calico intercepts traffic between pods to enforce security policies based on labels.

Frontend Pod

Vendor A Storefront

Backend Pod

Vendor A Database

Malicious Pod

Vendor B Compromised

Calico Policy Engine

Enforces label-based rules

  • Frontend Pod → Traffic Request → Calico Policy Engine
  • Calico Policy Engine → Permit (Match Label) → Backend Pod
  • Malicious Pod → Traffic Request → Calico Policy Engine
  • Calico Policy Engine → Deny (No Match) → Malicious Pod

Implementation example

This policy restricts backend access to only those pods labeled as frontend, preventing unauthorized access from other namespaces.

yaml · Illustrative code; not executed or production-validated.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  selector: role == 'backend' # Target the backend pods
  ingress:
  - action: Allow
    source:
      selector: role == 'frontend' # Only allow traffic from frontend pods

Expected business outcome

A hardened environment where inter-tenant traffic is strictly isolated, significantly reducing the blast radius of potential security breaches.

Limitations and checks

The primary limitation is the increased operational complexity of managing a large set of granular policies, which can lead to configuration drift; this can be checked by auditing policy logs and using the Calico flow visualization tools to identify orphaned or overly permissive rules.

Sources

Generated 2026-10-18 with gemini-3.1-flash-lite. Your assessment includes two questions about this example.

Catalog source: technology-maxxing. This page reproduces the existing catalog’s learning material and source links.