Code change:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

Related discussion:
text: ## What you can't do with network policies (at least, not yet) <del> As of Kubernetes {{< skew currentVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. </del> <ins> As of Kubernetes {{< skew currentVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers.  In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. </ins> <del> - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy). </del> <ins> - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy). </ins> - Anything TLS related (use a service mesh or ingress controller for this). <del> - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically). - Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). </del> <ins> - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically). - Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). </ins> - Creation or management of "Policy requests" that are fulfilled by a third party. <del> - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). </del> <ins> - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). </ins> - Advanced policy querying and reachability tooling. - The ability to log network security events (for example connections that are blocked or accepted). <del> - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). </del> <ins> - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). </ins> ## {{% heading "whatsnext" %}} - See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) walkthrough for further examples. <del> - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. </del> <ins> - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. </ins>