Zero-Trust Workload Access Controls

Reduce the attack surface of cloud-native applications by enabling secure, fine-grained, zero-trust access from Kubernetes pods to resources outside the cluster

Overview

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 zero-trust workload access controls are essential for cloud-native application security and compliance. Without such controls, an advanced persistent threat (APT) can take control of a pod and exfiltrate data.

Calico provides granular zero-trust 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:

  1. DNS policies – Enforce controls using DNS egress policies
  2. Egress Gateway – Enable network firewalls to identify and secure cloud-native workloads
  3. NetworkSets – Use IPs/CIDRs in network policy for access control

Benefits

Granular Access

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

Production-Ready

Safely and securely transition Kubernetes workloads from pilot to production

Maintain Compliance

Maintain compliance with existing enterprise and regulatory security requirements

Capabilities

DNS Policies

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.

Egress Gateway

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

Use IP Subnet/CIDR ranges in security policies

  • 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.

Additional resources:

Resources

Webinar

Learn More

Blog

Learn More

Assessment

Learn More