How to Implement Secure Multi-Tenancy in Kubernetes with Capsule and Network Policies

By /

Multi-tenancy in Kubernetes allows different teams or applications to share a cluster while maintaining isolation and security. While Capsule helps define and manage tenants at the namespace level, network policies ensure that tenants’ network traffic remains isolated. In this blog, we’ll explore how to implement secure multi-tenancy in Kubernetes using Capsule and Network Policies, with real-world examples and best practices.

🚀 Why Multi-Tenancy Needs Secure Networking

In a multi-tenant Kubernetes setup, multiple tenants (such as teams, customers, or applications) share the same cluster. This introduces several security challenges:

Traffic Isolation – Prevent one tenant’s network traffic from accessing another tenant’s pods or services.
Minimized Attack Surface – Prevent unauthorized lateral movement within the cluster.
Controlled Egress Traffic – Limit outbound traffic to prevent data exfiltration or accidental access to external systems.
Controlled Ingress Traffic – Ensure that only allowed sources can communicate with the tenant’s services.

Without proper network policies, one compromised tenant could potentially impact others, leading to data breaches and service downtime.

🛠️ How Capsule Improves Network Security

secure

Capsule enforces multi-tenancy at the namespace level, but network traffic between tenants is still allowed by default in Kubernetes. Capsule addresses this by:

  • Creating a separate namespace for each tenant.
  • Applying network policies to restrict communication between tenant namespaces.
  • Allowing tenant-specific ingress and egress rules.
  • Supporting namespace labels for easier network policy enforcement.

🌐 How Kubernetes Network Policies Work

A NetworkPolicy is a Kubernetes resource that defines how pods within a namespace can communicate with other pods and external endpoints. A network policy can control:

  • Ingress – Incoming traffic to the pod.
  • Egress – Outgoing traffic from the pod.
  • Pod-to-Pod Traffic – Communication between pods within a namespace or between namespaces.

Example network policy fields:

  • podSelector – Selects the pods to which the policy applies.
  • namespaceSelector – Selects the namespaces allowed to communicate.
  • policyTypes – Defines whether the policy applies to ingress, egress, or both.
  • ports – Specifies allowed ports and protocols.

🔎 Step-by-Step Guide: Implementing Secure Multi-Tenancy with Capsule and Network Policies

1. Install Capsule

First, install Capsule using Helm:

helm repo add clastix https://clastix.github.io/charts
helm install capsule clastix/capsule

Verify the installation:

kubectl get pods -n capsule-system

2. Create a Capsule Tenant

Create a tenant named team-a:

apiVersion: capsule.clastix.io/v1beta1
kind: Tenant
metadata:
  name: team-a
spec:
  owners:
    - kind: User
      name: "dev1@example.com"
  namespaceQuota: 2
  nodeSelector:
    kubernetes.io/os: linux
  storageClasses:
    allowed:
      - standard

Apply the tenant:

kubectl apply -f tenant.yaml

After applying, Capsule will create a namespace (e.g., team-a-namespace) for the tenant.

3. Create a Network Policy to Restrict Cross-Tenant Traffic

By default, pods within a namespace can communicate freely with other namespaces. Let’s create a network policy to restrict this behavior.

Create a deny-cross-namespace.yaml file:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
  namespace: team-a-namespace
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
        - podSelector: {}

Apply the policy:

kubectl apply -f deny-cross-namespace.yaml

✅ What this does:

  • Pods in team-a-namespace can only communicate with other pods in the same namespace.
  • Cross-namespace traffic is blocked.

4. Allow Ingress from a Specific Namespace

Suppose you want to allow team-b-namespace to access team-a-namespace.

Create an ingress policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-team-b-ingress
  namespace: team-a-namespace
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              capsule.clastix.io/tenant: team-b

Apply the policy:

kubectl apply -f allow-team-b-ingress.yaml

✅ What this does:

  • Only traffic from pods in team-b-namespace is allowed.
  • All other ingress traffic remains blocked.

5. Allow Egress to External Endpoints

If you want to allow outbound traffic to a specific external IP or service, define an egress policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-external
  namespace: team-a-namespace
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 192.168.1.0/24

Apply the policy:

kubectl apply -f allow-egress-to-external.yaml

✅ What this does:

  • Allows outbound traffic to IPs in the 192.168.1.0/24 range.
  • Egress to other IPs remains blocked.

6. Verify Network Policies

To check active network policies in the namespace:

kubectl get networkpolicy -n team-a-namespace

To inspect a specific network policy:

kubectl describe networkpolicy allow-egress-to-external -n team-a-namespace

🚨 Troubleshooting Common Issues

1. No Network Connectivity Between Pods

  • Ensure that the network plugin supports network policies (Calico, Cilium, etc.).
  • Use kubectl describe networkpolicy to confirm that policies are applied.

2. Egress Traffic Blocked

  • Check if the network policy allows outbound traffic to the target CIDR.
  • Test connectivity using curl or nc:
kubectl exec -it pod-name -- curl http://192.168.1.100

3. Ingress Traffic Not Working

  • Ensure that the ingress controller is configured correctly.
  • Verify that the network policy allows traffic from the correct namespace.

🏆 Best Practices for Secure Multi-Tenancy

Apply the principle of least privilege – Only allow necessary ingress and egress traffic.
Use Capsule’s tenant-specific labels – Helps define network policies at the tenant level.
Monitor network activity – Use Prometheus and Grafana to monitor tenant-specific traffic.
Automate network policy enforcement – Create templates to simplify policy creation.

🌍 Real-World Use Case

A SaaS company hosts multiple customer environments in a shared Kubernetes cluster:

  • Capsule creates separate tenants for each customer.
  • Network policies restrict cross-tenant traffic to prevent data leaks.
  • Egress is limited to specific internal services.
  • Monitoring tools provide visibility into tenant-specific network traffic.

This setup ensures that customer data remains isolated and secure.

🎯 Conclusion

Implementing secure multi-tenancy in Kubernetes requires a combination of tenant isolation and network segmentation. Capsule provides tenant-level isolation, while Kubernetes network policies enforce traffic control. Together, they create a scalable, secure, and efficient multi-tenant environment.

That’s it for now. I hope this article gave you some useful insights on the topic. Please feel free to drop a comment, question or suggestion.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top