Skip to main content
Calico Open Source 3.29 (latest) documentation

Use service accounts rules in policy

Big picture​

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

Value​

Using Calico network policy, you can leverage Kubernetes service accounts with RBAC for flexible control over how policies are applied in a cluster. For example, the security team can have RBAC permissions to:

  • Control which service accounts the developer team can use within a namespace
  • Write high-priority network policies for those service accounts (that the developer team cannot override)

The network security team can maintain full control of security, while selectively allowing developer operations where it makes sense.

Using Istio-enabled apps with Calico network policy, the cryptographic identity associated with the service account is checked (along with the network identity) to achieve two-factor authentication.

Concepts​

Use smallest set of permissions required​

Operations on service accounts are controlled by RBAC, so you can grant permissions only to trusted entities (code and/or people) to create, modify, or delete service accounts. To perform any operation in a workload, clients are required to authenticate with the Kubernetes API server.

If you do not explicitly assign a service account to a pod, it uses the default ServiceAccount in the namespace.

You should not grant broad permissions to the default service account for a namespace. If an application needs access to the Kubernetes API, create separate service accounts with the smallest set of permissions required.

Service account labels​

Like all other Kubernetes objects, service accounts have labels. You can use labels to create ‘groups’ of service accounts. Calico network policy lets you select workloads by their service account using:

  • An exact match on service account name
  • A service account label selector expression

Before you begin...​

Configure unique Kubernetes service accounts for your applications.

How to​

Limit ingress traffic for workloads by service account name​

In the following example, ingress traffic is allowed from any workload whose service account matches the names api-service or user-auth-service.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: demo-calico
  namespace: prod-engineering
spec:
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          names:
            - api-service
            - user-auth-service
  selector: 'app == "db"'

Limit ingress traffic for workloads by service account label​

In the following example, ingress traffic is allowed from any workload whose service account matches the label selector, app == web-frontend.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-web-frontend
  namespace: prod-engineering
spec:
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          selector: 'app == "web-frontend"'
  selector: 'app == "db"'

Use Kubernetes RBAC to control service account label assignment​

Network policies can be applied to endpoints using selectors that match labels on the endpoint, the endpoint's namespace, or the endpoint's service account. By applying selectors based on the endpoint's service account, you can use Kubernetes RBAC to control which users can assign labels to service accounts. This allows you to separate groups who can deploy pods from those who can assign labels to service accounts.

In the following example, pods with an intern service account can communicate only with pods with service accounts labeled, role: intern.

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: restrict-intern-access
  namespace: prod-engineering
spec:
  serviceAccountSelector: 'role == "intern"'
  ingress:
    - action: Allow
      source:
        serviceAccounts:
          selector: 'role == "intern"'
  egress:
    - action: Allow
      destination:
        serviceAccounts:
          selector: 'role == "intern"'

Additional resources​