// Module included in the following assemblies:
//
// * networking/ingress-node-firewall-operator.adoc

:_mod-docs-content-type: REFERENCE
[id="nw-ingress-node-firewall-operator-rules-object_{context}"]
= Ingress Node Firewall rules object

[role="_abstract"]
You can review rule fields and examples to define which ingress traffic is allowed or denied by using the Ingress Node Firewall rules object.

The fields for the Ingress Node Firewall rules object are described in the following table:

.Ingress Node Firewall rules object
[cols=".^2,.^2,.^6a",options="header"]
|====
|Field|Type|Description

|`metadata.name`
|`string`
|The name of the CR object.

|`interfaces`
|`array`
|The fields for this object specify the interfaces to apply the firewall rules to. For example, `- en0` and
`- en1`.

|`nodeSelector`
|`array`
|You can use `nodeSelector` to select the nodes to apply the firewall rules to. Set the value of your named `nodeselector` labels to `true` to apply the rule.

|`ingress`
|`object`
|`ingress` allows you to configure the rules that allow outside access to the services on your cluster.
|====

[id="nw-infw-ingress-rules-object_{context}"]
== Ingress object configuration

The values for the `ingress` object are defined in the following table:

.`ingress` object
[cols=".^3,.^2,.^5a",options="header"]
|====
|Field|Type|Description

|`sourceCIDRs`
|`array`
|Allows you to set the CIDR block. You can configure multiple CIDRs from different address families.

[NOTE]
====
Different CIDRs allow you to use the same order rule. In the case that there are multiple `IngressNodeFirewall` objects for the same nodes and interfaces with overlapping CIDRs, the `order` field will specify which rule is applied first. Rules are applied in ascending order.
====

|`rules`
|`array`
|Ingress firewall `rules.order` objects are ordered starting at `1` for each `source.CIDR` with up to 100 rules per CIDR. Lower order rules are executed first.

`rules.protocolConfig.protocol` supports the following protocols: TCP, UDP, SCTP, ICMP and ICMPv6. ICMP and ICMPv6 rules can match against ICMP and ICMPv6 types or codes. TCP, UDP, and SCTP rules can match against a single destination port or a range of ports using `<start : end-1>` format.

Set `rules.action` to `allow` to apply the rule or `deny` to disallow the rule.

[NOTE]
====
Ingress firewall rules are verified using a verification webhook that blocks any invalid configuration. The verification webhook prevents you from blocking any critical cluster services such as the API server.
====
|====

[id="nw-ingress-node-firewall-example-cr_{context}"]
== Ingress Node Firewall rules object example

A complete Ingress Node Firewall configuration is specified in the following example:

.Example Ingress Node Firewall configuration
[source,yaml]
----
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
  name: ingressnodefirewall
spec:
  interfaces:
  - eth0
  nodeSelector:
    matchLabels:
      <label_name>: <label_value>
  ingress:
  - sourceCIDRs:
       - 172.16.0.0/12
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMP
        icmp:
          icmpType: 8 #ICMP Echo request
      action: Deny
    - order: 20
      protocolConfig:
        protocol: TCP
        tcp:
          ports: "8000-9000"
      action: Deny
  - sourceCIDRs:
       - fc00:f853:ccd:e793::0/64
    rules:
    - order: 10
      protocolConfig:
        protocol: ICMPv6
        icmpv6:
          icmpType: 128 #ICMPV6 Echo request
      action: Deny
----
+
A `<label_name>` and a `<label_value>` must exist on the node and must match the `nodeselector` label and value applied to the nodes you want the `ingressfirewallconfig` CR to run on. The `<label_value>` can be `true` or `false`. By using `nodeSelector` labels, you can target separate groups of nodes to apply different rules to using the `ingressfirewallconfig` CR.


[id="nw-ingress-node-firewall-zero-trust-example-cr_{context}"]
== Zero trust Ingress Node Firewall rules object example

Zero trust Ingress Node Firewall rules can provide additional security to multi-interface clusters. For example, you can use zero trust Ingress Node Firewall rules to drop all traffic on a specific interface except for SSH.

A complete configuration of a zero trust Ingress Node Firewall rule for a network-interface cluster is specified in the following example:

[IMPORTANT]
====
Users need to add all ports their application will use to their allowlist in the following case to ensure proper functionality.
====

.Example zero trust Ingress Node Firewall rules
[source,yaml]
----
apiVersion: ingressnodefirewall.openshift.io/v1alpha1
kind: IngressNodeFirewall
metadata:
 name: ingressnodefirewall-zero-trust
spec:
 interfaces:
 - eth1
 nodeSelector:
   matchLabels:
     <ingress_firewall_label_name>: <label_value>
 ingress:
 - sourceCIDRs:
      - 0.0.0.0/0
   rules:
   - order: 10
     protocolConfig:
       protocol: TCP
       tcp:
         ports: 22
     action: Allow
   - order: 20
     action: Deny
----