Bootstrap FreeKB - OpenShift - Create egress network policy rules
OpenShift - Create egress network policy rules

Updated:   |  OpenShift articles

Egress provides a way for an application deployed on OpenShift to access an external URL, such as http://www.example.com.

Optionally, NetNamespace is used to assign an egress IP address to one or more namespaces, so that all egress traffic from the namespace is using a dedicated IP address. By assigning a specific egress IP address to a namespace, all outbound (egress) requests from applications in the project will come from the dedicated egress IP address, making it easier to find the requests that came from applications in the project. This also makes it possible to have two (or more) different projects share the same egress IP address, as a way to group similar projects together.

 

An OpenShift route or an Ingress route will provide a URL such as http://route001-project001.apps.openshift.example.com:8080 which is used to route a request onto a service, which is then routed onto a pod, and then to the container in the pod, and finally to the application running in the container.

 

If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

A  JSON or YAML file that contains key value pairs used to create an object, such as a config map, deployment, a project, a pod, a route, a secret, a service, et cetera. These files are known as templates. The oc explain command can be used to get the list of keys that can be used in the JSON or YAML template file.

oc explain egressnetworkpolicy

 

And then more details on each key can be displayed.

oc explain egressnetworkpolicy.spec

 

For example, let's say you have a YAML file named egress.yml that contains the following markup. This template will be used to create a list of IP address and hostnames that services / pods / deployments / containers in a project / namespace are allowed to connect to.

  • cidrSelector is used to list in IP address subnet that is allowed / denied
  • dnsName is used to list a DNS hostname that is allowed / denied

AVOID TROUBLE

The rules are evaluated in order, from the top most rule to the bottom most rule, thus the Deny rule should be the last rule.

apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: egress-rules
  namespace: foo
spec:
  egress:
  - type: Allow
    to:
      cidrSelector: 10.45.6.123/24
  - type: Allow
    to:
      dnsName: www.example.com
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0

 

The oc apply or oc create command with the -f or --filename option can be used to create egress rules using the template JSON or YAML file.

The oc replace command can be used to replace the egress rules using a new or updated template JSON or YAML file.

The oc edit command can be used to update the egress rules.

AVOID TROUBLE

There can only be one egressnetworkpolicy in a project / namespace

~]$ oc create --filename egress.yml 
egressnetworkpolicy.network.openshift.io/egress-rules created

 

The oc get egressnetworkpolicy command can then be used to confirm that the egress network policy exists.

~]$ oc get egressnetworkpolicy
NAME           AGE
egress-rules   115s

 

The oc describe egressnetworkpolicy command can be used to display egress related configuration. In this example, the egress settings for the project/namespace named foo is displayed. The rules are read in order, which means the deny rule should always be the very last rule.

~]$ oc describe egressnetworkpolicy egress-rules
Name:           egress-rules
Namespace:      foo
Created:        2 minutes ago
Labels:         <none>
Annotations:    <none>
Rule:           Allow to 10.45.6.123/24
Rule:           Allow to www.example.com
Rule:           Deny to 0.0.0.0/0

 




Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee



Comments


Add a Comment


Please enter c6bcd6 in the box below so that we can be sure you are a human.