Use service rules in policy

Big picture

Use Calico network policy to allow/deny traffic for Kubernetes services.

Value

Using Calico network policy, you can leverage Kubernetes Service names to easily define access to Kubernetes services. Using service names in policy enables you to:

  • Allow or deny access to the Kubernetes API service.
  • Reference port information already declared by the application, making it easier to keep policy up-to-date as application requirements change.

Features

This how-to guide uses the following Calico features:

NetworkPolicy or GlobalNetworkPolicy with a service match criteria.

How to

Allow access to the Kubernetes API for a specific namespace

In the following example, egress traffic is allowed to the kubernetes service in the default namespace for all pods in the namespace my-app. This service is the typical access point for the Kubernetes API server.

  1. apiVersion: projectcalico.org/v3
  2. kind: NetworkPolicy
  3. metadata:
  4.   name: allow-api-access
  5.   namespace: my-app
  6. spec:
  7.   selector: all()
  8.   egress:
  9.     - action: Allow
  10.       destination:
  11.         services:
  12.           name: kubernetes
  13.           namespace: default

Endpoint addresses and ports to allow will be automatically detected from the service.

Allow access to Kubernetes DNS for the entire cluster

In the following example, a GlobalNetworkPolicy is used to select all pods in the cluster to apply a rule which ensures all pods can access the Kubernetes DNS service.

  1. apiVersion: projectcalico.org/v3
  2. kind: GlobalNetworkPolicy
  3. metadata:
  4.   name: allow-kube-dns
  5. spec:
  6.   selector: all()
  7.   egress:
  8.     - action: Allow
  9.       destination:
  10.         services:
  11.           name: kube-dns
  12.           namespace: kube-system

Use service rules in policy - 图1note

This policy also enacts a default-deny behavior for all pods, so make sure any other required application traffic is allowed by a policy.

Allow access from a specified service

In the following example, ingress traffic is allowed from the frontend-service service in the frontend namespace for all pods in the namespace backend. This allows all pods that back the frontend-service service to send traffic to all pods in the backend namespace.

  1. apiVersion: projectcalico.org/v3
  2. kind: NetworkPolicy
  3. metadata:
  4.   name: allow-frontend-service-access
  5.   namespace: backend
  6. spec:
  7.   selector: all()
  8.   ingress:
  9.     - action: Allow
  10.       source:
  11.         services:
  12.           name: frontend-service
  13.           namespace: frontend

We can also further specify the ports that the frontend-service service is allowed to access. The following example limits access from the frontend-service service to port 80.

  1. apiVersion: projectcalico.org/v3
  2. kind: NetworkPolicy
  3. metadata:
  4.   name: allow-frontend-service-access
  5.   namespace: backend
  6. spec:
  7.   selector: all()
  8.   ingress:
  9.     - action: Allow
  10.       protocol: TCP
  11.       source:
  12.         services:
  13.           name: frontend-service
  14.           namespace: frontend
  15.       destination:
  16.         ports: [80]

Additional resources