1. Proposed title of this feature request

Network policies and egressFirewall improvements

2. What is the nature and description of the request?

2.1. Unify egress traffic management

As a cluster admin or an application owner I want to be able to manage egress traffic with a single API object.
For now 2 kind of objects are required in ordre to manage IP based and DNS based rules

• egressfirewall -> DNS name support
• networkpolicy -> standard traffic

2.2. Support DNS name and wildcard

As a cluster admin or an application owner I want to be able to declare rules bases on IP addresses or DNS name including wildcards
The following statement are expected to be supported in a rule. Spec are examples only

IP addresses (array of uniq IP)

spec:
  egress: 
  - type: Allow
    to:
      ipv4:
      - 1.2.3.4
      - 1.2.3.5

IP ranges (array of cidr blocs)

spec:
  egress:
  - to:
    type: Allow
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24

Ports (array of uniq port)

spec:
  egress:
  - type: Allow
    to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 32000

Port ranges (array of port ranges)

spec:
  egress:
  - type: Allow
    to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 32000
      endPort: 32768

Nodes (node name or selector based on labels)

spec:
  egress:
  - type: Allow
    to:
    - nodeSelector:
        matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: In
          values:
          - "rhtssc-worker-2.tamlab.redhat.com"
          - "rhtssc-worker-3.tamlab.redhat.com"

spec:
  egress:
  - type: Allow
    to:
    type: Allow
    - nodeSelector:
        matchExpressions:
        - key: "node-role.kubernetes.io"
          operator: In
          values:
          - "control-plane"

Namespaces

spec:
  egress:
  - to:
    - namespaceSelector:
        matchExpressions:
        - key: securityZone
          operator: In
          values: ["abc", "def"]

DNS name (array of FQDN)

spec:
  egress:
  - to:
    type: Allow
    - dnsName:
        - www.google.com
        - www.microsoft.com

DNS wildcard (array of domaine names)
Support only direct subdomains. *.microsoft.com matchs abc.microsoft.com and def.microsoft.com. It does not match def.abc.microsoft.com

spec:
  egress:
  - to:
    type: Allow
    - dnsName:
        - *.microsoft.com

2.3. Ease tracking of incomming traffic through Ingress

As of today incomming traffic through ingress follows the folling schema
External client -> Ingress or route -> Pods
With this classic schema it is not easy to filter the traffic since it must be allowed from external client to Ingress or Route and separately from Ingress to targetted Pods. Two netpols are required leading to loose a bit of identity and tracking on this traffic especially in a zero trust confirguration.
If loadbalancer is not managed by cloud provider, router is on the hostnetwork and not managed by networkpolicy

2.4. Hostnetwork protection

Currently there is no support of hostnetwork in network policy. this network is not part of the CNI and no covered by OVN-Kubernetes (this is expected)
It would be great to be able to manage hostnetwork filtering in the same way.

3. Why does the customer need this? (List the business requirements here)

Manage seamlessly the network filtering with a comprehensive object
Support additional feature like dns wildcards in network policies without egressFirewall object
Benefites are

• Better control of the traffic and network filtering
• Demonstrate installed policies during regulation audit (PCI-DSS, etc.)
• Simplify desing of network policy API
• Unifying design with admin network policies

4. List any affected packages or components.

• ovn-kubernetes
• openshift-apiserver
• openshift-kube-apiserver