1"use strict";(self.webpackChunktigera_docs=self.webpackChunktigera_docs||[]).push([[1150],{3905:(e,t,o)=>{o.d(t,{Zo:()=>p,kt:()=>h});var n=o(67294);function i(e,t,o){return t in e?Object.defineProperty(e,t,{value:o,enumerable:!0,configurable:!0,writable:!0}):e[t]=o,e}function r(e,t){var o=Object.keys(e);if(Object.getOwnPropertySymbols){var n=Object.getOwnPropertySymbols(e);t&&(n=n.filter((function(t){return Object.getOwnPropertyDescriptor(e,t).enumerable}))),o.push.apply(o,n)}return o}function a(e){for(var t=1;t<arguments.length;t++){var o=null!=arguments[t]?arguments[t]:{};t%2?r(Object(o),!0).forEach((function(t){i(e,t,o[t])})):Object.getOwnPropertyDescriptors?Object.defineProperties(e,Object.getOwnPropertyDescriptors(o)):r(Object(o)).forEach((function(t){Object.defineProperty(e,t,Object.getOwnPropertyDescriptor(o,t))}))}return e}function s(e,t){if(null==e)return{};var o,n,i=function(e,t){if(null==e)return{};var o,n,i={},r=Object.keys(e);for(n=0;n<r.length;n++)o=r[n],t.indexOf(o)>=0||(i[o]=e[o]);return i}(e,t);if(Object.getOwnPropertySymbols){var r=Object.getOwnPropertySymbols(e);for(n=0;n<r.length;n++)o=r[n],t.indexOf(o)>=0||Object.prototype.propertyIsEnumerable.call(e,o)&&(i[o]=e[o])}return i}var l=n.createContext({}),c=function(e){var t=n.useContext(l),o=t;return e&&(o="function"==typeof e?e(t):a(a({},t),e)),o},p=function(e){var t=c(e.components);return n.createElement(l.Provider,{value:t},e.children)},d={inlineCode:"code",wrapper:function(e){var t=e.children;return n.createElement(n.Fragment,{},t)}},u=n.forwardRef((function(e,t){var o=e.components,i=e.mdxType,r=e.originalType,l=e.parentName,p=s(e,["components","mdxType","originalType","parentName"]),u=c(o),h=i,y=u["".concat(l,".").concat(h)]||u[h]||d[h]||r;return o?n.createElement(y,a(a({ref:t},p),{},{components:o})):n.createElement(y,a({ref:t},p))}));function h(e,t){var o=arguments,i=t&&t.mdxType;if("string"==typeof e||i){var r=o.length,a=new Array(r);a[0]=u;var s={};for(var l in t)hasOwnProperty.call(t,l)&&(s[l]=t[l]);s.originalType=e,s.mdxType="string"==typeof e?e:i,a[1]=s;for(var c=2;c<r;c++)a[c]=o[c];return n.createElement.apply(null,a)}return n.createElement.apply(null,o)}u.displayName="MDXCreateElement"},58357:(e,t,o)=>{o.r(t),o.d(t,{assets:()=>l,contentTitle:()=>a,default:()=>d,frontMatter:()=>r,metadata:()=>s,toc:()=>c});var n=o(87462),i=(o(67294),o(3905));const r={description:"Learn about network policy!"},a="About Network Policy",s={unversionedId:"about/about-network-policy",id:"version-3.25/about/about-network-policy",title:"About Network Policy",description:"Learn about network policy!",source:"@site/calico_versioned_docs/version-3.25/about/about-network-policy.mdx",sourceDirName:"about",slug:"/about/about-network-policy",permalink:"/calico/3.25/about/about-network-policy",draft:!1,editUrl:"https://github.com/tigera/docs/edit/main/calico_versioned_docs/version-3.25/about/about-network-policy.mdx",tags:[],version:"3.25",frontMatter:{description:"Learn about network policy!"},sidebar:"calicoSidebar",previous:{title:"About Kubernetes Networking",permalink:"/calico/3.25/about/about-k8s-networking"},next:{title:"About Kubernetes Services",permalink:"/calico/3.25/about/about-kubernetes-services"}},l={},c=[{value:"What is network policy?",id:"what-is-network-policy",level:2},{value:"Why is network policy important?",id:"why-is-network-policy-important",level:2},{value:"Kubernetes network policy",id:"kubernetes-network-policy",level:2},{value:"Calico network policy",id:"calico-network-policy",level:2},{value:"Benefits of using Calico for network policy",id:"benefits-of-using-calico-for-network-policy",level:2},{value:"Full Kubernetes network policy support",id:"full-kubernetes-network-policy-support",level:3},{value:"Richer network policy",id:"richer-network-policy",level:3},{value:"Mix Kubernetes and Calico network policy",id:"mix-kubernetes-and-calico-network-policy",level:3},{value:"Ability to protect hosts and VMs",id:"ability-to-protect-hosts-and-vms",level:3},{value:"Integrates with Istio",id:"integrates-with-istio",level:3},{value:"Extendable with Calico Enterprise",id:"extendable-with-calico-enterprise",level:3},{value:"Best practices for network policies",id:"best-practices-for-network-policies",level:2}
1,{value:"Ingress and egress",id:"ingress-and-egress",level:3},{value:"Policy schemas",id:"policy-schemas",level:3},{value:"Default deny",id:"default-deny",level:3},{value:"Hierarchical policy",id:"hierarchical-policy",level:3}],p={toc:c};function d(e){let{components:t,...r}=e;return(0,i.kt)("wrapper",(0,n.Z)({},p,r,{components:t,mdxType:"MDXLayout"}),(0,i.kt)("h1",{id:"about-network-policy"},"About Network Policy"),(0,i.kt)("admonition",{type:"note"},(0,i.kt)("p",{parentName:"admonition"},"This guide provides optional background education, including\neducation that is not specific to Calico.")),(0,i.kt)("p",null,"Kubernetes and Calico provide network policy APIs to help you secure your workloads."),(0,i.kt)("p",null,"In this guide you will learn:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"What network policy is and why it is important."),(0,i.kt)("li",{parentName:"ul"},"The differences between Kubernetes and Calico network policies and when you might want to use each."),(0,i.kt)("li",{parentName:"ul"},"Some best practices for using network policy.")),(0,i.kt)("h2",{id:"what-is-network-policy"},"What is network policy?"),(0,i.kt)("p",null,"Network policy is the primary tool for securing a Kubernetes network. It allows you to easily restrict the network\ntraffic in your cluster so only the traffic that you want to flow is allowed."),(0,i.kt)("p",null,"To understand the significance of network policy, let's briefly explore how network security was typically achieved\nprior to network policy. Historically in enterprise networks, network security was provided by designing a physical\ntopology of network devices (switches, routers, firewalls) and their associated configuration. The physical topology\ndefined the security boundaries of the network. In the first phase of virtualization, the same network and network\ndevice constructs were virtualized in the cloud, and the same techniques for creating specific network topologies of\n(virtual) network devices were used to provide network security. Adding new applications or services often required\nadditional network design to update the network topology and network device configuration to provide the desired\nsecurity."),(0,i.kt)("p",null,"In contrast, the ",(0,i.kt)("a",{parentName:"p",href:"/calico/3.25/about/about-k8s-networking"},"Kubernetes network model"),' defines a "flat"\nnetwork in which every pod can communicate with all other pods in the cluster using pod IP addresses. This approach\nmassively simplifies network design and allows new workloads to be scheduled dynamically anywhere in the cluster with no\ndependencies on the network design.'),(0,i.kt)("p",null,"In this model, rather than network security being defined by network topology boundaries, it is defined using network\npolicies that are independent of the network topology. Network policies are further abstracted from the network by using\nlabel selectors as their primary mechanism for defining which workloads can talk to which w
1orkloads, rather than IP\naddresses or IP address ranges."),(0,i.kt)("h2",{id:"why-is-network-policy-important"},"Why is network policy important?"),(0,i.kt)("p",null,"In an age where attackers are becoming more and more sophisticated, network security as a line of defense is more important\nthan ever."),(0,i.kt)("p",null,"While you can (and should) use firewalls to restrict traffic at the perimeters of your network (commonly referred to as\nnorth-south traffic), their ability to police Kubernetes traffic is often limited to a granularity of the cluster as a\nwhole, rather than to specific groups of pods, due to the dynamic nature of pod scheduling and pod IP addresses. In\naddition, the goal of most attackers once they gain a small foothold inside the perimeter is to move laterally (commonly\nreferred to as east-west) to gain access to higher value targets, which perimeter based firewalls can't police against."),(0,i.kt)("p",null,"Network policy on the other hand is designed for the dynamic nature of Kubernetes by following the standard Kubernetes\nparadigm of using label selectors to define groups of pods, rather than IP addresses. And because network policy is\nenforced within the cluster itself it can police both north-south and east-west traffic."),(0,i.kt)("p",null,'Network policy represents an important evolution of network security, not just because it handles the dynamic nature of\nmodern microservices, but because it empowers dev and devops engineers to easily define network security themselves,\nrather than needing to learn low-level networking details or raise tickets with a separate team responsible for managing\nfirewalls. Network policy makes it easy to define intent, such as "only this microservice gets to connect to the\ndatabase", write that intent as code (typically in YAML files), and integrate authoring of network policies into git\nworkflows and CI/CD processes.'),(0,i.kt)("admonition",{type:"note"},(0,i.kt)("p",{parentName:"admonition"},"Note: Calico and Calico Enterprise offer capabilities that can help perimeter firewalls integrate\nmore tightly with Kubernetes. However, this does not remove the need or value of network policies within the cluster itself.)")),(0,i.kt)("h2",{id:"kubernetes-network-policy"},"Kubernetes network policy"),(0,i.kt)("p",null,"Kubernetes network policies are defined using the Kubernetes ",(0,i.kt)("a",{parentName:"p",href:"https://kubernetes.io/docs/reference/kubernetes-api/policy-resources/network-policy-v1/"},"NetworkPolicy")," resource."),(0,i.kt)("p",null,"The main features of Kubernetes network policies are:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"Policies are namespace scoped (i.e. you create them within the context of a specific namespace just like, for example, pods)"),(0,i.kt)("li",{parentName:"ul"},"Policies are applied to pods using label selectors"),(0,i.kt)("li",{parentName:"ul"},"Policy rules can specify the traffic that is allowed to/from other pods, namespaces, or CIDRs"),(0,i.kt)("li",{parentName:"ul"},"Policy rules can specify protocols (TCP, UDP, SCTP), named ports or port numbers")),(0,i.kt)("p",null,"Kubernetes itself does not enforce network policies, and instead delegates their enforcement to network plugins. Most\nnetwork plugins implement the mainline elements of Kubernetes network policies, though not all implement every feature\nof the specification. (Calico does implement every feature, and was the original reference implementation of Kubernetes\nnetwork policies.)"),(0,i.kt)("p",null,"To learn more about Kubernetes network policies, read the ",(0,i.kt)("a",{parentName:"p",href:"/calico/3.25/network-policy/get-started/kubernetes-policy/kubernetes-network-policy"},"Get started with Kubernetes network policy"),"\nguide."),(0,i.kt)("h2",{id:"calico-network-policy"},"Calico network policy"),(0,i.kt)("p",null,"In addition to enforcing Kubernetes network policy, Calico supports its own\nnamespaced ",(0,i.kt)("a",{parentName:"p",href:"/calico/3.25/reference/resources/networkpolicy"},"NetworkPolicy")," and non-namespaced\n",(0,i.kt)("a",{parentName:"p",href:"/calico/3.25/reference/resources/globalnetworkpolicy"},"GlobalNetworkPolicy")," resources, which provide additional\nfeatures beyond those supported by Kubernetes network policy. This includes support for:"),(0,i.kt)("ul",null,(0,i.kt)("li",{parentName:"ul"},"policy ordering/priority"),(0,i.kt)("li",{parentName:"ul"},"deny and log actions in rules"),(0,i.kt)("li",{parentName:"ul"},"more flexible match criteria for applying policies and in policy rules, including matching on Kubernetes\nServiceAccounts, and (if using Istio & Envoy) cryptographic identity and layer 5-7 match criteria such as HTTP & gRPC URLs."),(0,i.kt)("li",{parentName:"ul"}
1,"ability to reference non-Kubernetes workloads in polices, including matching on\n",(0,i.kt)("a",{parentName:"li",href:"/calico/3.25/reference/resources/networkset"},"NetworkSets")," in policy rules")),(0,i.kt)("p",null,"While Kubernetes network policy applies only to pods, Calico network policy can be applied to multiple types of\nendpoints including pods, VMs, and host interfaces."),(0,i.kt)("p",null,"To learn more about Calico network policies, read the ",(0,i.kt)("a",{parentName:"p",href:"/calico/3.25/network-policy/get-started/calico-policy/calico-network-policy"},"Get started with Calico network policy"),"\nguide."),(0,i.kt)("h2",{id:"benefits-of-using-calico-for-network-policy"},"Benefits of using Calico for network policy"),(0,i.kt)("h3",{id:"full-kubernetes-network-policy-support"},"Full Kubernetes network policy support"),(0,i.kt)("p",null,"Unlike some other network policy implementations, Calico implements the full set of Kubernetes network policy features."),(0,i.kt)("h3",{id:"richer-network-policy"},"Richer network policy"),(0,i.kt)("p",null,"Calico network policies allow even richer traffic control than Kubernetes network policies if you need it. In addition,\nCalico network policies allow you to create policy that applies across multiple namespaces using GlobalNetworkPolicy\nresources."),(0,i.kt)("h3",{id:"mix-kubernetes-and-calico-network-policy"},"Mix Kubernetes and Calico network policy"),(0,i.kt)("p",null,"Kubernetes and Calico network policies can be mixed together seamlessly. One common use case for this is to split\nresponsibilities between security / cluster ops teams and developer / service teams. For example, giving the security /\ncluster ops team RBAC permissions to define Calico policies, and giving developer / service teams RBAC permissions to\ndefine Kubernetes network policies in their specific namespaces. As Calico policy rules can be ordered to be enforced\neither before or after Kubernetes network policies, and can include actions such as deny and log, this allows the\nsecurity / cluster ops team to define basic higher-level more-general purpose rules, while empowering the developer /\nservice teams to define their own fine-grained constraints on the apps and services they are responsible for."),(0,i.kt)("p",null,"For more flexible control and delegation of responsibilities between two or more teams, Calico Enterprise extends this\nmodel to provide ",(0,i.kt)("a",{parentName:"p",href:"#hierarchical-policy"},"hierarchical policy"),"."),(0,i.kt)("p",null,(0,i.kt)("img",{alt:"Example mix of network policy types",src:o(16676).Z,width:"1862",height:"2400"})),(0,i.kt)("h3",{id:"ability-to-protect-hosts-and-vms"},"Ability to protect hosts and VMs"),(0,i.kt)("p",null,"As Calico policies can be enforce on host interfaces, you can use them to protect your Kubernetes nodes (not\njust your pods), including for example, limiting access to node ports from outside of the cluster. To learn more, check\nout the Calico ",(0,i.kt)("a",{parentName:"p",href:"/calico/3.25/network-policy/hosts/"},"policy for hosts")," guides."),(0,i.kt)("h3",{id:"integrates-with-istio"},"Integrates with Istio"),(0,i.kt)("p",null,"When used with Istio service mesh, Calico policy engine enforces the same policy model at the host networking\nlayer and at the service mesh layer, protecting your infrastructure from compromised workloads and protecting your\nworkloads from compromised infrastructure. This also avoids the need for dual provisioning of security at the service\nmesh and infrastructure layers, or having to learn different policy models for each layer."),(0,i.kt)("h3",{id:"extendable-with-calico-enterprise"},"Extendable with Calico Enterprise"),(0,i.kt)("p",null,"Calico Enterprise adds even richer network policy capabilities, with the ability\nto specify hierarchical policies, with each team have particular boundaries of trust, and FQDN / domain names in policy\nrules for restricting access to specific external services."),(0,i.kt)("h2",{id:"best-practices-for-network-policies"},"Best practices for network policies"),(0,i.kt)("h3",{id:"ingress-and-egress"},"Ingress and egress"),(0,i.kt)("p",null,"At a minimum we recommend that every pod is protected by network policy ingress rules that restrict what is allowed\nto connect to the pod and on which ports. The best practice is also to define network policy egress rules that restrict\nthe outgoing connections that are allowed by pods themselves. Ingress rules protect your pod from attacks outside of the\npod. Egress rules help protect everything outside of the pod if the pod gets compromised, reducing the attack surface to\nmake mov
1ing laterally (east-west) or to prevent an attacker from exfiltrating compromised data from your cluster (north-south)."),(0,i.kt)("h3",{id:"policy-schemas"},"Policy schemas"),(0,i.kt)("p",null,"Due to the flexibility of network policy and labelling, there are often multiple different ways of labelling and writing\npolicies that can achieve the same particular goal. One of the most common approaches is to have a small number of\nglobal policies that apply to all pods, and then a single pod specific policy that defines all the ingress and egress\nrules that are particular to that pod."),(0,i.kt)("p",null,"For example:"),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-yaml"},"kind: NetworkPolicy\napiVersion: networking.k8s.io/v1\nmetadata:\n name: front-end\n namespace: staging\nspec:\n podSelector:\n matchLabels:\n app: back-end\n ingress:\n - from:\n - podSelector:\n matchLabels:\n app: front-end\n ports:\n - protocol: TCP\n port: 443\n egress:\n - to:\n - podSelector:\n matchLabels:\n app: database\n ports:\n - protocol: TCP\n port: 27017\n\n")),(0,i.kt)("h3",{id:"default-deny"},"Default deny"),(0,i.kt)("p",null,"One approach to ensuring these best practices are being followed is to define ",(0,i.kt)("a",{parentName:"p",href:"/calico/3.25/network-policy/get-started/kubernetes-default-deny"},"default deny"),"\nnetwork policies. These ensure that if no other policy is\ndefined that explicitly allows traffic to/from a pod, then the traffic will be denied. As a result, anytime a team\ndeploys a new pod, they are forced to also define network policy for the pod. It can be useful to use a Calico\nGlobalNetworkPolicy for this (rather than needing to define a policy every time a new namespace is created) and to\ninclude some exceptions to the default deny (for example to allow pods to access DNS)."),(0,i.kt)("p",null,"For example, you might use the following policy to default-deny all (non-system) pod traffic except for DNS queries to kube-dns/core-dns."),(0,i.kt)("pre",null,(0,i.kt)("code",{parentName:"pre",className:"language-yaml"},'apiVersion: projectcalico.org/v3\nkind: GlobalNetworkPolicy\nmetadata:\n name: default-app-policy\nspec:\n namespaceSelector: has(projectcalico.org/name) && projectcalico.org/name not in {"kube-system", "calico-system", "calico-apiserver"}\n types:\n - Ingress\n - Egress\n egress:\n - action: Allow\n protocol: UDP\n destination:\n selector: k8s-app == "kube-dns"\n ports:\n - 53\n')),(0,i.kt)("h3",{id:"hierarchical-policy"},"Hierarchical policy"),(0,i.kt)("p",null,(0,i.kt)("a",{parentName:"p",href:"/calico-enterprise/latest/network-policy/policy-tiers/tiered-policy"},"Calico Enterprise")," supports hierarchical network policy using policy tiers. RBAC\nfor each tier can be defined to restrict who can interact with each tier. This can be used to delegate trust across\nmultiple teams."),(0,i.kt)("p",null,(0,i.kt)("img",{alt:"Example tiers",src:o(968).Z,width:"1862",height:"2400"})))}d.isMDXComponent=!0},16676:(e,t,o)=>{o.d(t,{Z:()=>n});const n=o.p+"assets/images/example-k8s-calico-policy-mix-c22a42da6321a0be5f0963664fd5baf3.svg"},968:(e,t,o)=>{o.d(t,{Z:()=>n});const n=o.p+"assets/images/example-tiers-350db070cf4f095db5de19ecbcc1e9ea.svg"}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.