Network policy docs clarifications #39875

npinaeva · 2023-03-09T11:02:24Z

Add "Pod lifecycle" section to the network policy docs.
Clarify network policy behaviour for hostNetwork pods
Clarify network policy behaviour for L2/L3 protocols

New sections should clarify some confusing aspect for the users, and become the base to build better-defined API for AdminNetworkPolicy.

The current version is intended for content reviews, and may not completely follow style guidelines, which will be fixed once we agree on the content.

k8s-ci-robot · 2023-03-09T11:02:32Z

Welcome @npinaeva!

It looks like this is your first PR to kubernetes/website 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/website has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

npinaeva · 2023-03-09T11:05:04Z

/cc @danwinship @astoycos

bradtopol · 2023-03-09T15:27:30Z

/retest

bradtopol · 2023-03-09T15:27:56Z

/recheck

bradtopol · 2023-03-09T15:30:48Z

@npinaeva This looks like it needs to build again.

git commit --allow-empty -m "empty commit to rerun tests"

sftim

Thanks. Here's some thoughts.

content/en/docs/concepts/services-networking/network-policies.md

sftim · 2023-03-09T16:19:22Z

~~I'll trigger a build in Netlify (we haven't got that hooked up to /retest in Prow - sorry about that)~~

Please rebase this against main - there's been a breaking change to the CVE feed format.

npinaeva · 2023-03-09T16:38:12Z

@sftim thanks for your feedback! I made some changes and left some questions, ptal :)

WillsonHG · 2023-03-09T21:32:03Z

/easycla

linux-foundation-easycla · 2023-03-09T21:32:07Z

The committers listed above are authorized under a signed CLA.

✅ login: npinaeva / name: Nadia Pinaeva (ae26b7e, cf80f24, 3082727, 9fd88db)

Arhell

/easycla

content/en/docs/concepts/services-networking/network-policies.md

netlify · 2023-03-10T10:42:15Z

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	`9fd88db`
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/652ea3a9734fb5000701d829
😎 Deploy Preview	https://deploy-preview-39875--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

content/en/docs/concepts/services-networking/network-policies.md

sftim

Some more thoughts

content/en/docs/concepts/services-networking/network-policies.md

npinaeva · 2023-07-13T13:48:18Z

hey @kbhawkey , thanks for asking! Yes I am still working on it, just waiting for some feedback :)

huntergregory · 2023-07-31T22:38:30Z

content/en/docs/concepts/services-networking/network-policies.md

+
+Once the NetworkPolicy is handled by a network plugin,
+
+1. All newly created pods affected by a given NetworkPolicy will be isolated before 


pods...will be isolated before they are started

I believe this bullet point is incorrect. This requirement does not even seem possible for a NetworkPolicy implementation which is disjoint from the CNI (e.g. Azure NPM).

Assuming that isolation here means blocking traffic. Please correct me if I'm misinterpreting.

Your interpretation, and the bullet point, are correct. A correct implementation of NetworkPolicy must ensure that pods are not able to bypass pre-existing NetworkPolicies at any point in their lifecycle.

If pods aren't fully subject to NetworkPolicy at startup time, then an attacker can exploit that race condition by continuously creating new pods and trying to make connections that should have been blocked, until they eventually succeed, and then they can do whatever bad thing the NetworkPolicy was supposed to have been preventing them from doing, rendering the NetworkPolicy useless.

This requirement does not even seem possible for a NetworkPolicy implementation which is disjoint from the CNI (e.g. Azure NPM).

Note that it's allowed for pods to come up more restricted than they're supposed to be, just not less restricted. So if the NP impl can create a fallback "block everything else" rule that would apply to newly-created pods, then it could do that, and then the pod would come up fully isolated until the NP impl has a chance to fix it up.

If the CNI plugin works in such a way that the NP implementation can't create rules that would apply to a new pod before that pod exists (eg, the CNI plugin is creating a new interface), then there is probably no way to correctly implement NetworkPolicy independently of the CNI plugin. (Though there are small-ish modifications that could be made to the plugin to make this possible. Eg, you could add a flag to the CNI plugin saying "make newly-created pods start out completely isolated", and then it would depend on the existence of some external NP impl to fix the pods up after that.)

make newly-created pods start out completely isolated

(aside)
That sounds like a very reasonable workaround, especially given the (alpha) PodReadyToStartContainers condition - the new Pod might be fully isolated, then add packet filtering rules, then remove the full isolation, and finally assert PodReadyToStartContainers. But: it does need the network plugin to play at least some role.

