--- title: "Egress Access Control for Kubernetes Workloads" source: "https://www.tigera.io/blog/egress-access-control-for-kubernetes-workloads/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Egress Access Control for Kubernetes Workloads By [Bikram Gupta](https://www.tigera.io/blog/author/bikramgupta/) on May 12, 2020 • 4 min read Consider an enterprise hybrid cloud deployment with hundreds of nodes and thousands of pods. These systems are running business applications with different levels of security requirements. A first-order security and compliance requirement in such a scenario is to ensure that a pod or host is only allowed to talk to authorized destinations. Now consider the real life scenario where there’s a churn rate (pods/hosts being added/removed) of hundreds of pods/minute. The challenge is to continue enforcing these security controls in near real time despite a high churn rate. An efficient mechanism for security controls has a direct impact on productivity. Ideally, you do not want to wait days for an access policy to be granted through a ticketing process, nor do you want to wait precious minutes for a policy change to take effect. Security controls have two broad categories, East-West (E-W) and North-South (N-S). Egress access control refers to N-S security on egress. The following are typical use cases of egress access control: - Configure default-deny without blocking access to essential services - Permit access to specific Internet APIs (slack, twilio, watson etc.) - Permit access to internal resources in the corporate network (database, VMs etc.) - Automatic enforcement of egress policy on VM’s as they come up (autoscaling, new node provisioning etc.) Network Policy in Calico Enterprise helps you address the use cases above. ## How does it work? ![Diagram of a Kubernetes pod with policy enforcement points at the container, pod, and host levels](/app/uploads/2019/10/Enforce-Security.png) Calico Enterprise uses a single policy language across all resources (pods, VMs, bare metal). The egress access control for pods is enforced on the pod-to-host interfaces. The egress access control for hosts is enforced on the host interface. At the heart of the enforcement is the concept of labels. Consider a simple example as shown below. This policy applies to a selector with key=my-pod-label, and value=my-value. This label can be present on a pod or a host. ![YAML code showing a GlobalNetworkPolicy with selector 'my-pod-label == 'my-value](https://www.tigera.io/app/uploads/2020/05/Egress-Access-Control-for-Kubernetes-Workloads.png) The access rule of the policy permits access to any destination with key=color and value=red. That destination can be any resource (pod, host, networkset etc.). This is the elegance of having a single policy language across all your hosts and pods. The backend processing of access policies is equally simple. Calico runs a daemon on every Kubernetes node and non-Kubernetes host that you protect. Any change in configuration is sent to etcd (Kubernetes datastore). Calico-nodes watch for any change and pull the change. Calico is proven to scale in large-scale deployments with thousands of nodes. ## Why does this matter? - Egress access control with default-deny is the first order requirement for security and compliance in hybrid cloud datacenter. - Calico network policies reduce operational overhead in managing access control. You create declarative access policies which do not need to be changed often, if designed properly. - With one policy, you can enforce access controls across pods and hosts. No hidden clause. All you need is labels on the pods/hosts. Configuration is stored in the same kubernetes datastore (etcd), simplifying operations. ## How do I enable Egress Access Control? It is a core feature of Calico Enterprise. Refer to the sample blueprints. - [Deny all egress traffic](https://docs.tigera.io/calico-enterprise/latest/network-policy/). - [Permit egress based on network-set](https://docs.projectcalico.org/security/external-ips-policy#limit-traffic-to-or-from-external-networks-global-network-set). - [Permit egress based on domain](https://docs.tigera.io/calico-enterprise/latest/network-policy/get-started/kubernetes-policy-advanced#5-allow-dns-egress-traffic). The important part is to have a solid egress control framework that scales as you expand clusters, teams and applications. - Establish a process on who is authorized to manage the egress policies. Define and enforce the policy life-cycle from access request to enforcement to monitoring. - Implement a design so you have to make minimal changes to policies. The way to achieve this is to group the resources into (global) network sets. As the external resource access requirement changes, you simply update the network set. As new pods need access to external resources, you simply label the pods. - Have the deny-all in place. To learn more about egress access control… Policy rules in Calico: [https://docs.projectcalico.org/security/policy-rules](https://docs.projectcalico.org/security/policy-rules) Protect Kubernetes nodes in Calico: [https://docs.projectcalico.org/security/kubernetes-nodes](https://docs.projectcalico.org/security/kubernetes-nodes) Protect hosts: [https://docs.projectcalico.org/security/tutorials/protect-hosts](https://docs.projectcalico.org/security/tutorials/protect-hosts) Automatic host endpoints: [https://docs.tigera.io/calico-enterprise/latest/network-policy/hosts/kubernetes-nodes#automatic-host-endpoints](https://docs.tigera.io/calico-enterprise/latest/network-policy/hosts/kubernetes-nodes#automatic-host-endpoints) Domain name in policy rules for pods and hosts: [https://docs.tigera.io/calico-enterprise/latest/network-policy/domain-based-policy#trusted-dns-servers](https://docs.tigera.io/calico-enterprise/latest/network-policy/domain-based-policy#trusted-dns-servers) [How-To](https://www.tigera.io/tags/how-to/)[Products](https://www.tigera.io/tags/products/) ## Related posts [![Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/app/uploads/2026/09/Meet-Mylo-An-AI-native-way-to-work-with-Calico.png)](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) #### [Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) By [Phil DiCorpo](https://www.tigera.io/blog/author/phil-dicorpo/) on Sep 3, 2026 A library of Calico tools and skills — delivered through the Calico MCP Server What if your hardest network question took ten minutes instead of ten days? Anyone who has operated Kubernetes networking at scale... [Read more](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/) [![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) #### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 27, 2026 Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a... [Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) [![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) #### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 24, 2026 The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms... [Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)