--- title: "Workload access control: Securely connecting containers and Kubernetes with the outside world" source: "https://www.tigera.io/blog/workload-access-control-securely-connecting-containers-and-kubernetes-with-the-outside-world/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Workload access control: Securely connecting containers and Kubernetes with the outside world By [John Armstrong](https://www.tigera.io/blog/author/john-armstrong/) on Oct 21, 2021 • 5 min read Containers have changed how applications are developed and deployed, with Kubernetes ascending as the de facto means of orchestrating containers, speeding development, and increasing scalability. Modern application workloads with microservices and containers eventually need to communicate with other applications or services that reside on public or private clouds outside the Kubernetes cluster. However, securely controlling granular access between these environments continues to be a challenge. Without proper security controls, containers and Kubernetes become an ideal target for attackers. At this point in the Kubernetes journey, the security team will insist that workloads meet security and compliance requirements before they are allowed to connect to outside resources. As shown in the table below, Calico Enterprise and Calico Cloud offer multiple solutions that address different access control scenarios to limit workload access between Kubernetes clusters and APIs, databases, and applications outside the cluster. Although each solution addresses a specific requirement, they are not necessarily mutually exclusive.   **Your requirement** **Calico’s solution** **Advantages** You want to use existing firewalls and firewall managers to enforce granular egress access control of Kubernetes workloads at the destination (outside the cluster) Egress Access Gateway Security teams can leverage existing investments, experience, and training in firewall infrastructure and InfoSec processes You want to enforce granular egress access control of Kubernetes workloads at the source (inside the cluster) using DNS policies DNS Policies DevSecOps teams can enforce egress access controls from within the cluster, without the need for firewalls You have specific workloads or groups of workloads that need the ability to access external objects on the internet with a predefined range of IP addresses Global and Namespaced NetworkSets DevSecOps teams can use this method to apply policy to control traffic going to (egress) or coming from (ingress) external, non-Calico networks   Let’s examine each one of these workload access control methods in a bit more detail. ## Egress Access Gateway The Calico Egress Access Gateway is an ideal solution for security teams that have made an investment in firewall infrastructure, and wish to extend the zone-based firewall architecture and the capabilities of firewall managers like Fortinet FortiManager and Palo Alto Networks Panorama to embrace Kubernetes clusters. Firewalls are ubiquitous and are the predominant method of determining which traffic will be allowed or denied access between security zones, and in which direction. Traffic is identified by IP address, and for a zone-based security architecture to work, the firewall must know the network identity based on the source IP address. The Egress Access Gateway can assign a fixed, routable IP address to a Kubernetes namespace containing an application or workload. All egress pod traffic from that namespace will then be assigned that routable IP address to identify the workload running within that namespace. A single firewall rule can be defined that allows all pods within a given namespace to securely access resources outside of the cluster, in effect establishing a universal firewall. By extending the scope of firewalls to Kubernetes to control traffic originating from a cluster, the Egress Access Gateway enables enterprise security teams to leverage familiar, existing firewall tools, processes, and architecture, thereby simplifying and facilitating Kubernetes adoption and deployment. The Egress Access Gateway can also be used in conjunction with DNS policies for an added layer of protection. ## DNS policies DNS policies can be created that implement fine-grained access controls between an individual pod or namespace and the external services it needs to connect to. Security policies based on domain names enable fine-grained controls that are enforced at the source pod, eliminating the need for a firewall rule or equivalent. DNS endpoints can be defined as an exact address (e.g. google.com) or can include wildcards (e.g. *.google.com, http://api.twilio.com/* ). Once a DNS policy has been implemented, no other pods will be permitted to communicate with that DNS endpoint unless allowed by the policy. With the DNS policy model, workload access control policies are enforced from within the cluster. Calico security policies are designed to abstract away from IP addresses in favor of label selectors, but still require external services outside of the cluster to be identified by an IP address. If security policies need to be enforced from an external control point such as a firewall, the Egress Access Gateway is a recommended option. ## NetworkSets Kubernetes workloads typically integrate with third-party APIs, applications, and SaaS services that live outside a Kubernetes cluster. To securely enable access to those integrations, security teams must be able to limit IP ranges for egress and ingress traffic to workloads. This includes using IP lists or ranges to deny-list known threats. Using a CIDR (Classless Inter-Domain Routing) range, a single IP address can be used to designate a subnetwork, or network set, representing an arbitrary set of IP subnetworks/CIDRs, allowing it to be matched by Calico policy. Calico GlobalNetworkSets and Namespaced NetworkSets are used to specify the IPs/CIDRs to use in a network policy, and eliminate the need for users to manually update all the access control policies when one end of the communication is a large set of IP CIDRs. Calico network sets can be used to apply policy to control traffic going to (egress) or coming from (ingress) external, non-Calico, networks.   With Calico’s workload access control solutions, you can accelerate your application modernization journey and integrate container and Kubernetes workloads with external APIs, applications, databases and public clouds without compromising any requirements for security or compliance.   ***Learn best practices to granularly control workload access between Kubernetes clusters and external resources. Download our white paper, [Best practices: Using workload access controls for containerized workload protection](https://www.tigera.io/lp/workload-access-controls/)***   [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/)