Use service rules in policy

1 MINUTE READ

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.

Limitations

Service rules in network policy are not implemented on Windows nodes. This will be included in a future release.

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.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-api-access
  namespace: my-app
spec:
  selector: all()
  egress:
    - action: Allow
      destination:
        services:
          name: kubernetes
          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.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-kube-dns
spec:
  selector: all()
  egress:
    - action: Allow
      destination:
        services:
          name: kube-dns
          namespace: kube-system

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

Above and beyond