Maybe there's an interface or API that we can define so that a network plugin waits between setting up IP networking for a Pod and asserting that condition. That would help standalone NetworkPolicy implementations to provide the guarantees we expect.

sftim

Thanks. Please be sure to address https://github.com/kubernetes/website/pull/39875/files#r1168499297

sftim · 2023-08-16T13:40:53Z

content/en/docs/concepts/services-networking/network-policies.md

If you're willing to update it, the section about SCTPSupport is stale.

can you please elaborate?

It's now generally available, no need to enable it and no option to disable it.

The whole "SCTP support" section can probably just go away; once you get rid of the stuff about the feature gate, all that's left is a warning that SCTP NetworkPolicies only work if your network plugin supports SCTP, which is kind of a no-brainer.

so do you want me to add another commit to remove SCTP support section? This PR doesn't touch SCTP yet, so maybe it would be a better option to have it as another PR (knowing for how ling we've been discussing this one)?

I added one more commit for SCTP, I left the note about plugin SCTP support, since it looks fine to me in the new "Network traffic filtering" section that talks about protocols. ptal

sftim · 2023-08-16T13:42:41Z

content/en/docs/concepts/services-networking/network-policies.md

+that pod may be started unprotected, and isolation rules will be applied when 
+the NetworkPolicy handling is completed.
+
+Once the NetworkPolicy is handled by a network plugin,


Suggested change

Once the NetworkPolicy is handled by a network plugin,

For a cluster with a conformant networking plugin and a conformant implementation of

NetworkPolicy:

It is not exactly equivalent, but I added this message as a not at the beginning of the Pod lifecycle section

