Skip to content

API docs: clarify ICMP related. #364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
k8s-ci-robot merged 1 commit into from
Apr 22, 2026
+78 −61
Merged

API docs: clarify ICMP related. #364

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 24 additions & 23 deletions apis/v1alpha2/clusternetworkpolicy_types.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,11 +188,11 @@ type ClusterNetworkPolicyIngressRule struct {
Name string `json:"name,omitempty"`

// Action specifies the effect this rule will have on matching
// traffic. Currently the following actions are supported:
// traffic. Currently, the following actions are supported:
//
// - Accept: Accepts the selected traffic, allowing it into
// the destination. No further ClusterNetworkPolicy or
// NetworkPolicy rules will be processed.
// - Accept: Accepts the selected traffic, including replies to that
Copy link
Copy Markdown
Contributor

@tssurya tssurya Apr 5, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We spoke a bit about this during AMS KubeCon,
but a note for future that since we have made this explicit we do need to consider this while designing the ICMP protocol match whether ICMP protocol match will also allow related or if its purely restricted to specific independent types and codes.
just highlighting it for history (no action required from this comment)

Copy link
Copy Markdown
Contributor

@danwinship danwinship Apr 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's some trickiness here, but I would hope that conntrack deals with it all for us.

If you allow ICMP pings, you would also have implicitly be allowing the replies to that ping, just like in the IP case.

// traffic and related ICMP traffic. No further ingress
// ClusterNetworkPolicy or NetworkPolicy rules will be processed.
//
// Note: while Accept ensures traffic is accepted by
// Kubernetes network policy, it is still possible that the
Expand Down Expand Up @@ -245,15 +245,15 @@ type ClusterNetworkPolicyEgressRule struct {
Name string `json:"name,omitempty"`

// Action specifies the effect this rule will have on matching
// traffic. Currently the following actions are supported:
// traffic. Currently, the following actions are supported:
//
// - Accept: Accepts the selected traffic, allowing it to
// egress. No further ClusterNetworkPolicy or NetworkPolicy
// rules will be processed.
// - Accept: Accepts the selected traffic, including replies to that
// traffic and related ICMP traffic. No further egress
// ClusterNetworkPolicy or NetworkPolicy rules will be processed
// but any ingress rules at the destination do apply.
//
// - Deny: Drops the selected traffic. No further
// ClusterNetworkPolicy or NetworkPolicy rules will be
// processed.
// - Deny: Drops the selected traffic. No further ClusterNetworkPolicy or
Copy link
Copy Markdown
Contributor

@tssurya tssurya Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recently learnt that networkpolicies when created mid way do expect to effect existing connections? so for both DENY and PASS it actually does include ICMP related as well for that connection?

Copy link
Copy Markdown
Contributor

@danwinship danwinship Apr 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For networkingv1.NetworkPolicy there is no official expectation about what happens when you create a NetworkPolicy that matches a pre-existing connection. For CNP we're leaning toward "it breaks existing connections" but we never finished that discussion (#305).

// NetworkPolicy rules will be processed.
//
// - Pass: Skips all further ClusterNetworkPolicy rules in the
// current tier for the selected traffic, and passes
Expand Down Expand Up @@ -288,20 +288,16 @@ type ClusterNetworkPolicyEgressRule struct {
type ClusterNetworkPolicyRuleAction string

const (
// ClusterNetworkPolicyRuleActionAccept indicates that
// matching traffic will be accepted and no further policy
// evaluation will be done. This is a final decision.
// ClusterNetworkPolicyRuleActionAccept stops further rule processing of
Copy link
Copy Markdown
Contributor

@tssurya tssurya Apr 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm interesting..I am trying to find the nuance/motivation behind the change here and for the other actions..
so ACCEPT in ingress rules being hit doesn't mean the policy stops being evaluated but we still evaluate the egress rules?
OR
is there something between policy v/s rules?

Copy link
Copy Markdown
Contributor Author

@fasaxc fasaxc Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Traffic from pod A to pod B goes through pod A's egress rules and pod B's ingress rules. The change was intended to hint that pod A's "egress accept" may still get blocked by pod B's ingress rules.

TBH I started just trying to make the language more direct. "stops and accepts" instead of "indicates that ..."

// this policy direction (Ingress/Egress) and accepts the traffic.
ClusterNetworkPolicyRuleActionAccept ClusterNetworkPolicyRuleAction = "Accept"
// ClusterNetworkPolicyRuleActionDeny indicates that matching traffic
// will be denied and no further policy evaluation will be done.
// This is a final decision.
// ClusterNetworkPolicyRuleActionDeny stops further rule processing and
// drops the traffic.
ClusterNetworkPolicyRuleActionDeny ClusterNetworkPolicyRuleAction = "Deny"
// ClusterNetworkPolicyRuleActionPass indicates that matching traffic
// will jump to the next tier evaluation. That means that all the rules
// with lower precedence at the same tier will be ignored,
// but evaluation will continue at the next tier.
// For example, if an Admin tier CNP uses Pass action,
// NetworkPolicy evaluation will happen next.
// ClusterNetworkPolicyRuleActionPass skips rules with lower precedence in
// the current tier and continues processing in the next tier. For example,
// if an Admin tier CNP uses Pass action, NetworkPolicy evaluation will
// happen next.
ClusterNetworkPolicyRuleActionPass ClusterNetworkPolicyRuleAction = "Pass"
)

Expand Down Expand Up @@ -380,6 +376,11 @@ type ClusterNetworkPolicyEgressPeer struct {
// or deny all IPv4 pod-to-pod traffic as well. If you don't want that,
// add a rule that Passes all pod traffic before the Networks rule.
//
// Networks matches both regular IP traffic and ICMP traffic to/from
// the specified CIDRs. For example, a Networks entry of "0.0.0.0/0"
// will match both IPv4 and ICMP traffic, while "::/0" will match
// both IPv6 and ICMPv6 traffic.
//
// Each item in Networks should be provided in the CIDR format and should be
// IPv4 or IPv6, for example "10.0.0.0/8" or "fd00::/8".
//
Expand Down
27 changes: 16 additions & 11 deletions config/crd/experimental/policy.networking.k8s.io_clusternetworkpolicies.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,15 +75,15 @@ spec:
action:
description: |-
Action specifies the effect this rule will have on matching
traffic. Currently the following actions are supported:
traffic. Currently, the following actions are supported:

- Accept: Accepts the selected traffic, allowing it to
egress. No further ClusterNetworkPolicy or NetworkPolicy
rules will be processed.
- Accept: Accepts the selected traffic, including replies to that
traffic and related ICMP traffic. No further egress
ClusterNetworkPolicy or NetworkPolicy rules will be processed
but any ingress rules at the destination do apply.

- Deny: Drops the selected traffic. No further
ClusterNetworkPolicy or NetworkPolicy rules will be
processed.
- Deny: Drops the selected traffic. No further ClusterNetworkPolicy or
NetworkPolicy rules will be processed.

- Pass: Skips all further ClusterNetworkPolicy rules in the
current tier for the selected traffic, and passes
Expand Down Expand Up @@ -373,6 +373,11 @@ spec:
or deny all IPv4 pod-to-pod traffic as well. If you don't want that,
add a rule that Passes all pod traffic before the Networks rule.

Networks matches both regular IP traffic and ICMP traffic to/from
the specified CIDRs. For example, a Networks entry of "0.0.0.0/0"
will match both IPv4 and ICMP traffic, while "::/0" will match
both IPv6 and ICMPv6 traffic.

Each item in Networks should be provided in the CIDR format and should be
IPv4 or IPv6, for example "10.0.0.0/8" or "fd00::/8".

Expand Down Expand Up @@ -588,11 +593,11 @@ spec:
action:
description: |-
Action specifies the effect this rule will have on matching
traffic. Currently the following actions are supported:
traffic. Currently, the following actions are supported:

- Accept: Accepts the selected traffic, allowing it into
the destination. No further ClusterNetworkPolicy or
NetworkPolicy rules will be processed.
- Accept: Accepts the selected traffic, including replies to that
traffic and related ICMP traffic. No further ingress
ClusterNetworkPolicy or NetworkPolicy rules will be processed.

Note: while Accept ensures traffic is accepted by
Kubernetes network policy, it is still possible that the
Expand Down
27 changes: 16 additions & 11 deletions config/crd/standard/policy.networking.k8s.io_clusternetworkpolicies.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,15 +75,15 @@ spec:
action:
description: |-
Action specifies the effect this rule will have on matching
traffic. Currently the following actions are supported:
traffic. Currently, the following actions are supported:

- Accept: Accepts the selected traffic, allowing it to
egress. No further ClusterNetworkPolicy or NetworkPolicy
rules will be processed.
- Accept: Accepts the selected traffic, including replies to that
traffic and related ICMP traffic. No further egress
ClusterNetworkPolicy or NetworkPolicy rules will be processed
but any ingress rules at the destination do apply.

- Deny: Drops the selected traffic. No further
ClusterNetworkPolicy or NetworkPolicy rules will be
processed.
- Deny: Drops the selected traffic. No further ClusterNetworkPolicy or
NetworkPolicy rules will be processed.

- Pass: Skips all further ClusterNetworkPolicy rules in the
current tier for the selected traffic, and passes
Expand Down Expand Up @@ -335,6 +335,11 @@ spec:
or deny all IPv4 pod-to-pod traffic as well. If you don't want that,
add a rule that Passes all pod traffic before the Networks rule.

Networks matches both regular IP traffic and ICMP traffic to/from
the specified CIDRs. For example, a Networks entry of "0.0.0.0/0"
will match both IPv4 and ICMP traffic, while "::/0" will match
both IPv6 and ICMPv6 traffic.

Each item in Networks should be provided in the CIDR format and should be
IPv4 or IPv6, for example "10.0.0.0/8" or "fd00::/8".

Expand Down Expand Up @@ -490,11 +495,11 @@ spec:
action:
description: |-
Action specifies the effect this rule will have on matching
traffic. Currently the following actions are supported:
traffic. Currently, the following actions are supported:

- Accept: Accepts the selected traffic, allowing it into
the destination. No further ClusterNetworkPolicy or
NetworkPolicy rules will be processed.
- Accept: Accepts the selected traffic, including replies to that
traffic and related ICMP traffic. No further ingress
ClusterNetworkPolicy or NetworkPolicy rules will be processed.

Note: while Accept ensures traffic is accepted by
Kubernetes network policy, it is still possible that the
Expand Down
5 changes: 5 additions & 0 deletions pkg/client/applyconfiguration/apis/v1alpha2/clusternetworkpolicyegresspeer.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

14 changes: 7 additions & 7 deletions pkg/client/applyconfiguration/apis/v1alpha2/clusternetworkpolicyegressrule.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

8 changes: 4 additions & 4 deletions pkg/client/applyconfiguration/apis/v1alpha2/clusternetworkpolicyingressrule.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

11 changes: 6 additions & 5 deletions site-src/api-overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -78,9 +78,10 @@ traffic, ClusterNetworkPolicy will enable administrators to set `Pass`,
be read as-is, i.e. there will not be any implicit isolation effects for the Pods
selected by the ClusterNetworkPolicy, as opposed to implicit deny NetworkPolicy rules imply.

- **Accept**: Accepts the selected traffic, allowing it into
the destination. No further ClusterNetworkPolicy or
NetworkPolicy rules will be processed.
- **Accept**: Accepts the selected traffic, including replies to that
traffic and related ICMP traffic (e.g. ICMP errors such as
"destination unreachable" or "packet too big"). No further
ClusterNetworkPolicy or NetworkPolicy rules will be processed.

- **Deny**: Drops the selected traffic. No further
ClusterNetworkPolicy or NetworkPolicy rules will be
Expand Down Expand Up @@ -119,8 +120,8 @@ before policies with higher priority values in the same tier.
### Rules

Each CNP should define at least one `Ingress` or `Egress` relevant in-cluster traffic flow
along with the associated Action that should occur. In each `gress` rule the user
should AT THE MINIMUM define an `Action`, and at least one `ClusterNetworkPolicyPeer`.
along with the associated Action that should occur. In each rule the user
should *at a minimum* define an `Action`, and at least one peer (`To` or `From` entry).
Optionally the user may also define select `Protocols` to filter traffic on and also
a name for each rule to make management and reporting easier for Admins.

Expand Down
Loading