Red Hat OpenShift Administration II: Configuring a Production Cluster

Bookmark this page
P12345678910
PreviousNext

Configure Network Policies

Objectives

  • Restrict network traffic between projects and pods.

Managing Network Policies in OpenShift

With network policies, you can configure isolation policies for individual pods. Network policies do not require administrative privileges, and give developers more control over the applications in their projects. You can use network policies to create logical zones in the SDN that map to your organization network zones. The benefit of this approach is that the location of running pods becomes irrelevant, because with network policies, you can separate traffic regardless of where it originates.

In contrast to traditional firewalls, Kubernetes network policies control network traffic between pods by using labels instead of IP addresses. To manage network communication between pods in two namespaces, assign a label to the namespace that needs access to another namespace, and create a network policy that selects these labels. You can also use a network policy to select labels on individual pods to create ingress or egress rules. In network policies, use selectors under spec to assign which destination pods are affected by the policy, and selectors under spec.ingress to assign which source pods are allowed. The following command assigns the network=network-1 label to the network-1 namespace:

[user@host ~]$ oc label namespace network-1 network=network-1

The following examples describe network policies that allow communication between pods in the network-1 and network-2 namespaces:

  • The following network policy applies to any pods with the deployment="product-catalog" label in the network-1 namespace. The network-2 namespace has the network=network-2 label. The policy allows TCP traffic over port 8080 from pods whose label is role="qa" in namespaces with the network=network-2 label.

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: network-1-policy
  namespace: network-1
spec:
  podSelector:  1
    matchLabels:
      deployment: product-catalog
  ingress:  2
  - from:  3
    - namespaceSelector:
        matchLabels:
          network: network-2
      podSelector:
        matchLabels:
          role: qa
    ports:  4
    - port: 8080
      protocol: TCP

    1

    The top-level podSelector field is required and defines which pods use the network policy. If the podSelector is empty, then all pods in the namespace are matched.

    2

    The ingress field defines a list of ingress traffic rules to apply to the matched pods from the top-level podSelector field.

    3

    The from field defines a list of rules to match traffic from all sources. The selectors are not limited to the project in which the network policy is defined.

    4

    The ports field is a list of destination ports that allow traffic to reach the selected pods.

  • The following network policy allows traffic from any pods in namespaces with the network=network-1 label into any pods and ports in the network-2 namespace. This policy is less restrictive than the network-1 policy, because it does not restrict traffic from any pods in the network-1 namespace.

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: network-2-policy
  namespace: network-2
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network: network-1

Note

Network policies are Kubernetes resources. As such, you can manage them with oc commands.

Network Policies Between Projects

One benefit of using network policies is to manage security between projects (tenants), which you cannot do with layer 2 technologies such as VLANs. With this approach, you can create tailored policies between projects to ensure that users can access only what they should (which conforms to the least privilege approach).

The fields in the network policy that take a list of objects can either be combined in the same object or can be listed as multiple objects. If combined, the conditions are combined with a logical AND. If separated in a list, the conditions are combined with a logical OR. With the logic options, you can create specific policy rules. The following examples highlight the differences that the syntax can make:

  • This example combines the selectors into one rule, and thereby allows access only from pods with the app=mobile label in namespaces with the network=dev label. This sample shows a logical AND statement.

    ...output omitted...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network: dev
      podSelector:
        matchLabels:
          app: mobile

  • By changing the podSelector field in the previous example to be an item in the from list, any pods in namespaces with the network=dev label or any pods with the app=mobile label from any namespace can reach the pods that match the top-level podSelector field. This sample shows a logical OR statement.

    ...output omitted...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network: dev
    - podSelector:
        matchLabels:
          app: mobile

Deny-all Network Policies

If a pod is matched by selectors in one or more network policies, then the pod accepts only connections that at least one of those network policies allows. A strict example is a policy to deny-all ingress traffic to pods in your project, including from other pods inside your project. An empty pod selector means that this policy applies to all pods in this project. The following policy blocks all traffic, because no ingress rules are defined. Traffic is blocked unless you also define an explicit policy that overrides this default behavior.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
spec:
  podSelector: {}

Important

If a pod does not match any network policies, then OpenShift does not restrict traffic to that pod. When creating an environment to allow network traffic only explicitly, you must include a deny-all policy.

Allowing Access from OpenShift Cluster Services

When you protect your pods by using network policies, OpenShift cluster services might need explicit policies to access pods. Several common scenarios require explicit policies, including the following ones:

  • The router pods that enable access from outside the cluster by using ingress or route resources

  • The monitoring service, if your application exposes metrics endpoints

The following policies allow ingress from OpenShift monitoring and ingress pods:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring

Important

Network policies do not block traffic from pods that use host networking to pods in the same node.

For example, on a single-node cluster, a deny-all network policy does not prevent ingress pods that use the host network strategy from accessing application pods.

Inside a node, traffic from pods that use host networking is treated differently from traffic from other pods. Network policies control only internal traffic from pods that do not use host networking.

When traffic leaves a node, no such different treatment exists, and network policies control all traffic from other nodes.

For more information about this topic, refer to Network Policies

References

For more information about network policy, refer to the Network Policy chapter in the Red Hat OpenShift Container Platform 4.14 Networking documentation at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html-single/networking/index#network-policy

PreviousNext
Revision: do280-4.14-08d11e1