(IMO we don't need this note; the entire page only applies to plugins that implement NetworkPolicy, and the entire /services-networking/ section only (fully) applies to clusters with conformant networking plugins.)

yeah good point, @sftim what do you think?

the entire page only applies to plugins that implement NetworkPolicy

The conceptual explanation is relevant even if your cluster is using a network plugin that has never heard of NetworkPolicy.

We should document somewhere what we expect from a conforming network plugin. Otherwise, it's not fair on plugin authors - they need to know what's expected and shouldn't have to become detectives in meeting that end.

The way we inform implementers might once day be through a separate reference page, but for now this concept page is the closest thing we have.

content/en/docs/concepts/services-networking/network-policies.md

sftim · 2023-08-16T13:46:34Z

content/en/docs/concepts/services-networking/network-policies.md

+Every created NetworkPolicy will be handled by a network plugin eventually, but there is no
+way to tell from the Kubernetes API when exactly that happens. 


Suggested change

Every created NetworkPolicy will be handled by a network plugin eventually, but there is no

way to tell from the Kubernetes API when exactly that happens.

Every created NetworkPolicy will be handled by a network plugin eventually, but there is no

way to tell from the Kubernetes API when exactly the policy is being enforced for new or

existing Pods.

(As an example: if you write a NetworkPolicy implementation that begins enforcing the policy from

midnight the next day, that conforms to Kubernetes' requirements - but of course could be very

frustrating for cluster administrators).

This suggestion looks more implementor-focused to me, and I think we were going to outline implementor guideline in a different document, wdyt?
Another note - I don't think the implementation you described will pass conformance tests for network policy, so maybe it is not really conformant?

There are no conformance tests for NetworkPolicy, but it wouldn't pass the ordinary e2e tests.

I think we were going to outline implementor guideline in a different document

yeah, there's been discussion about that (partly inspired by this PR). https://groups.google.com/g/kubernetes-sig-network/c/Ga9SWGs00k4 / kubernetes/community#7421

sftim · 2023-08-16T13:46:52Z

content/en/docs/concepts/services-networking/network-policies.md

+The only way to check if the network policy is applied to a pod, is to run a connectivity check
+from that pod.


Even then, you might not be able to tell (I think).

that is right, e.g. connections may be dropped for another reason, but I am not sure if adding these details will improve or over-complicate this section, wdyt?

I'd omit the sentence. I'm wary about the risk of misleading people.

(I don't want someone to think “Right, so this Pod shouldn't be able to talk to a Pod in namespace untrusted. I tried and failed, so my policy is working. Job done, !”)

danwinship · 2023-08-22T14:51:48Z

content/en/docs/concepts/services-networking/network-policies.md

+Because they are applied at Pod level, NetworkPolicies apply equally to init containers,
+sidecar containers, and regular containers.
+
+2. Allow rules will be applied eventually after the isolation rules (that includes applying both at the same time).


"Allow rules will be applied eventually after the isolation rules (or may be applied at the same time)."

danwinship · 2023-08-22T14:52:10Z

content/en/docs/concepts/services-networking/network-policies.md

+from that pod.
+
+The pods must be resilient against being started up with different network
+connectivity than expected. If the pod needs to make sure it has expected network


"Therefore, pods must be resilient..."

danwinship · 2023-08-22T14:52:56Z

content/en/docs/concepts/services-networking/network-policies.md

+The pods must be resilient against being started up with different network
+connectivity than expected. If the pod needs to make sure it has expected network
+connectivity before being started, you can use an [init container](/docs/concepts/workloads/pods/init-containers/)
+that will run required connectivity checks before starting the app containers.


"...before letting the app containers start." or "...before kubelet starts the app containers".

danwinship · 2023-08-22T14:54:24Z

content/en/docs/concepts/services-networking/network-policies.md

+   ```
+   may apply ingress and egress rules to all connections with nodeA IP, or just ignore
+   that pod as if it didn't match the selector, or do something else.
+2. a `hostNetwork` pod is selected by `ingress` or `egress` rules.


2. a `hostNetwork` pod is selected by a `podSelector` in an `ingress` or `egress` rule.

(since there's the ipBlock case too, but you don't talk about that in this bullet point)

danwinship · 2023-08-22T14:55:54Z

(left some other comments up above in earlier threads too)

sftim · 2023-08-23T17:11:37Z

so do you want me to add another commit to remove SCTP support section? This PR doesn't touch SCTP yet, so maybe it would be a better option to have it as another PR (knowing for how ling we've been discussing this one)?

You must fix the mandatory corrctive feedback about undefined behavior and get that update tech-reviewed. You can also address the optional feedback about SCTP if you'd like to.

npinaeva · 2023-09-20T10:47:54Z

@danwinship can you please tal at the hostNetwork section?
@sftim can you please check the sctp changes?

danwinship

(mostly editorial comments, except for the hostNetwork section, which must be fixed)

danwinship · 2023-10-16T18:59:49Z

content/en/docs/concepts/services-networking/network-policies.md

+When a new NetworkPolicy object is created, it may take some for a network plugin
+to handle the new object. If the pod that is affected by a NetworkPolicy
+is created before the network plugin has completed NetworkPolicy handling,
+that pod may be started unprotected, and isolation rules will be applied when 
+the NetworkPolicy handling is completed.


Suggested change

When a new NetworkPolicy object is created, it may take some for a network plugin

to handle the new object. If the pod that is affected by a NetworkPolicy

is created before the network plugin has completed NetworkPolicy handling,

that pod may be started unprotected, and isolation rules will be applied when

the NetworkPolicy handling is completed.

When a new NetworkPolicy object is created, it may take some time for a network plugin

to handle the new object. If a pod that is affected by a NetworkPolicy

is created before the network plugin has completed NetworkPolicy handling,

that pod may be started unprotected, and isolation rules will be applied when

the NetworkPolicy handling is completed.

danwinship · 2023-10-16T19:15:38Z

content/en/docs/concepts/services-networking/network-policies.md

+that pod may be started unprotected, and isolation rules will be applied when 
+the NetworkPolicy handling is completed.
+
+Once the NetworkPolicy is handled by a network plugin,


(IMO we don't need this note; the entire page only applies to plugins that implement NetworkPolicy, and the entire /services-networking/ section only (fully) applies to clusters with conformant networking plugins.)

danwinship · 2023-10-16T19:22:16Z

content/en/docs/concepts/services-networking/network-policies.md

+sidecar containers, and regular containers.
+
+2. Allow rules will be applied eventually after the isolation rules (or may be applied at the same time).
+In the worst case, a newly created pod may have no network connectivity at all, if


Suggested change

In the worst case, a newly created pod may have no network connectivity at all, if

In the worst case, a newly created pod may have no network connectivity at all when it is first started, if

danwinship · 2023-10-16T19:26:34Z

content/en/docs/concepts/services-networking/network-policies.md

+Therefore, pods must be resilient against being started up with different network
+connectivity than expected. If the pod needs to make sure it has expected network
+connectivity before being started, you can use an [init container](/docs/concepts/workloads/pods/init-containers/)
+that will run required connectivity checks before kubelet starts the app containers.


As Tim notes, this won't work for checking "negative connectivity", so it might be good to clarify that this is only for the "positive connectivity" case. "If you need to make sure the pod can reach certain destinations before being started, you can use an init container to wait for those destinations to be reachable before kubelet starts the app containers."

danwinship · 2023-10-16T19:34:48Z

content/en/docs/concepts/services-networking/network-policies.md

+
+## NetworkPolicy and `hostNetwork` pods
+
+NetworkPolicy behaviour for `hostNetwork` pods is undefined, but should be limited with 2 possibilities:


Suggested change

NetworkPolicy behaviour for `hostNetwork` pods is undefined, but should be limited with 2 possibilities:

NetworkPolicy behaviour for `hostNetwork` pods is undefined, but it should be limited to 2 possibilities:

danwinship · 2023-10-16T19:36:50Z

content/en/docs/concepts/services-networking/network-policies.md

+- network plugin can distinguish `hostNetwork` pod traffic from any other traffic and will apply
+  NetworkPolicy to it


Suggested change

- network plugin can distinguish `hostNetwork` pod traffic from any other traffic and will apply

NetworkPolicy to it

- The network plugin can distinguish `hostNetwork` pod traffic from all other traffic

(including being able to distinguish traffic from different `hostNetwork` pods on

the same node), and will apply NetworkPolicy to `hostNetwork` pods just like it does

to pod-network pods.

danwinship · 2023-10-16T19:39:06Z

content/en/docs/concepts/services-networking/network-policies.md

+NetworkPolicy behaviour for `hostNetwork` pods is undefined, but should be limited with 2 possibilities:
+- network plugin can distinguish `hostNetwork` pod traffic from any other traffic and will apply
+  NetworkPolicy to it
+- network plugin ignores `hostNetwork` pods


Suggested change

- network plugin ignores `hostNetwork` pods

- The network plugin cannot properly distinguish `hostNetwork` pod traffic, and so it ignores `hostNetwork` pods when matching `podSelector` and `namespaceSelector`. Traffic to/from `hostNetwork` pods is treated the same as all other traffic to/from the node IP. (This is the most common implementation.)

It's not ignoring the pods entirely; eg, a pod which is isolated for ingress will still reject connections from hostNetwork pods.

danwinship · 2023-10-16T19:40:51Z

content/en/docs/concepts/services-networking/network-policies.md

+     ...
+   ```
+
+2. a `hostNetwork` pod is selected by a `podSelector` in an `ingress` or `egress` rule.


Suggested change

2. a `hostNetwork` pod is selected by a `podSelector` in an `ingress` or `egress` rule.

2. a `hostNetwork` pod is selected by a `podSelector` or `namespaceSelector` in an `ingress` or `egress` rule.

Signed-off-by: Nadia Pinaeva <npinaeva@redhat.com>

"Network traffic filtering" section Signed-off-by: Nadia Pinaeva <npinaeva@redhat.com>

sftim

I'd like a technical review from @kubernetes/sig-network-misc

sftim · 2023-11-07T13:16:01Z

content/en/docs/concepts/services-networking/network-policies.md


 {{< note >}}
 You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP
 protocol NetworkPolicies.
 {{< /note >}}

+When a `deny all` network policy is defined, it is only guaranteed to deny TCP, UDP and SCTP


(nit)

Suggested change

When a `deny all` network policy is defined, it is only guaranteed to deny TCP, UDP and SCTP

When a _deny all_ network policy is defined, it is only guaranteed to deny TCP, UDP and SCTP

sftim · 2023-11-07T13:16:35Z

content/en/docs/concepts/services-networking/network-policies.md


 {{< note >}}
 You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP
 protocol NetworkPolicies.
 {{< /note >}}

+When a `deny all` network policy is defined, it is only guaranteed to deny TCP, UDP and SCTP
+connections. For other protocols, such as ARP or ICMP, the behaviour is undefined.


(optionally)

Suggested change

connections. For other protocols, such as ARP or ICMP, the behaviour is undefined.

connections. For other protocols, such as ARP or ICMP, the behaviour is undefined: it is up to

each network plugin to decide what behavior to adopt and implement.

sftim · 2023-11-07T13:19:29Z

content/en/docs/concepts/services-networking/network-policies.md

+that pod may be started unprotected, and isolation rules will be applied when 
+the NetworkPolicy handling is completed.
+
+Once the NetworkPolicy is handled by a network plugin,


the entire page only applies to plugins that implement NetworkPolicy

The conceptual explanation is relevant even if your cluster is using a network plugin that has never heard of NetworkPolicy.

We should document somewhere what we expect from a conforming network plugin. Otherwise, it's not fair on plugin authors - they need to know what's expected and shouldn't have to become detectives in meeting that end.

The way we inform implementers might once day be through a separate reference page, but for now this concept page is the closest thing we have.

danwinship · 2023-11-09T15:44:58Z

/lgtm

I'd like a technical review from @kubernetes/sig-network-misc

Sure, that's what I was doing all along. I declare this PR to be technically accurate!

k8s-ci-robot · 2023-11-09T15:45:07Z

LGTM label has been added.

Git tree hash: a9fc7ecc2e8284aed8052790b331247fec345282

sftim · 2023-11-09T16:36:28Z

This is good to publish.

/approve

k8s-ci-robot · 2023-11-09T16:36:38Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sftim

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~content/en/OWNERS~~ [sftim]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

k8s-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Mar 9, 2023

k8s-ci-robot requested a review from danwinship March 9, 2023 11:02

k8s-ci-robot added the language/en Issues or PRs related to English language label Mar 9, 2023

k8s-ci-robot requested a review from thockin March 9, 2023 11:02

k8s-ci-robot added the sig/docs Categorizes an issue or PR as relevant to SIG Docs. label Mar 9, 2023

k8s-ci-robot requested a review from astoycos March 9, 2023 11:05

sftim reviewed Mar 9, 2023

View reviewed changes

npinaeva force-pushed the netpol-pod-start branch from fb6e1dd to ec490df Compare March 9, 2023 16:36

k8s-ci-robot added the cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. label Mar 9, 2023

Arhell reviewed Mar 10, 2023

View reviewed changes

tengqm reviewed Mar 10, 2023

View reviewed changes

k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Mar 10, 2023

npinaeva force-pushed the netpol-pod-start branch from ec490df to c81237a Compare March 10, 2023 10:31

This was referenced Mar 10, 2023

Document network policy behaviour for host network pods kubernetes-sigs/network-policy-api#73

Closed

Should protocol be at a higher level than ports? kubernetes-sigs/network-policy-api#72

Closed

npinaeva force-pushed the netpol-pod-start branch from c81237a to ea01aa6 Compare March 10, 2023 17:58

sftim reviewed Mar 10, 2023

View reviewed changes

content/en/docs/concepts/services-networking/network-policies.md Show resolved Hide resolved

npinaeva force-pushed the netpol-pod-start branch from ea01aa6 to 2ea313b Compare March 14, 2023 12:21

sftim reviewed Mar 14, 2023

View reviewed changes

huntergregory reviewed Jul 31, 2023

View reviewed changes

sftim reviewed Aug 16, 2023

View reviewed changes

npinaeva force-pushed the netpol-pod-start branch from ed1190b to d2a900e Compare August 16, 2023 19:22

danwinship reviewed Aug 22, 2023

View reviewed changes

npinaeva force-pushed the netpol-pod-start branch from d2a900e to 040523b Compare August 24, 2023 11:31

k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Aug 24, 2023

danwinship reviewed Oct 16, 2023

View reviewed changes

npinaeva added 4 commits October 17, 2023 17:09

Add "Pod lifecycle" section to the network policy docs.

ae26b7e

Signed-off-by: Nadia Pinaeva <npinaeva@redhat.com>

Clarify network policy behaviour for hostNetwork pods

cf80f24

Signed-off-by: Nadia Pinaeva <npinaeva@redhat.com>

Clarify network policy behaviour for L2/L3 protocols

3082727

Signed-off-by: Nadia Pinaeva <npinaeva@redhat.com>

Remove "SCTP support" section, move plugin support note to the

9fd88db

"Network traffic filtering" section Signed-off-by: Nadia Pinaeva <npinaeva@redhat.com>

npinaeva force-pushed the netpol-pod-start branch from 6c09ac9 to 9fd88db Compare October 17, 2023 15:09

huntergregory mentioned this pull request Nov 2, 2023

REQUEST: New membership for huntergregory kubernetes/org#4573

Closed

9 tasks

sftim reviewed Nov 7, 2023

View reviewed changes

k8s-ci-robot added the sig/network Categorizes an issue or PR as relevant to SIG Network. label Nov 7, 2023

k8s-ci-robot assigned danwinship Nov 9, 2023

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 9, 2023

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 9, 2023

k8s-ci-robot merged commit 9d663cd into kubernetes:main Nov 9, 2023
6 checks passed

windsonsea mentioned this pull request Nov 10, 2023

[zh] Add translations to network-policies.md #43866

Merged

npinaeva deleted the netpol-pod-start branch November 14, 2023 09:16


		Once the NetworkPolicy is handled by a network plugin,

		1. All newly created pods affected by a given NetworkPolicy will be isolated before

	Once the NetworkPolicy is handled by a network plugin,
	For a cluster with a conformant networking plugin and a conformant implementation of
	NetworkPolicy:

		Every created NetworkPolicy will be handled by a network plugin eventually, but there is no
		way to tell from the Kubernetes API when exactly that happens.

-Every created NetworkPolicy will be handled by a network plugin eventually, but there is no
-way to tell from the Kubernetes API when exactly that happens.
+Every created NetworkPolicy will be handled by a network plugin eventually, but there is no
+way to tell from the Kubernetes API when exactly the policy is being enforced for new or
+existing Pods.
+(As an example: if you write a NetworkPolicy implementation that begins enforcing the policy from
+midnight the next day, that conforms to Kubernetes' requirements - but of course could be very
+frustrating for cluster administrators).

		The only way to check if the network policy is applied to a pod, is to run a connectivity check
		from that pod.

	In the worst case, a newly created pod may have no network connectivity at all, if
	In the worst case, a newly created pod may have no network connectivity at all when it is first started, if


		## NetworkPolicy and `hostNetwork` pods

		NetworkPolicy behaviour for `hostNetwork` pods is undefined, but should be limited with 2 possibilities:

		- network plugin can distinguish `hostNetwork` pod traffic from any other traffic and will apply
		NetworkPolicy to it

-- network plugin can distinguish `hostNetwork` pod traffic from any other traffic and will apply
-  NetworkPolicy to it
+- The network plugin can distinguish `hostNetwork` pod traffic from all other traffic
+  (including being able to distinguish traffic from different `hostNetwork` pods on
+  the same node), and will apply NetworkPolicy to `hostNetwork` pods just like it does
+  to pod-network pods.

	- network plugin ignores `hostNetwork` pods
	- The network plugin cannot properly distinguish `hostNetwork` pod traffic, and so it ignores `hostNetwork` pods when matching `podSelector` and `namespaceSelector`. Traffic to/from `hostNetwork` pods is treated the same as all other traffic to/from the node IP. (This is the most common implementation.)

	When a `deny all` network policy is defined, it is only guaranteed to deny TCP, UDP and SCTP
	When a _deny all_ network policy is defined, it is only guaranteed to deny TCP, UDP and SCTP

	connections. For other protocols, such as ARP or ICMP, the behaviour is undefined.
	connections. For other protocols, such as ARP or ICMP, the behaviour is undefined: it is up to
	each network plugin to decide what behavior to adopt and implement.

Network policy docs clarifications #39875

Network policy docs clarifications #39875

Conversation

npinaeva commented Mar 9, 2023

k8s-ci-robot commented Mar 9, 2023

npinaeva commented Mar 9, 2023

bradtopol commented Mar 9, 2023

bradtopol commented Mar 9, 2023

bradtopol commented Mar 9, 2023

sftim left a comment

Choose a reason for hiding this comment

sftim commented Mar 9, 2023 • edited Loading

npinaeva commented Mar 9, 2023

WillsonHG commented Mar 9, 2023

linux-foundation-easycla bot commented Mar 9, 2023 • edited Loading

Arhell left a comment

Choose a reason for hiding this comment

netlify bot commented Mar 10, 2023 • edited Loading

✅ Pull request preview available for checking

sftim left a comment

Choose a reason for hiding this comment

npinaeva commented Jul 13, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sftim left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danwinship commented Aug 22, 2023

sftim commented Aug 23, 2023

npinaeva commented Sep 20, 2023

danwinship left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sftim left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danwinship commented Nov 9, 2023

k8s-ci-robot commented Nov 9, 2023

sftim commented Nov 9, 2023

k8s-ci-robot commented Nov 9, 2023

sftim commented Mar 9, 2023 •

edited

Loading

linux-foundation-easycla bot commented Mar 9, 2023 •

edited

Loading

netlify bot commented Mar 10, 2023 •

edited

Loading