Cloud-native workloads are dynamic, distributed, and ephemeral and do not have fixed network addresses. Traditional methods such as network firewalls, which rely on fixed network addresses, are insufficient to specify access controls at a granular workload level. However, granular workload access controls are essential for security and compliance of cloud-native applications.
Calico provides granular workload access controls to control the flow of data between individual pods in Kubernetes clusters and external resources including databases, internal applications, 3rd-party cloud APIs, and SaaS applications. Calico provides three ways to enable fine-grained workload access controls:
- DNS policies – Enforce controls using DNS egress policies
- Egress Gateway – Enable network firewalls to identify and secure cloud-native workloads
- NetworkSets – Use IPs/CIDRs in network policy for access control
Fine-grained access to resources outside of the cluster, like databases, cloud-managed services, third-party APIs, and other applications that are not yet containerized
Safely and securely transition Kubernetes workloads from pilot to production
Maintain compliance with existing enterprise and regulatory security requirements
Author DNS policies for fine-grained access
- Calico extends the open-source policy model so that fully qualified domain names (FQDN / DNS) can be used to allow access from a pod or set of pods (via label selector) to external resources (databases, cloud services, third-party APIs).
- Security policies based on domain names (DNS) 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). DNS endpoints can also be used within Global Network Sets.
Use Egress Gateway to integrate with existing network firewalls
- Calico’s Egress Access Gateway assigns a fixed, routable IP to a Kubernetes namespace. All egress pod traffic from that namespace is assigned that routable IP address to identify the workload running within that namespace. This enables the cluster to securely scale while preserving the limited number of routable IPs and leveraging non-routable IPs for all other pod traffic within the cluster.
- A single firewall rule can be defined that allows all pods within a namespace to securely access resources outside of the cluster, in effect establishing a universal firewall. The platform team only has to manage one firewall rule instead of many, saving time and eliminating the burden of multiple firewall change requests to the security team. Beyond the cluster, enterprise monitoring systems such as SIEMs can identify an application/workload in a Kubernetes namespace via its source IP address.
- Enterprise security teams can leverage familiar, existing firewall tools, processes, and architecture, thereby simplifying and facilitating Kubernetes adoption and deployment.
Global and namespaced NetworkSets
- Calico GlobalNetworkSets and namespaced NetworkSets can use CIDR notations for a range of IPs to use in a network policy, to automatically update access control policies for all the IPs described by the CIDR notation. Calico NetworkSets can be used to apply policy to control traffic going to or coming from external, non-Calico networks. And using Calico NetworkSets, you can easily scale out by using the same set of IPs in multiple policies.
How It Works
Calico helps you granularly restrict access from Kubernetes clusters to resources outside the cluster in different ways. This not only protects your cluster resources, it provides you with the flexibility to align with your specific architecture. Fully qualified domain names can be used in DNS policies to control access from a pod or set of pods to an external resource. You can enforce the controls from a firewall outside the cluster using the Egress Gateway. Or you can securely enable access by using NetworkSets to limit IP ranges for egress and ingress traffic to/from workloads.